A secure OAuth token proves that an agent can reach a tool. It does not prove that the agent should take a specific action.
Untrusted content can influence tool choice or arguments. A valid token can then authorize destructive, costly, or data-exposing requests.
Agent security and tool calling mean treating every tool request as untrusted. Deterministic policy must verify delegated identity, intent, arguments, destination, permissions, and business impact.
OAuth scopes alone are insufficient. Require strict schemas and allowlists. Apply spend and rate limits, require approval for high-risk changes, and keep immutable evidence logs.
A token is not authorization for agent actions
A service token proves that a workload can reach an API. It does not prove that a specific agent action is allowed.
Treat each proposed call as untrusted until a policy enforcement point checks the full request context. A policy enforcement point is a control that makes and enforces access decisions.
This applies Zero Trust Architecture directly. Do not trust a request because it came from an approved application or internal network.
John Kindervag introduced Zero Trust at Forrester Research. NIST SP 800-207 later described the same enterprise discipline.
Continuously verify access instead of granting broad, permanent trust.
The most frequent error is giving an agent a persistent service credential. Teams do this because the backend already uses OAuth 2.0.
That credential is like giving a hotel concierge a master key. You then assume every note they receive is a valid guest request.
A tool token usually proves an application, workload, or user identity to an API. It may carry scopes, such as read:customers or write:invoices.
It usually does not prove that the right person requested a specific action. It also does not prove that the request targets the right customer account.
Separate three identities in every design. Track the employee or system that delegated authority, the agent runtime, and the receiving tool.
A useful authorization record links all three identities. Without that chain, investigators cannot establish who authorized an API call.
Short-lived, just-in-time access is safer than broad credentials stored for weeks or months. Many production designs use token lifetimes between 5 and 15 minutes.
The policy gate must still decide whether each call is allowed. A short token does not make a bad request safe.
Which decisions must happen per call?
Per-call authorization should check who delegated, what action the agent requests, and which resource it targets. It should also check authority duration and relevant business conditions.
This is agent authorization, not merely agent authentication. Authentication proves identity. Authorization decides what that identity may do now.
Identity and access management, multi-factor authentication, OpenID Connect, and OAuth 2.0 remain essential. They establish identity and issue tokens.
They do not decide whether delete_customer_data, send_wire, or change_firewall_rule is appropriate. That question matters after an agent reads a hostile email.
A defensible rule: A model may propose a tool call. Only deterministic policy may authorize it. The model must never reinterpret a deny decision.
This distinction addresses the credential problem. The next problem is harder: untrusted text can shape a valid request.
Short-lived tokens reduce the exposure window. They do not remove the need for credential lifecycle controls.
Each credential used for tool-call authorization needs an owner and intended audience. It also needs a maximum lifetime, revocation path, and automated rotation.
For example, a gateway may detect a billing token at a storage export API. It should revoke the session grant, deny the call, and alert security operations.
AI agent security also needs scheduled client-secret and signing-key rotation. Avoid shared static credentials.
Invalidate delegated grants when an employee changes roles. Do the same when a tool is compromised or a task ends unexpectedly.
The highest-risk attacks begin with indirect prompt injection. Hostile content causes a trusted agent to select a valid tool.
The model does not need to be hacked. It only needs to mistake hostile content for an instruction.
An indirect prompt injection is an instruction hidden in content that an agent reads. That content can be a web page, ticket, PDF, shared document, or email.
For example, a ticket may contain hidden text. It may tell the agent to export customer records to an external URL for “verification.”
A wrong answer is inconvenient. A wrong answer followed by a production API call can cause a reportable security incident.
How does indirect prompt injection become action?
The path usually has four stages. The agent retrieves external content, the content changes the model plan, the model selects a tool, and the application executes the call.
External content can be useful evidence, but it must never become an authorization source.
A common case involves a support agent connected to CRM and email tools. A malicious ticket asks it to “verify account ownership.”
The ticket asks for a customer export to a new address. The email API token may work, but the request can still violate consent rules.
The National Institute of Standards and Technology treats this as a risk-management issue. It is not only a model-quality issue.
The NIST AI Risk Management Framework supports governance across real operating contexts. This includes harmful outcomes from connected systems.
Tool poisoning happens when tool metadata steers a model toward unsafe behavior. The metadata may include descriptions, parameter hints, catalogs, or server responses.
A malicious Model Context Protocol server may call an export function “required diagnostics.” It may hide that the function sends data to another tenant.
Do not let a tool decide whether it is authorized. Tool metadata is input, not policy.
The authorization service must use its own approved inventory and action taxonomy. It also needs schemas and destination allowlists.
Guidance from NIST, CISA, OpenAI, Anthropic, Microsoft, Google Cloud, and AWS repeats one practical rule. Keep sensitive actions outside the model’s discretionary control.
The agent may ask for an action. A separate system must decide.
Which calls create the greatest harm?
Prioritize controls for external exports, privilege changes, payments, customer messages, production changes, and deletion. These calls combine broad reach with costly or public side effects.
Excessive agency means giving an agent broad permissions and an open-ended goal. It also means letting it act without a meaningful stopping rule.
It is like asking a temporary contractor to “fix purchasing.” Then you give them every vendor, bank account, and approval queue.
The risk model now has a clear requirement. A decision point must inspect each proposed call before production receives it.
A contextual policy gate should allow, deny, require approval, or route each request to a sandbox. It must use verified identity, authority, action type, arguments, resource scope, and business risk.
This is the control most security reviews expect before production access. It checks the call before it reaches a mutable system.
Place the gate between the agent runtime and downstream API. The model emits a proposed function call.
A gateway canonicalizes the call and evaluates policy. It gets approval when needed, then mints or uses narrow credentials.
This design matches NIST SP 800-207 Zero Trust Architecture. The policy decision point decides, while the enforcement point blocks or permits requests.
It also supports federal expectations under Executive Order 14028 and OMB Memorandum M-22-09. These rules matter in many U.S. federal and regulated settings.
Who may delegate authority?
Authority should start with a known user, approved service workflow, or governed business process. Bind the agent identity to its delegate, task, tenant, resource set, and expiration.
Do not let an agent inherit a broad backend role. Broad roles hide who approved each sensitive action.
Use role-based access control as the base entitlement layer. Then add attribute-based access control for context checks.
Attribute-based access control checks facts such as tenant, data class, device state, region, time window, and approval status. A finance analyst may view invoices but not pay an unapproved recipient after hours.
Just-in-time access works when an agent needs elevated rights for one defined step. The policy service can issue a narrow grant for one action and resource.
That grant should expire after the call. Short grants reduce the value of stolen credentials.
What belongs in an allow decision?
A complete decision checks the action, tenant, resource owner, and data class. It also checks destination, session assurance, time limit, approval state, and projected impact.
Policy should check the agent and tool versions. Behavior can change after a deployment.
The error most often missed in reviews is authorizing the verb but not the object. Allowing send_email means little without checking recipients, attachments, sender identity, and external delivery.
A decision response should be structured, not conversational. Use deny, allow, allow_with_limits, require_approval, or sandbox.
The model should receive only the outcome and safe error details. It must not edit policy inputs or retry hidden alternatives.
How should the request flow work?
A secure flow is easy to audit. Capture delegation, parse the call, normalize arguments, evaluate policy, collect approval, and execute with constrained credentials.
Record evidence at every stage. Each stage should share one request ID across systems.
For a U.S. company operating in Washington, D.C., and California, export rules may vary. A support agent might view one customer record without approval.
The same agent should need approval for exports above 100 records. It should also need approval for destinations outside approved company domains.
Local privacy duties differ, but the authorization pattern remains the same. A policy gate is only as reliable as its inputs.
The next control makes model-created arguments safe enough to evaluate.
Normalize arguments before production sees them
Normalization converts different representations into one canonical form. Think of it as requiring one address format on every shipping label.
A warehouse needs that format before deciding where a package goes. A policy engine also needs clear values before it can decide safely.
It cannot safely compare unclear URLs, encoded paths, aliases, or natural-language amounts. Attackers often hide dangerous targets inside those fields.
This works well in theory, but unsafe calls often pass through “metadata” fields. Query filters, redirect URLs, attachment links, cloud account IDs, and file paths can change real effects.
Which fields need strict schemas?
Validate action names, enums, IDs, URLs, file paths, account numbers, query filters, currency, amounts, and deletion scope. Use a typed schema for every field.
Reject unexpected fields, wildcards, malformed types, duplicate keys, and encoded destinations. Also reject natural-language instructions hidden inside arguments.
For example, create_payment should include a recipient ID from an internal registry. It should include cents, a three-letter currency code, an invoice ID, and an idempotency key.
It should not accept an arbitrary bank account string from retrieved text. Retrieved content is evidence, not a payment instruction.
Schema validation alone is not enough. A valid delete_records object might request 50,000 records instead of one.
Business limits must check meaning and likely impact. Valid syntax does not guarantee safe intent.
How do allowlists stop destination abuse?
Allowlists should cover approved SaaS tenants, cloud accounts, repositories, domains, payment recipients, and production resources. Resolve redirects and aliases before the final check.
Also resolve shortened URLs, nested IDs, and cross-account references. The final target matters more than the first supplied string.
A safe policy may allow https://api.company.com but deny an external object-store redirect. It may allow one AWS account but deny cross-account role assumption.
API security controls must inspect the final resolved target. Checking only the original agent input is not enough.
Which business limits override permission?
Business limits should cap payment size, messages sent, exported records, deletion count, API calls, and concurrent actions. Apply caps by user, agent, tenant, and session.
Typical initial limits range from 10 to 100 records per export. Unattended payments often start between $100 and $1,000.
Business owners should approve higher risk tiers. Limits should match the cost of a mistake.
Policy can restrict production changes to a maintenance window. It can also require a dry run first.
An administrator may still be blocked from changing network rules during an active incident. They may also be blocked from deleting too much of a dataset.
Once requests are deterministic, teams can choose autonomy with discipline. They no longer need to guess from model confidence.
Choose block, approval, sandbox, or autonomy
Use a risk matrix for reversibility, privilege, data sensitivity, financial impact, destination trust, and validation quality. Map each result to block, approval, sandbox, or autonomous execution.
The matrix must be a live product control. It should not become a forgotten threat-model document.
Human approval for every action does not last. It creates queues, rubber-stamping, and delayed operations.
Fully autonomous execution is also unsafe for mutable tools. The useful middle ground limits autonomy to low-blast-radius actions with strong verification.
| Decision | Use when | Required controls | Example |
|---|
| Block | Unknown target or hard limit exceeded | Deny, alert, preserve evidence | Export to an unapproved domain |
| Approval | Sensitive or irreversible impact | Bound approval, expiry, dual control where needed | Payment above $1,000 |
| Sandbox | Untrusted content or high-variance output | No production secrets, isolated network | Code from a public repository |
| Autonomous | Read-only, narrow, reversible request | Schema, allowlist, rate cap, audit log | Read one assigned ticket |
When should policy block a call?
Block calls to unknown tools, unapproved destinations, malformed arguments, or unverified resource ownership. Also block privilege changes outside policy and requests above hard limits.
A block must be final for that request. The agent cannot turn it into a similar call without a new evaluation.
Block when required evidence is missing. If the system cannot confirm delegation, tenant boundary, or target ownership, it should fail closed.
This matters in CMMC 2.0 and FedRAMP-bound settings. These settings require proof of controlled access, not only claimed controls.
When is approval or sandbox better?
Require human approval for payments, external messages, regulated exports, production changes, and irreversible deletion. Bind approval to normalized arguments, the approver, target, and short expiry.
Approval windows often last between 5 and 30 minutes. Long approval windows create replay risk.
Use secure sandboxing for unfamiliar tools, untrusted documents, code execution, and exploratory queries. Microsegmentation must separate sandbox paths, credentials, and data access from production.
The best practical rule is simple. Autonomous actions should be low-impact, narrow, reversible, and independently verifiable.
Immutable evidence logs keep approved actions from spreading too far. They need more than a final allow or deny result. Record the correlation ID, delegated identity, and agent and model version.
Also record tool and server version, normalized arguments, resolved destination, policy version, and risk score. Store the approval record, credential audience, decision, result, and idempotency key.
Use a privacy-preserving hash when raw arguments contain sensitive data. For blocked calls, retain the rule and safe reason code.
Do not store unnecessary sensitive prompt content. Evidence should support review without creating another data leak.
For example, an export to an unapproved domain should create a searchable event. The event should link the task, destination, denied condition, and later human review.
This creates an auditable chain for incident response, compliance review, and root-cause analysis.
Contain mutable calls and secure MCP
An idempotency key makes repeated requests produce one intended outcome. It prevents duplicate side effects after retries.
It is essential for payments, provisioning, deletion, and workflow triggers. Agents may retry after timeouts or unclear tool responses.
A common platform-review case involves an agent that creates a ticket correctly. It then retries the same external notice after a timeout.
Without idempotency and a rate cap, one unclear response can send dozens of messages. It can also create duplicate charges.
How do budgets and kill switches work?
Set budgets for dollars spent, changed records, exports, messages, API calls, and concurrent actions. Alert when a session reaches 60 to 70 percent of its budget.
Require approval before the agent reaches the hard cap. A budget should stop damage before finance or customers notice it.
A kill switch should disable one tool, agent version, tenant, MCP server, or all mutable calls. It should keep safe read-only work available when possible.
Test the switch during incident exercises. A switch that exists only in a runbook is not a containment control.
Prefer compensating actions, staged deployment, and dry-run modes when rollback is possible. Some actions cannot be undone.
Sending regulated data to an external party cannot be undone. Those actions belong in the approval tier.
Learn more
Here are some additional resources on this subject:
