The Permission Layer: Securing Tool-Using AI Agents

Tool-using AI changes the security question from “Can the model reveal something harmful?” to “Can this chain of identities perform an unauthorized action?” A secure permission layer must identify the human, workload, agent instance, tool service, target resource, and delegated authority; evaluate policy at the moment of action; issue the narrowest usable credential; and preserve evidence for revocation and investigation.

Prompts are not access controls. A system message that says “never delete production data” can reduce accidental requests, but it cannot replace a deny rule at the tool or resource. Least privilege must survive prompt injection, model error, replay, a malicious connector, and a compromised downstream service.

Map the complete identity and authority chain

A tool call may involve several principals:

the human or business process requesting work;
the host application and its authenticated session;
an agent or workflow instance;
the model provider, which may propose an action but should not own a production credential;
the tool gateway or MCP server;
the downstream service identity;
the resource and tenant being accessed.

Record which principal acts on behalf of which other principal. Do not collapse all calls into one “AI service account.” A shared administrator credential makes it impossible to apply user-specific policy, revoke one agent, or explain responsibility.

The February 2026 NCCoE paper on software and AI agent identity and authorization is an initial public draft, not a final NIST standard. It identifies current questions around identification, authorization, auditing, non-repudiation, and prompt injection. Use it as a planning signal and discussion framework, not as a claim of compliance. Our agent identity and authorization guide develops the implementation pattern in more detail.

Authorize the action, resource, and context

Coarse roles such as agent-user or admin are inadequate. A decision should combine:

caller, delegated subject, tenant, and workload identity;
tool, operation, and exact target resource;
argument constraints such as amount, row set, repository, or recipient;
environment, time, device or workload posture, and network path;
data classification and purpose;
workflow state, evidence, risk score, and approval artifact;
rate, cumulative budget, and anomaly signals.

Role-based controls are useful for baseline eligibility. Attribute- or relationship-based rules narrow that eligibility to the customer, project, record, or region the caller is assigned. A relationship such as “account manager for customer 42” must be resolved from an authoritative system, not inferred by the model.

Default deny. Publish only tools the current principal could plausibly use, but still authorize every call at execution. Hiding a tool from the model reduces attack surface; it does not enforce access.

Split broad tools into narrow capabilities

Tool design determines permission quality. Replace manage_customer(action, payload) with separate capabilities such as customer.read, customer.update_contact_draft, customer.commit_contact, and customer.export. Separate draft from commit, internal change from external communication, and additive update from destructive action.

Apply constraints in the tool:

allowlisted fields and destinations;
row-level and tenant-level filters;
maximum amount or batch size;
path and query restrictions;
safe output encoding;
timeouts, rate limits, and concurrency budgets;
an idempotency key for mutations;
a verification read after commit.

Tool names and descriptions are untrusted metadata. Validate the server owner, package, schema, network destinations, and observed behavior before approval. Re-review when a schema expands, a new domain is contacted, or an operation changes from read-only to state-changing.

Issue scoped, short-lived, audience-bound credentials

Never expose a long-lived production secret to the model context. The host or broker should obtain a short-lived credential after policy approval and deliver it only to the executor. Scope it to the resource, operation, tenant, and lifetime needed.

For remote MCP servers, the MCP 2026-07-28 authorization specification requires resource identification and server-side token validation. RFC 8707 Resource Indicators explains why a client should identify the target protected resource so the authorization server can audience-restrict the token. A token intended for the CRM MCP server must not be accepted by the finance server.

The OAuth 2.0 Security Best Current Practice, RFC 9700, recommends privilege restriction and stronger defenses against replay. Where the risk and infrastructure justify it, RFC 9449 DPoP can sender-constrain an OAuth token to a key so possession of a leaked bearer value alone is insufficient. DPoP does not cure a compromised client that also loses the key; it is defense in depth.

Prohibit token passthrough and confused authority

An MCP server or tool proxy must not accept a token meant for another service and forward it downstream. The official MCP security best-practices guide calls token passthrough an anti-pattern. It breaks audience boundaries, bypasses local controls, muddles logs, and can create a confused deputy.

Use two authorization relationships:

client to tool server, with a token issued for the tool server;
tool server to downstream API, with a separate token issued for that API.

The server validates the inbound subject, audience, scope, expiry, issuer, and policy. It then obtains or uses a separately protected downstream credential, preserving delegation information where the protocol and policy support it. Logs must distinguish the initiating human, the tool server, and the downstream service principal.

For OAuth proxies, require per-client consent before forwarding into a shared upstream client flow. Validate redirect URIs exactly, bind state to the request, and prevent a prior consent cookie from silently approving an attacker-controlled client.

Make approval specific, informed, and expiring

Human approval is required when the policy cannot safely authorize an action automatically. It should occur after arguments are validated but before a credential is issued or a side effect is committed.

Show the approver:

the initiating user and represented organization;
exact tool, target, and action;
redacted but decision-relevant arguments;
source evidence and uncertainty;
external recipient, amount, or affected record count;
whether the action is reversible and how;
permission requested and duration;
why policy escalated the case.

Bind the decision to a cryptographic digest of the canonical request, approver, policy version, and expiry. A changed recipient or amount invalidates approval. High-risk actions may require step-up authentication, separation of duties, or two-person control. See human approval design for patterns that avoid fatigue and rubber-stamping.

Apply zero trust to tools, including internal ones

NIST SP 800-207 Zero Trust Architecture states that network location or ownership should not create implicit trust and shifts protection toward resources. Apply that principle to an agent calling an internal tool: authenticate and authorize each relevant request, inspect resource and principal context, and continuously evaluate signals.

A local MCP server is especially sensitive because it may run with the host user’s filesystem and process privileges. Use a sandbox, explicit directory grants, network egress policy, environment-variable filtering, package verification, and a clear installation consent screen showing the exact command. Prefer stdio for a single local client; if a local HTTP endpoint is unavoidable, authenticate it and protect it from other processes and browser-based attacks.

Server-side URL fetching also needs zero-trust treatment. Validate OAuth metadata and tool-supplied URLs with a mature parser, block private, loopback, link-local, and cloud metadata ranges unless explicitly required, validate redirects, and route outbound traffic through an egress policy.

Validate every input and distrust every output

Schema validation is necessary but not sufficient. Enforce business invariants after parsing: a positive amount may still exceed the caller’s limit; a syntactically valid URL may still target an internal administrator service; a valid SQL string may still access forbidden tables.

Normalize before policy evaluation so alternate encodings cannot bypass rules. Cap object depth, string and array length, regex cost, query execution, file size, decompression ratio, and response size. Sanitize tool output before placing it in model context. Separate returned data from instructions and never allow a tool result to redefine system policy.

The OWASP Top 10 for Agentic Applications 2026 offers a current threat taxonomy that includes goal hijacking, tool misuse, excessive agency, memory poisoning, unexpected code execution, cascading failures, and insufficient traceability. Turn these categories into adversarial tests for the whole chain rather than claiming that an OWASP reference makes the system secure.

Make mutations idempotent and budgets cumulative

A permission may be narrow per call yet dangerous in aggregate. Limit cumulative spend, records touched, messages sent, exports created, and tool invocations per workflow, user, and time window. Parallel agents should draw from the same centrally enforced budget.

Mutating calls need an idempotency key bound to the business intent and request hash. If the response is lost after commit, the executor queries the prior result rather than repeating the action. Reject reuse of a key with different arguments. A model’s request to retry cannot override the retry budget.

Rate limits should distinguish benign throughput from suspicious shape: new recipients, broad scans, sequential identifiers, sudden nighttime volume, repeated denials, and cross-tenant probes. Policy should be able to step down from automatic execution to approval or deny as risk changes.

Log enough to revoke, investigate, and prove

An audit record should connect intent to outcome:

workflow and correlation identifier;
human, workload, agent instance, tool server, and downstream principals;
delegated subject and tenant;
tool and schema version;
policy version, decision, reasons, and evaluated attributes;
approval artifact and authentication strength;
credential issuer, audience, scope, and token identifier—not the secret;
canonical request hash and idempotency key;
redacted arguments, result class, latency, retry, and verification;
compensation, user correction, and final business state.

Protect logs from tampering and excessive access. Tokenize sensitive identifiers, encrypt evidence, keep credentials and full private prompts out of standard telemetry, and apply purpose-specific retention. A trace that cannot be searched during revocation or incident response is not operationally useful.

The current NIST AI Agent Standards Initiative includes research on agent authentication and identity infrastructure and security evaluation. As standards evolve, a clean identity and evidence model makes it easier to adopt stronger interoperable controls without rebuilding every workflow.

Build revocation and rollback before launch

Revocation must work at several levels:

end one user grant or agent instance;
revoke a token, client, certificate, or signing key;
disable a tool, operation, tenant, or destination;
roll back a schema or policy version;
compensate the business action in the system of record.

Keep short token lifetimes, introspection or revocation paths where supported, key rotation, and a deny list for urgent containment. Feature flags should stop new side effects without destroying evidence or in-flight checkpoints. If a tool is compromised, quarantine its output and memories derived from it, not only future calls.

Test the incident path: stolen token, leaked signing key, malicious tool update, poisoned output, mistaken approval, and duplicated transaction. Measure the time from detection to blocked action, credential revocation, affected-case identification, compensation, and safe restoration.

Measure permission quality, not only denial volume

Track:

unauthorized successful actions and cross-tenant exposure;
overprivileged grants and unused scopes;
token lifetime, audience, and sender-constraint coverage;
correct denials versus policy false positives;
approval rate, latency, abandonment, and argument-change reapproval;
attempts to bypass policy through encoding, tool output, or prompt injection;
duplicate side effects and cumulative-budget breaches;
mean time to revoke and contain;
percentage of actions with complete identity and evidence chains;
user productivity, task completion, and cycle-time improvement.

A high denial count may mean strong defense or a badly designed tool. Review samples with business owners and security. Shrink broad capabilities, improve policy data, and automate only stable low-risk cases. Do not loosen controls merely to improve completion.

Stage deployment and review suppliers

Begin with read-only tools in a test tenant. Add reversible draft actions, then approved external actions, and only later tightly bounded straight-through execution. Shadow policy decisions before enforcement to find missing attributes, but never shadow a control whose absence could expose real data.

Assess third-party tools and MCP servers for ownership, update process, signing, vulnerability response, data handling, sub-processors, network destinations, credential storage, tenancy, logging, deletion, and emergency disablement. Require notification when schemas or permissions change. Our AI vendor risk and procurement guide provides a broader due-diligence structure.

The permission layer is successful when it gives a useful workflow exactly enough authority for exactly long enough—and can explain, stop, and reverse that authority without disabling unrelated work.

Source notes

Substantive review completed 2026-07-30. Protocol and credential guidance was checked against current MCP authorization and security documentation and IETF OAuth standards. The NIST zero-trust publication is final. The February 2026 NCCoE agent identity concept paper is explicitly an initial public draft with a closed comment period, not a final standard. OWASP’s 2026 list is used as a threat framework, not a certification.