Work type: Research analysis and engineering review design. Evidence: An existing published article, primary research, and the review matrix below. Scope: AI assistants that connect to multiple tools through MCP.
The problem
A useful assistant can read information and act on it. That also creates a security question: can content from one integration influence an action performed through another?
Invariant Labs demonstrated tool poisoning and cross-server influence: malicious tool metadata could influence an agent to access sensitive data or alter another tool’s behavior. These are their discoveries and experiments. My existing MCP article examines those attack patterns and their implications for application security.
My contribution
The contribution is analysis: connecting the attack patterns to the boundaries an engineering team needs to review. The article covers tool descriptions, tool outputs, changes after initial approval, and the gap between a user’s intended action and the arguments an agent actually submits.
This case study adds a review matrix to make that analysis easier to use in a design review. The matrix is a proposed verification plan, not evidence that a particular host has passed it. The review matrix was prepared with AI assistance. Its checks remain proposed and unexecuted.
Approach
Start with a narrow user action, such as drafting a message. Identify every component that can read private context, select a recipient, or send the message. Then ask which component can enforce the user’s intended scope even if the model follows an injected instruction.
| Boundary | Failure to investigate | Engineering implication |
|---|---|---|
| Tool metadata to model context | A description tries to redirect behavior | Treat metadata as untrusted input; limit capabilities outside the model |
| One integration to another | A low-trust source influences a privileged action | Scope credentials and action permissions by task and integration |
| Approval to execution | Arguments change after the user reviews them | Bind approval to the actual action and final arguments |
| Approved integration to updated integration | Tool definitions change after review | Detect changes and require renewed review before granting access |
| External content to outbound action | Retrieved text tries to redirect a destination | Enforce destination and data policies at the action boundary |
Prompt instructions and suspicious-text filters can help, but neither is an authorization boundary. The more useful question is what the tool executor will refuse regardless of the model’s proposed action.
Supporting artifact
Download the engineering review matrix (CSV). It pairs five scenarios with controls, expected behavior, and evidence to collect. Each row is explicitly marked proposed; not executed.
Use synthetic content, reserved example addresses, and a mock tool executor when running these checks. Record host and model versions, configuration, final tool arguments, allow/deny decisions, and repeat-run outcomes. A successful baseline matters: a control that blocks every useful action has not demonstrated a workable design.
Result and limitations
The result is an inspectable analysis and a concrete review plan. It shows how I reason from an attack mechanism to engineering requirements and falsifiable checks.
This work does not establish a new vulnerability, a tested fix, a deployment, or a measured reduction in risk. I have not reproduced the cited experiments for this case study. The matrix does not model OAuth flows, transport security, every injection technique, or the behavior of a specific current MCP host. Published demonstrations are evidence of the reported attack patterns, not proof that every present-day integration is vulnerable.
Why this matters for AppSec and security engineering
An attack narrative is useful when it changes a design decision. Here, it turns “review this plugin” into specific questions: what can it access, what can change after approval, what authorizes an outbound action, and what trace proves the control worked?
Those questions connect offensive analysis to design review, least privilege, regression testing, and incident investigation. They also keep the assessment honest about what was observed and what still needs verification.