Confused Deputy AI Controls for Runtime Delegated Authority

Confused deputy AI controls run every time an agent uses authority that belongs to a service or downstream account, including authority exercised through a tool. The failure begins when a legitimate deputy receives a request, reaches for its broad credential, and acts without resolving whose authority should govern the operation. A clean deployment diagram will not stop that request. Runtime controls have to bind the caller and resource to the action and policy while the operation is still deniable.

I want to keep this operational. A release checklist proves one candidate met its acceptance conditions. The control set below handles the next Monday morning, after permissions change and a new document enters retrieval while an old session remains open on a laptop.

TL;DR

• Resolve the initiating caller on every request and reject unverifiable identity context.
• Derive delegated authority for one resource and action rather than inheriting the deputy's standing privilege.
• Validate token issuer, audience, expiry, and scope at the resource receiving the token.
• Treat user content and retrieved text or tool output as untrusted instructions with recorded provenance.
• Join the model-request record to the action service's separate records for authorization and outcome.

Confused deputy AI controls operate per request

A deputy may perform only an action the resolved caller can authorize in the current context. That decision expires with the request or a short session window. Cached permission results need an explicit lifetime and invalidation path.

NIST SP 800-207 describes least-privilege, per-request access decisions using a policy decision point and policy enforcement point. It also calls for continuing reevaluation during a transaction when policy requires it. For an AI workflow, the model or agent can propose an action. An MCP proxy can do the same. The component controlling the target resource remains the enforcement point that can permit or deny the effect.

A confused deputy acceptance checklist supplies the pre-release gate. Production begins after that signed decision.

Control 1: resolve the initiating principal

Authenticate the human or workload at the application entry point. Apply the same requirement to an agent, then carry a verifiable subject identifier into each policy decision. Signed tokens or server-side session lookups can do this. Caller-provided fields such as X-User-Role: admin cannot.

For each request, record the identity issuer and subject. Record the tenant and authentication time, plus the delegation chain. Shared service accounts can transport a request, but they should never erase the initiating principal in the authorization record. When a batch job legitimately has its own authority, name that workload identity and keep its permissions separate from interactive users.

Runtime signal: count requests with missing, stale, or unverifiable caller context. The enforcement point denies them, and the service owner investigates repeated attempts by client and route.

Control 2: derive authority for the target action

Standing credentials make deputies useful and dangerous. Keep the credential narrow, then evaluate the proposed operation against the caller's current entitlement and target resource. Include argument values and approval state within the tenant. A read_record operation needs the record identifier in the decision. A send_email operation needs the recipient domain and relevant data class.

Authorization belongs immediately before the effect. An approved HTTP request to an LLM establishes policy for that model exchange. The tool server separately authorizes the selected tool and arguments, as detailed in MCP tool call authorization. The model's tool choice is input to that decision, never a grant of authority.

Runtime signal: alert on denied action attempts by identity and resource. Include the denial reason. Review any fallback path that executes after the policy service times out.

Control 3: bind tokens to the intended resource

The MCP authorization specification requires HTTP MCP servers to validate tokens issued for their own audience. It also requires authorization on every HTTP request and uses resource indicators to identify the intended MCP server. Those checks prevent a token minted for one service from becoming a roaming credential.

At runtime, validate issuer and signature. Check audience and expiry against the required scope. Reject a token sent in a query string. Refuse tokens issued for an upstream or neighboring service, even when their signatures verify. Refresh and step-up flows should request the minimum additional scope for the operation being attempted.

Runtime signal: monitor audience mismatches, expired-token use, invalid scopes, and repeated refresh failures. A sudden cluster often points to a client configuration mistake or attempted replay.

Control 4: separate instruction provenance

An agent reads user content and retrieved documents. It also reads email and websites, along with tool results. Each span carries different authority. Label those sources before they enter the model context, and preserve the labels in the request record. Retrieved text can supply facts. It cannot silently become the operator's instruction.

The practical policy checks the assembled prompt for sensitive data and instruction-like content associated with untrusted provenance. If a retrieved customer ticket tells the agent to export all accounts, the next action still faces authorization at the target service. Prompt inspection reduces exposure, while action authorization contains the effect.

Runtime signal: track detected instruction patterns by provenance class and the resulting model-request decision. Track any later action attempt sharing the same correlation ID.

Control 5: prohibit token passthrough

MCP's security best practices call token passthrough an anti-pattern. A server that accepts a token minted for another service and forwards it downstream loses audience separation and weakens accountability. The same guidance requires per-client consent in the documented OAuth proxy confused-deputy scenario.

Use a deliberate delegation or token-exchange design when a deputy must call another resource. The resulting credential should identify the target resource and carry only approved scope. It should expire quickly. Keep the original client token out of downstream logs and headers.

Runtime signal: scan service telemetry for foreign token audiences and direct forwarding patterns. Rotate any credential exposed through a passthrough path and revoke affected sessions.

Control 6: expire, revoke, and reevaluate authority

Permissions change while sessions remain active. Set short token lifetimes for privileged operations. Reevaluate authorization when the target resource changes, and invalidate cached policy when a role or tenant mapping changes. High-impact actions can require fresh authentication or explicit approval.

Test revocation continuously with synthetic identities. Remove an entitlement and repeat the action. Measure the time until denial. The useful service objective is the revocation window, not the speed of a dashboard update. A permission system without a measured revocation path is a directory, not a runtime control.

Runtime signal: publish revocation latency and stale-cache denials. Include privileged actions completed after an entitlement change.

Control 7: join decisions without collapsing them

Assign one correlation ID at the workflow entry point. Carry it into the HTTP model request and the agent's proposed action. Keep the same ID on the action service's authorization decision and the downstream outcome. Each component writes its own policy version and timestamp. It also records the resolved identity, target, and result.

The joined trail should preserve distinct decisions. An allowed model request and a denied tool call describe a working control chain. Combining them into one generic success event destroys the very evidence an investigator needs. The MCP confused deputy attack gives the attack path; the production record shows exactly where the path stopped.

Runtime signal: measure records that lack a correlation ID and action decisions with no initiating identity. Also measure effects with no matching authorization event.

DeepInspect

DeepInspect governs authenticated HTTP traffic intentionally routed between users or agents and LLM endpoints. At that boundary it can evaluate caller context and prompt content. It can also evaluate provenance metadata, model destination, and policy. It can block or redact the model request and preserve a per-decision record linked to the workflow correlation ID.

Downstream tool execution remains outside that LLM request boundary. DeepInspect does not turn an allowed model request into permission for an MCP tool or database query. The same limit applies to a third-party API action. Join its model-request record to the action service's own authorization and outcome records, then operate both control points continuously. Book a demo today.