The classic confused deputy pattern has a clear multi-agent form: a powerful agent acts on behalf of a lower-trust child or document without preserving whose request it is and which grant authorized the effect.
01 / Read the source
What the primary material says
NSA’s MCP guidance highlights the risk of server-held credentials at tool boundaries. OWASP’s agent-control work addresses runtime mediation. NIST’s agent identity work points to the need for attributable principals and delegation. The combined architectural lesson is to preserve the requester and its authority through the chain, not merely the credential of the component that executes.
A deterministic action gate limits the effect of a malicious or mistaken request; it does not guarantee that the model never follows untrusted instructions. Tool and prompt defenses remain useful. Nor does a log of the deputy’s identity establish the requester’s permission unless the grant chain is recorded and validated.
02 / Architectural consequence
Where the trust boundary changes
A document-extraction child asks its parent to send a customer ledger to an external endpoint. The parent has a messaging tool and a valid credential, but the child’s delegated work is limited to reading assigned invoice documents. If the parent authorizes by its own broad capability, it becomes the deputy.
Do not let the deputy become the source of permission
The parent may legitimately possess a messaging or payment capability for its own assignments. A child’s request must carry its narrower grant, however, and the parent’s decision to help cannot widen that grant. The same pattern appears when an MCP server uses its own database credential for a client. The protected endpoint often sees the deputy, so the system needs a way to evaluate the lower-trust origin before execution and preserve that fact in evidence.
03 / ProofGrid analysis
Authority beyond the credential
ProofGrid’s category thesis makes the grant edge explicit: origin, parent, child, purpose, action and target should be checked together. This narrows blast radius even when malicious content or an agent mistake produces the attempted instruction; it does not claim to prevent every upstream prompt injection.
04 / A testable next step
What a security architect can do
Construct a negative test in which a child requests an operation outside its grant through a more privileged parent. Verify the denial occurs at the actual outbound effect and that the record identifies both requester and executing principal.
Can an untrusted document induce a higher-privilege tool call? Does the executor receive the child task or only the parent credential? Can the parent delegate its full capability by copying a token? The negative test should keep the parent’s legitimate capability while proving the child’s out-of-scope request still fails.
Primary sources
Read the documents
Durable references