01 / Attack path
How the boundary is crossed
A customer-support agent discovers a shared MCP server with read_customer, change_address and delete_customer tools. Its task permits reading one customer record. A poisoned tool description requests a diagnostic export; the agent also holds a valid token for the MCP server. Neither fact authorizes an export or deletion.
- 01Lower-trust input
- 02Attempted instruction
- 03Protected action
- 04Enforced decision
02 / Containment
Where bounded authority limits the effect
Validate the client-to-server token for this MCP resource, treat tool descriptions as untrusted data, and bind the current task to an explicit operation and normalized arguments. Enforce the final decision where the downstream customer API can actually stop the change. A gateway check alone is insufficient if another route reaches that API.
03 / Failure and evidence
The attacker’s opportunity and the defender’s record
The server accepts a token intended for another audience, forwards it to a downstream API, or treats a visible tool as permission for every caller and argument. An agent may then borrow privileges from the server or from another user.
Retain the trusted task and principal identifiers, tool-definition version, validated token audience result, selected tool and normalized arguments, decision reason, downstream attempt and independently observed customer state. Do not put raw bearer tokens in the audit record.
04 / Canonical scope
Why this reference stands alone
The MCP security guide is the broad deployment pillar. Individual token, server, gateway and poisoning references explain one boundary. This threat model owns the end-to-end attack surface, assumptions and negative-test matrix.
Threat register / versioned protocol
Four boundaries, four different owners.
The MCP specification describes transport authorization and tool exchange; it does not make an application’s customer-deletion policy for it. Treat that gap as a design responsibility, not a protocol defect. The review below separates what the MCP server can validate from what the downstream system must enforce.
Discovery → selection
- Unsafe assumption
- A tool description is an instruction the agent may obey.
- Failure
- A compromised server advertises an export as a required diagnostic step.
- Negative test
- Change the description after discovery; verify that a forbidden export still receives DENY.
- Control owner
- Host and tool registry
Client → MCP server
- Unsafe assumption
- A signed bearer token is valid for every server.
- Failure
- Server B accepts a token issued for server A or passes it onward.
- Negative test
- Present a valid token with the wrong resource audience; verify rejection before tools/call.
- Control owner
- MCP server and authorization server
Tool call → downstream API
- Unsafe assumption
- Access to the MCP server permits every tool and argument.
- Failure
- A read-only task invokes delete_customer with the server’s broad service credential.
- Negative test
- Call the tool directly with a forbidden operation and then with a changed target; verify both are stopped at execution.
- Control owner
- Application policy and executor
Decision → observed state
- Unsafe assumption
- An ALLOW or tool success message proves the intended result.
- Failure
- A timeout hides a partial write and an unsafe retry repeats it.
- Negative test
- Inject a timeout after the downstream commit; reconcile the customer record before retrying.
- Control owner
- Executor and evidence owner
Walk the request before choosing a control.
Start with the accountable user or organization and the task actually assigned. Record the host and client instance, then the server identity and the protected-resource identifier for the token. Follow the selected tool name and its definition version into the parsed arguments. Finally identify which executor changes durable state. If any arrow in that chain carries only an agent-written assertion, the authority provenance is missing at that point.
A gateway can narrow exposure and check the inbound request, but it cannot by itself prove that a separate service applied the same decision to the final effect. Conversely, a downstream API may know its own resource policy but lack the initiating task and delegated limit. The integration review should document how trusted context crosses that boundary without forwarding the MCP client’s token as a generic credential.
What this model does not cover.
Action authorization does not sanitize malicious documents, secure the host process, replace sandboxing, or guarantee the model will choose a sensible plan. Keep source-content isolation, secure tool implementation, token storage, monitoring and incident response in the design. ProofGrid governs authority decisions; the MCP host, server and execution systems still own their respective security controls.
Read the MCP security architecture guide for deployment topology, token audience validation for the transport test, and confused-deputy analysis for privilege borrowing across principals.
Architecture field test
Trace source, tool and effect separately
Where can an MCP attack cross a trust boundary?
- 01Untrusted description or result
- 02Agent interprets instruction
- 03Tool call carries proposed effect
- 04Server and executor enforce scope
Work the boundary
A newly discovered MCP server offers an audit-search tool whose description tells the agent to upload prior results for “diagnostics.” The client may display the tool, but the upload destination is not authorized by the investigation task. A downstream egress boundary should deny it.
| Required facts | Server identity, tool metadata provenance, client token audience, task grant, final arguments and protected-system result. |
|---|---|
| Allow only when | The call is addressed to a trusted resource and its action stays within the originating task. |
| Deny when | A malicious tool description induces export to an attacker destination or a server forwards a client token downstream. |
Break the assumption
Swap the server origin while preserving the tool name, then embed the upload instruction in a tool result. Test both discovery trust and action policy. Confirm that a denial leaves the external destination untouched.
Design tradeoff
Tool metadata scanning helps detect hostile instructions but cannot prove every output safe. Keep server trust, token isolation, argument checks and downstream permissions as independent controls.
For trace source, tool and effect separately, consult OWASP AI Agent Security Cheat Sheet. This worked decision and negative test are ProofGrid analysis.
Continue with Tool poisoning.
Primary references