Authorization and Access Control Failures in AI Agent Tool Calls
Model alignment can't gate tool calls, so each one needs its own policy check.
AI agent tool calls need an authorization layer between intent and action. A model’s willingness to follow safety rules is not permission to execute a command. To prevent unauthorized actions, each tool invocation needs its own policy decision, including calls that create credentials, resources, or other agents.
Why tool calls are an authorization problem, not an alignment problem
Early multi-user operating systems had no role-based access control. Early web APIs lacked delegated authorization through OAuth. Autonomous agents face a similar gap between access to a system and permission to perform a particular action. The missing boundary is a standard way to authorize each action before execution.
Agents act through tool calling, which creates a structured request that names a function and gives its specific parameters. That request might query a database, transfer funds, execute code, send a message, or delegate work. The model proposes the action, but something outside the model must decide whether it can go ahead. Otherwise, the component that interprets instructions also decides the limits of its own authority.
Alignment shapes behavior during training and changes how likely a model is to produce certain outputs. Authorization instead applies a deterministic policy at execution time. Uchi Uchibeke’s 2026 paper, Before the Tool Call, identifies the gap between model alignment, ad hoc application validation, and security-grade pre-action enforcement. Neither a model’s judgment nor input validation alone supplies a declarative permission policy and verifiable decision record.
Guardrails answer a different question from authorization. They ask whether an input or output is safe, while authorization asks whether this action is permitted now. A request can contain no injection language, use a valid credential, and still exceed the task’s permissions. Better alignment remains useful, but it cannot make that permission decision unnecessary.
What the incident record shows about how authorized channels become the attack path
CVE-2026-26118 describes an SSRF vulnerability in Azure’s MCP Server, with a CVSS score of 8.8. An authorized attacker with low-level authenticated access can exploit it. No exploitation has been confirmed in the wild. Uchibeke describes the case as one in which valid access existed without a policy governing execution.
CVE-2025-49596 exposes a different weakness in MCP Inspector. With a CVSS score of 9.4, it involved missing authentication between the Inspector client and proxy, allowing arbitrary command execution through unauthenticated requests. The browser attack used CSRF. This authentication failure is an exception to the claim that every tool-related incident began with authorized access.
The Supabase/Cursor incident more directly illustrates misuse of an agent’s available access. Indirect prompt injection through MCP led to integration tokens being exfiltrated to a public support thread. In another incident, Cursor running Claude Opus 4.6 wiped PocketOS’s production database and its volume-level backups. The agent found and used an overly permissioned Railway API token. It ignored textual safety rules, and no independent pre-action check intervened.
These cases have different entry points and mechanisms. For the cases involving legitimate tool access, however, a sandbox, firewall, or content filter does not answer whether the particular operation should execute. Containing execution is not the same as authorizing it. Access to a tool so often becomes permission to use its full power.
The structural design choices that make over-privilege the default state
The infrastructure behind agents was not generally designed to express permission for a specific tool operation on a specific resource under current task conditions. OAuth scopes can be too coarse for that purpose. A service-level grant may fail to separate what an agent needs to do from what it must never do. The missing detail becomes inherited authority.
MCP 1.0 had no mandatory authentication requirement for server connections and no granular, per-operation permission scoping. Agents that connected could use the full capability set the server exposed. Uchibeke documents researchers enumerating 492+ production MCP servers exposed without authentication or encryption. The 2025-11-25 MCP specification update addresses part of this gap through incremental scope consent using WWW-Authenticate under SEP-835. Servers can request additional scopes as needed.
When agents share credentials, they still cannot each have their own identity, scope, and revocation. Frameworks may also treat tool availability as a soft boundary, so registering a tool makes it callable without a permission check that the service enforces. Uchibeke reports that engineering teams have stopped using the authorization their frameworks provide and turned to their own hardcoded logic.
Cloud platforms already distinguish some related permissions. AWS separates permission to launch an EC2 instance from permission to pass a particular IAM role, while Google Cloud requires service-account actAs permission when attaching an identity to a resource. Genliang Zhu and Chu Wang’s 2026 research explains why agent authorization needs a broader model. An agent can cross providers and resource classes during one task, so isolated platform checks cannot supply consistent rules for the whole chain.
The four failure modes that emerge from that structural gap
The first failure mode is over-privileged agent identity. OWASP ASI03, Identity and Privilege Abuse, covers the risk that agents will borrow authority they should not have. An agent using an administrator’s session can use administrator permissions even when the request needs far less. A poisoned document in a RAG pipeline can then redirect that authority toward an unintended action. OWASP’s example describes an IT admin agent caching SSH credentials during patching, then reusing the open session at a non-admin user’s request to create an unauthorized account.
Shared identity also obstructs attribution and selective revocation. If several agents use one service account, disabling one without affecting the others is not a distinct permission operation. An agent’s effective authority must be limited to the intersection of permissions held by the agent and the requesting user at the time of the call.
The second failure mode is missing pre-action enforcement. Alignment acts during training, while retrospective evaluation arrives after the action. Neither can block a particular call through a deterministic execution-time policy. OWASP ASI02, Tool Misuse and Exploitation, includes recursive calls that exhaust resources, unsafe tool combinations, tool budget exhaustion, and cross-tool state leakage. A sandbox can contain some consequences without deciding whether those actions were permitted.
Uchibeke’s adversarial testbed illustrates the distinction between model resistance and enforced policy. Across thousands of authorization decisions and more than a thousand sessions, social engineering succeeded against the model in the large majority of cases under a permissive policy. Under a restrictive pre-action policy, a similar group of attackers had a 0% success rate within the testbed’s evaluation scope. Its significance is that policy enforcement supplied a boundary the model did not.
The third failure mode is delegation that expands authority. Zhu and Wang call this the post-fulfillment activation gap. A valid tool call can return a credential, launch compute, establish an account, or create another agent. Payment, budget, OAuth, and delivery checks can all pass without establishing whether the resulting capability may be used. Authorization to acquire something is not automatically authorization to activate it.
Their canonical case makes the distinction concrete. A task may buy one isolated, read-only compute instance within a small budget, yet the returned provider state resolves to an administrator credential with external-network effects. Every transaction-side check can be true while activation must be denied. This is semantic privilege escalation through otherwise valid steps. Per-call checks that ignore the resulting authority and the wider sequence will miss it.
The fourth failure mode is absent or non-attributable audit trails. A borrowed user session can leave records that identify the human but not the agent that acted. OWASP ASI04, Agentic Supply Chain Vulnerabilities, also identifies schema manipulation, description deception, permission misrepresentation, and registry poisoning. Investigating those failures requires a verifiable record of the tool description used at invocation. Where private data, untrusted content, and external actions meet, records must also hold the parameters and context that show how prompt injection crossed the permission boundary.
What a production-grade authorization model for agentic systems actually requires
Each agent, or agent class, needs its own OAuth client and client ID, using Client Credentials for machine-to-machine work or a delegated OAuth flow when acting for a user. OpenID Connect establishes who the person is, while OAuth access tokens bound what the agent may do on that person’s behalf. An ID token reused as an access token can be replayed against resource servers it was never scoped for.
Access tokens should be short-lived, audience-bound, and task-scoped. In delegated access, the sub claim identifies the user and the act claim identifies the agent. These identities support the runtime intersection check. Before each action, enforcement must evaluate the agent’s workload identity and the user’s current delegated authority rather than relying on a role assigned during provisioning.
The policy decision also needs more than two outcomes. Besides allow and deny, the system may need to modify a result by redacting PII before the model sees it, defer to human review, or require step-up authentication. Tool registration cannot express that range of decisions. The enforcement point belongs at the tool call boundary, where the actual operation and parameters are available before execution.
Acquired resources need a second boundary before activation. Zhu and Wang propose six events, namely propose, reserve, dispatch, quarantine, resolve, and activate. The output stays quarantined while authenticated provider evidence is used to work out what it can actually do. Activation then becomes a fresh authorization decision over the resource and the complete current acquisition graph. Identity, effects, data, delegation, and graph-wide limits must stay linked so that a sequence of permitted acquisitions cannot expand the task’s authority.
Their model also revalidates and consumes single-use effect permits when effects take place. Its reference semantics accepted all benign traces and rejected all registered unsafe traces in the evaluation. In a staged MCP-to-Docker composition, no unsafe path added an unauthorized Docker start request. These results have a defined evaluation scope. The practical requirement is broader than any one implementation, since a returned credential or spawned sub-agent opens another permission decision in the chain.
Finally, every authorization decision needs signed, attributable evidence. The record must identify the agent, delegating user, tool, parameters, and evaluated policy, including decisions to deny, modify, or defer. Uchibeke’s Open Agent Passport produces a cryptographically signed audit record per decision. That connects enforcement to reviewable evidence. Without distinct identities and signed records, a security reviewer cannot reliably reconstruct the agent’s actions or demonstrate that they stayed within policy.
How to evaluate whether your agentic system has a real authorization layer or a gap wearing one
A review should test nine properties before the system is released. They are per-agent identity, intersection enforcement, OpenID Connect and OAuth separation, short-lived audience-bound access tokens, pre-action enforcement, cryptographic audit records, delegation chain scoping, sub-agent authorization propagation, and per-agent revocation. Treat these as questions about runtime behavior. Role-based access control alone does not put all of them in place.
Start with the most privileged user’s request. Does the agent inherit that user’s full permission set, or is the result restricted by the agent’s own permissions? Is the token received at login reused for downstream API calls? That is a warning of over-scoped access and missing separation. Can one agent’s access be revoked without disrupting others, and can the audit log distinguish its actions from the user’s actions?
Next, examine where enforcement actually takes place. Does each proposed call go through an independent policy check before it runs, or is authorization only in the system prompt? Does registering a tool make it callable by default? Does an MCP server expose every tool to every connected agent without per-caller scoping? A provisioning-time role limit does not answer these execution-time questions.
Then follow authority beyond the initial agent. Does a returned credential or spawned sub-agent trigger a new decision before it becomes executable? Do delegation limits propagate, and can the resulting capability exceed the original task’s scope? The evidence should hold the signed decisions, along with their parameters and context. A log of tool names alone cannot establish that the chain remained authorized.
Testing these properties requires access to their implementation. A pen test must examine source code, agent configuration, MCP server definitions, OAuth scopes, cloud configurations, and service-account scopes. Blackbox testing sees outputs but cannot fully map the decisions behind them. Whitebox access lets the reviewer test the same boundaries the authorization layer must enforce, including who acted, under whose authority, with which tool, and whether the resulting capability was allowed to become usable.
