Confused Deputy AI Checklist: A Release Gate for Delegated Authority

A confused deputy AI checklist should end with a release decision. The candidate workflow either proves that every privileged action stays inside the initiating caller's authority, or it stays out of production. Picture the review room with two browser sessions open: a support analyst in one, a finance administrator in the other, both sending the same request. If the traces converge on one broad service credential and produce the same privileged result, the deputy has erased the caller boundary.

This gate applies before initial release and after a material change to identity or model route. Changes to tool inventory or OAuth configuration also reopen it, as do changes to retrieval scope or downstream credentials. Runtime monitoring begins after acceptance. Mixing those jobs creates a checklist that never closes and a production control set that nobody owns.

TL;DR

• Define the candidate and trust boundaries before testing begins. List the privileged actions too.
• Trace one verified caller identity through every delegation and authorization decision.
• Prove that tokens have the intended audience and the narrow scopes required for the action.
• Run cross-role, cross-tenant, injected-instruction, stale-token, and revocation tests with recorded outcomes.
• Release only with a signed evidence pack and named exceptions. Include a material-change trigger.

Confused deputy AI checklist acceptance gate

The acceptance unit is one versioned workflow. Name the application build and agent configuration. Record the model route and MCP servers. Include the downstream services and identity provider, then identify the policy bundle and credential set. Freeze that candidate while the tests run. A green result against Tuesday's tool manifest says nothing about a server added on Friday.

Write the decision in advance. The available dispositions are release or hold. A release may carry a time-bounded exception. I would hold any candidate whose action log identifies only a shared service account. That log proves the deputy acted and leaves the person or agent behind the request unresolved.

The MCP confused deputy attack explains the failure mechanism. This checklist starts after the architecture has been selected and asks for acceptance evidence against one candidate.

1. Fix the caller and resource identities

Record the authenticated human or workload identity at the workflow entry point. Then list every deputy that can act with separate authority: the agent process and MCP proxy, plus the tool server and retrieval service. Include the downstream API client. Each hop needs an issuer and subject. It also needs an audience and expiry, plus a correlation identifier that a reviewer can inspect.

The MCP authorization specification treats a protected MCP server as an OAuth resource server. It requires tokens intended for that server and authorization on every HTTP request. Acceptance evidence should include a decoded test token with secrets removed and the validation configuration. Include a rejected token minted for another resource.

Pass condition: every deputy can bind its request to the initiating caller or to an explicitly approved workload identity, without trusting a caller-written header.

2. Bound delegated authority before the action

Build an authority matrix for each privileged action. Each row names the caller role and resource. It also records the permitted operation and argument constraints. Add the approval requirement and credential used downstream. The matrix needs enough detail to distinguish read_customer for account 1842 from a query across the customer collection.

NIST SP 800-207 defines zero trust around least-privilege, per-request access decisions. It also states that authorization to one resource does not automatically grant access to another. Apply that rule at every action service. An approved model request gives no authority to send an email or change a ticket. It also gives no authority to read a different tenant's records.

Pass condition: each privileged action has a pre-execution decision against the resolved caller and target resource. The decision also covers the submitted arguments.

3. Verify consent, scopes, and token audience

For OAuth-backed MCP proxies, inspect the consent flow rather than accepting a successful login screenshot. The MCP project's security best practices require per-client consent before a third-party authorization flow in the documented proxy scenario. The guidance also rejects token passthrough and requires the server to accept tokens issued for itself.

Capture the registered client identifier and exact redirect URI. Record the requested scopes and resource indicator. Include the token audience and expiry, along with the revocation path. Attempt a redirect URI variation and a token for a neighboring service. Both attempts should fail before a privileged operation begins.

Pass condition: the candidate requests only approved scopes and binds consent to the actual client. It validates the target audience and rejects token reuse across resources.

4. Run adversarial authority tests

Use test identities with intentionally different rights. The evidence pack should contain at least these negative cases:

• A low-privilege caller asks the deputy for an administrator-only action.
• Tenant A supplies a resource identifier belonging to tenant B.
• Retrieved text or a user message instructs the agent to call an unapproved action.
• A permitted action receives an argument outside the caller's allowed range.
• An expired or revoked token is replayed during an active session.
• The policy service or identity lookup becomes unavailable.

Record the request ID and resolved identity. Include the target and policy version. Add the decision and downstream effect, followed by the test timestamp. A red banner in a test console is weak evidence. The authoritative downstream system should show that the denied write or read never occurred.

Pass condition: every negative case fails closed, and the evidence links the denied request to the absence of a downstream effect.

5. Prove revocation and change handling

Revoke one caller's entitlement while a session remains active, then repeat the privileged request. Rotate a downstream credential and confirm that the old credential stops working. Remove one tool or model route and verify that stale clients cannot keep using the prior policy state.

The release record should also define material changes. New tools or broader scopes reopen this gate. So do changed redirect URIs or different identity issuers. Altered tenant mapping and new downstream credentials also require reassessment. A model-version change belongs here only when it changes tool selection or identity handling. A change to the governed request shape also qualifies.

Pass condition: revocation takes effect within the documented window and stale authority fails. The owner also has a dated list of changes that force reassessment.

6. Sign the evidence pack

Package the frozen architecture diagram and authority matrix. Include token-validation evidence and negative-test results. Add the exception register and rollback owner. The security owner signs the control result. The application owner signs that the tested candidate matches the release artifact. Any exception needs an expiry date and a narrower compensating control.

The bounded artifact covers one candidate and one evidence set. It records one disposition. Recurring controls take over after release. MCP tool call authorization separates the model-request decision from the tool server's own action decision, which prevents one green log entry from standing in for the full chain.

DeepInspect

DeepInspect contributes evidence at one specific boundary. For HTTP AI traffic intentionally routed between an authenticated user or agent and an LLM, it evaluates the application-supplied identity context and prompt content. It also evaluates the model destination and policy version before the request proceeds. Its per-decision record can prove the outcome for that model exchange.

The action service still authorizes its own tool call and database query. It also authorizes each file operation or third-party API request. DeepInspect does not validate an MCP token merely because the MCP transport uses HTTP, and it does not replace downstream authorization. Include its request record as one linked artifact in the acceptance pack, alongside the action service's separate decision. Book a demo today.