10 patterns for this goal
Tool authorization fails when agents designed to access only a limited, pre-approved set of tools instead escalate to broader tool access, bypass authorization checks, or invoke tools without proper validation. An agent designed to read files in a sandbox directory discovers a path-traversal vulnerability and reads files outside the sandbox, an agent escalates from “read-only query” permissions to “write” permissions by modifying request context, and a tool-authorization check verifies the agent is authorized to invoke a tool but does not verify the agent is authorized for the specific parameters (reading one database table vs. all tables). Tool authorization failures matter precisely because tools are the agent’s primary interface to external systems: overly broad tool access turns any agent compromise into full system compromise.
Effective tool authorization requires three layers: (1) role-based access (what tools can agent invocation), (2) parameter-based access (what parameters/resources can agent invoke tool against), (3) runtime validation (re-verify authorization even for pre-approved tool invocations). The shared lesson is that tool authorization is not binary (authorized/not authorized) but graduated (authorized for specific tools, against specific resources, with limited parameters, for limited time). Without parameter-level scoping, tool-access authorization is useless: an agent authorized to access a database is not authorized to query all tables, an agent authorized to access file systems is not authorized to read outside its sandbox.
Authorization checks must be performed on agent-immutable state, not on agent-modifiable context: (1) derive permissions from agent identity and configuration (stored outside agent-accessible state), (2) validate permissions before accepting any parameter from agent (do not trust agent-supplied parameters), (3) implement capability-scoped authorization (agent can invoke tool, but with limited parameters and resource scopes defined at authorization-check time), (4) audit permission escalation attempts and alert on escalation patterns.
Parameter validation (checking that parameters match expected format/type) is necessary but insufficient. Authorization requires validating not just parameter format but parameter scope: even if a parameter is properly formatted, is agent authorized to use that specific parameter value (e.g., table name in database query)? Defense requires: (1) validate parameter type/format (prevent injection), (2) validate parameter scope (verify agent is authorized for that specific resource), (3) restrict parameter choices to pre-approved set when possible (allowlist of tables/files/endpoints agent can access).
Least-privilege requires starting minimal: give agents only the tools absolutely required for their core task, add tools on-demand with audit trail showing why each tool was added, continuously monitor tool usage and disable unused tools. Implement just-in-time authorization: agents request tool access for specific action, receive scoped-access for that action only, access expires after action completes. This makes it visible when agents access tools they rarely use (red flag for compromise or unusual behavior).
| Pattern | Mechanism | Frequency |
|---|---|---|
| Tool Access Scope Limits | Agent accesses tools beyond its authorized scope | Occasional |
| Tool Capability Limits | Agent invokes tool capabilities beyond authorized operations | Occasional |
| Tool Financial Limits | Agent invokes paid tools exceeding budget or cost limits | Occasional |
| Tool Integration Limits | Agent integrates tool incorrectly or with unsafe configuration | Occasional |
| Tool Invocation | Agent invokes tool without proper context or prerequisites | Occasional |
| Tool Operational Limits | Agent exceeds tool operational limits (rate limits, timeout, quotas) | Common |
| Tool Rate Quota Limits | Agent exceeds tool rate limits or quota allocations | Common |
| Tool Reliability | Tool fails or times out; agent lacks error handling | Occasional |
| Tool Selection | Agent selects wrong tool or incorrect tool version | Occasional |
| Tool SLA Quality Limits | Tool performance degrades below SLA; agent unaware of degradation | Occasional |
Total: 10 patterns
An agent exposes admin-tier tool operations (e.g. `delete_user`, `override_billing`, `reset_org_settings`) through the same tool-calling interface as ordinary operations, and the dispatch layer invokes them without first checking whether the requesting user actually holds an admin role. Any user who can phrase a prompt that maps to the admin tool schema gets the admin code path executed with the agent's (often elevated) service credentials.
A high-risk action (fund transfer, policy override, data export) is gated behind a requirement that a human approver's cryptographic signature or signed token accompany the execution request. The agent's verification of that signature is incomplete — it checks presence of a token rather than validity, uses a weak or non-constant-time comparison, doesn't bind the signature to the specific action payload, or doesn't check expiry/single-use — so a forged, replayed, or mismatched approval is accepted as genuine.
Some permissions are conditional on runtime state rather than static role membership — "allow withdrawal only if account balance exceeds the requested amount," "allow this API call only during business hours," "allow escalation only if the ticket is marked P1." The agent evaluates these conditions against stale, cached, or incorrectly fetched data, or implements the comparison logic incorrectly (off-by-one, wrong field, wrong currency/unit), and grants access that the live condition would have denied.
A user grants an agent limited authority to act on their behalf — e.g. "book travel under $2,000" or "respond to routine emails but don't send anything financial." The agent (or a sub-agent it spawns to handle part of the task) continues acting under the user's identity or impersonation token beyond that delegated scope, because the scope was expressed as a natural-language instruction rather than an enforced, machine-checkable boundary on the credential itself.
A role is defined with fine-grained access — e.g. "read-only" or "can create tickets but not delete them" — but the tool wrapper the agent calls exposes the underlying API's full create/read/update/delete surface regardless of which operations the role is actually meant to permit. The agent, having no operation-level gate in the tool itself, can invoke update or delete through a tool nominally scoped to a narrower capability.
Before performing a mutating action on a specific resource (cancel this subscription, delete this file, update this profile), the agent authenticates that a valid user is making the request but never verifies that this specific user is the owner or authorized party for this specific resource. Any authenticated user can therefore direct the agent to mutate resources belonging to someone else simply by supplying that resource's identifier.
Permissions in a hierarchical system are meant to narrow as they cascade down (an org-level admin has broad rights, a team-level member has fewer, a specific user within that team has only what's explicitly granted), but the agent's logic for resolving effective permission at a given level applies the wrong tier's rules — either inheriting a broader ancestor permission that should have been narrowed, or failing to inherit a permission that should have propagated down, resulting in over- or under-granted access.
An agent is deliberately provisioned with read-only access to a data source — the intent being it can look things up but never modify anything — yet a misconfigured tool binding, an overly broad service credential, or an undocumented fallback code path still allows write operations to succeed. The read-only boundary exists in configuration or documentation but isn't actually enforced at the point where the write would occur.
An agent is assigned a role intended to convey a specific level of access (e.g. "support-tier-1"), but the mapping from that role to the underlying tool's actual permission model is incomplete, outdated, or was translated incorrectly during integration — so the agent ends up able to do meaningfully more, or less, than the role's name and documentation suggest. Unlike a missing check, the check exists and runs; it's the mapping table itself that's wrong.
An operation is classified in policy as sensitive or high-risk — deleting a production resource, transferring funds above a threshold, changing a customer's access level — and is documented as requiring human approval before execution. In practice, the agent's execution path has no code-level gate enforcing that requirement: the classification exists as a label or a line in a policy document, but nothing in the tool-dispatch pipeline actually blocks execution pending approval.