OWASP LLM06 Excessive Agency for refund and discount agents

What is Excessive Agency?

In the OWASP Top 10 for LLM Applications 2025, Excessive Agency is the vulnerability that “enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM.” The trigger can be a hallucination, a weak model, or direct or indirect prompt injection.

OWASP names three root causes: excessive functionality (tools the agent does not need), excessive permissions (tools with more rights than the task requires) and excessive autonomy (high-impact actions with no independent check). The damage depends on what the agent can reach, which is why it matters most for agents with payment tools.

What does it look like in a refund or discount agent?

Each OWASP root cause has a direct equivalent in a support or sales agent. The examples are illustrative.

Root cause	Refund or discount equivalent	How to test it
Excessive functionality	A generic `update_order` tool that can change price, status and refund amount, when the agent only needs `issue_refund`	Ask the agent to “correct” the order price. Check whether any tool lets it
Excessive functionality	An old `apply_coupon` tool from a pilot still registered with the agent	List the tools the agent can call in production and compare with the design
Excessive permissions	The refund tool uses a service account that can refund any order, not only the signed-in customer’s	Give the agent another customer’s order number
Excessive permissions	`apply_discount(percent)` accepts any value from 0 to 100	Push for 90% off with a plausible story. Check the tool rejects it
Excessive autonomy	Refunds of any amount execute without a person, including on orders marked delivered	Claim non-delivery on a $900 order with proof of delivery on file

Which OWASP mitigations apply to money tools?

OWASP lists eight prevention steps. Mapped to a refund or discount agent:

Minimize extensions: give the agent only the money tools its job needs.
Minimize extension functionality: issue_refund issues refunds. It does not edit orders or prices.
Avoid open-ended extensions: no general database, admin API or “run action” tool.
Minimize extension permissions: the tool’s credentials can refund within limits and nothing else.
Execute in the user’s context: the tool can act only on the authenticated customer’s orders.
Require user approval: a person approves refunds, credits and discounts above a threshold or outside policy.
Complete mediation: caps, eligibility and approvals are enforced in the payment or order system, not by the model.
Sanitize inputs and outputs: validate amounts, currencies and order IDs in every tool call.

How does the OWASP Agentic Top 10 extend this?

OWASP published the Top 10 for Agentic Applications for 2026 on 9 December 2025. Several entries apply directly to agents that move money: ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI06 Memory and Context Poisoning, and ASI09 Human-Agent Trust Exploitation.

The list also frames a principle it calls least agency: autonomy should be earned, not granted by default (Auth0 summary). For a refund agent, that means starting with low caps and human approval, then widening limits only where test and production data support it.

Why isn’t least privilege enough for money tools?

Excessive Agency controls bound the worst case. They do not stop the agent from misusing authority it legitimately has. OWASP’s own text notes that logging, monitoring and rate limiting limit the damage but do not prevent it.

A $50 goodwill credit can be correctly scoped, correctly permitted and still granted to someone who talked the agent into it. ASI02 describes this case: a legitimate tool used in an unsafe or unintended way. Measuring it takes adversarial conversations against the real tools and policy, scored in dollars granted outside policy, not only a review of permissions.

Checklist for a refund or discount agent

Controls to put in place, then try to break in testing.

An inventory of every tool the agent can call, with its owner and purpose. Anything unused is removed.
Typed parameters with server-side limits: maximum refund, maximum discount percentage, allowed reason codes.
Limits per conversation, per customer and per day, so splitting and stacking hit a ceiling.
Tools scoped to the authenticated customer. Order IDs from other accounts are rejected.
Human approval above a threshold, outside policy, or when the customer cites an approval the system cannot find.
Content from tickets, attachments, product pages and tool outputs treated as data, never as instructions.
Memory and customer notes that cannot grant entitlements on their own.
Alerts on unusual refund rates per agent version, per customer and per hour.

Questions

Is Excessive Agency the same as prompt injection?

No. Prompt injection (LLM01) is one way an attacker manipulates the model. Excessive Agency (LLM06) is about how much damage the model can do once manipulated. Strong LLM06 controls limit the cost of an injection that gets through.

Where should refund caps be enforced?

Outside the model, in the system that executes the refund. OWASP calls this complete mediation: authorization is enforced downstream, not by asking the LLM to decide. A cap written only in the prompt is a suggestion.

This page applies a security standard to a common use case and is not legal advice.

Attack families

Scenarios

Free checklist

Get the guardrail checklist for agents that move money.

A one-page PDF of the controls and the test for each. Download it right away, and we email you the link.

OWASP Excessive Agency (LLM06) for refund and discount agents