OWASP LLM-08 is called "Excessive Agency." Read the description carefully and you'll notice: it's not a model safety problem. It's an identity and authorization problem. And most organizations deploying agents have no solution for it.
The Travel Agent That Booked a $47,000 Flight
A company deploys a travel assistant. The agent can search flights, compare prices, and book trips on behalf of employees. It works through a shared service account connected to the corporate travel API.
An employee asks the agent to "find the cheapest flight to London next Tuesday." The agent finds a $450 economy ticket. But the agent also has access to the booking API — same service account, same OAuth token. A prompt injection embedded in a flight description triggers the agent to book a first-class ticket for $47,000.
Who authorized that booking? The service account did. On behalf of... the service account. There's no link to the employee who asked. No policy that says "this agent may search flights for Alice but may only book economy under $5,000." No receipt showing which policy was evaluated, what budget was checked, or what the agent's capability constraints were.
Why This Keeps Happening
The root cause is not insufficient logging or missing "guardrails." The root cause is that agent identity and authorization are not modeled.
Shared bot identities
Agents run under service accounts, blurring which human principal the agent acts for. Revoking one employee's access requires revoking the entire bot — or doing nothing.
Binary authorization
OAuth scopes and API keys say "allowed" or "denied." They cannot express per-operation constraints — budget caps, velocity limits, geographic restrictions.
No delegation model
No first-class representation of "Alice delegated these specific capabilities to this agent, with these constraints, expiring at this time."
What Authorization for Agents Actually Requires
Delegation-Bound Agent Context
Every agent action must be bound to a delegating human principal through a first-class Delegation record. Revoking Alice's delegation severs her agent's access. Bob's delegation is unaffected. This is the confused-deputy fix.
Per-Operation Capabilities with Constraints
The delegation must express what the agent can do, with quantitative limits: budget caps per booking, velocity limits per day, geographic restrictions. This requires a richer vocabulary than OAuth scopes.
ARIA separates OperationRef (semantic, policy-level: travel.flight.book) from ToolId (implementation: mcp:amadeus:book_flight). Tool upgrades and MCP server migrations never require policy rewrites.
Graph-Anchored ABAC
For agents, you need both relationship-based access control (who can act for whom) and attribute-based rules (under what constraints). Graph-Anchored ABAC embeds policies as first-class nodes in a Neo4j graph — one query resolves relationships and policies together.
What the OWASP and MITRE Mappings Tell You
For LLM-08 specifically: ARIA's response is capability limits and plan discipline, enforced through the delegation model at the MCP Gateway. The agent cannot accumulate capabilities beyond what the delegation explicitly grants.
For the travel agent scenario: PDP evaluation would have denied the booking, the OAuth token would never have been fetched (authorization happens before credential retrieval), and a signed receipt would have recorded the denial with the policy version, delegation state, and budget snapshot. That receipt is what you hand the auditor.
Before You Ship Your Next Agent
1. Can you revoke one user's agent without affecting all users?
2. Can you express per-operation constraints (budget, velocity, geography) in your policy — not just allow/deny?
3. If an auditor asks "prove this agent was authorized to perform this action on March 15," can you produce a signed receipt in minutes?
If the answer to any of these is "no," you have an identity and authorization problem, not a guardrails problem.
ARIA is EmpowerNow's runtime execution control platform. Standards-based (OpenID AuthZEN 1.0, OAuth 2.0 RFC 8693/9396/9449, MCP). Production rollout underway.
Next in this series: The Hidden Security Flaw in "Just Put the Token in a Vault"