Start with three signals: a stored baseline of approved descriptions, runtime diffing against the live version, and validation rules for imperatives or undeclared endpoints. Then tie those signals to agent sessions so a change can be blocked before the tool is invoked.
Why This Matters for Security Teams
mcp tool poisoning is dangerous because the attack surface is not just the tool itself, but the tool’s description, arguments, and declared capability boundary. When an agent trusts poisoned instructions or altered metadata, it can be steered toward unauthorized endpoints, data exfiltration, or privilege misuse without any obvious human click path. That makes this a governance and runtime detection problem, not a cataloguing problem.
Current guidance suggests treating tool definitions as security-sensitive inputs and monitoring them the way teams monitor secrets or policy files. The OWASP OWASP Top 10 for Agentic Applications 2026 and NHI Management Group’s Top 10 NHI Issues both reinforce that attackers increasingly target the control plane around identities and automation, not only the workload itself.
For security teams, the practical challenge is that MCP tool metadata often changes outside normal software release controls, so a poisoned description can enter through a repository, registry, or connector pipeline long before it is noticed. In practice, many security teams encounter tool poisoning only after an agent has already invoked the altered tool, rather than through intentional pre-deployment review.
How It Works in Practice
Detection works best when security teams combine static trust baselines with runtime validation. The first step is to store an approved version of each MCP tool description, including name, purpose, parameters, declared endpoints, and any allowed side effects. The live tool definition is then diffed against that baseline whenever the agent resolves or refreshes the tool catalog. That makes changes visible before invocation.
At runtime, the agent session should be tied to the specific tool version it was allowed to see. If the live definition contains new imperatives, hidden instructions, altered authentication flows, or undeclared hosts, the session can be paused or denied before the tool call is executed. This is similar in spirit to policy enforcement in NIST Cybersecurity Framework 2.0, but applied to autonomous tool use rather than general enterprise control.
Useful detection signals include:
- Unexpected verbs such as “exfiltrate,” “bypass,” or “ignore prior instructions” inside tool descriptions.
- Endpoint drift, where the declared destination no longer matches the approved service map.
- Parameter expansion, especially when new fields appear without review.
- Prompt or instruction stuffing embedded in descriptions, comments, or examples.
- Cross-session reuse of a tool definition that should be versioned or isolated per agent.
NHIMG’s OWASP Agentic Applications Top 10 is useful here because it frames tool manipulation as an agentic control failure, not just a content integrity issue. Teams that also apply strict lifecycle controls from the NHI Lifecycle Management Guide usually get better results because tool registration, approval, rotation, and decommissioning all become auditable stages.
These controls tend to break down when tools are dynamically generated at runtime from untrusted upstream data, because the baseline itself becomes too fluid to validate reliably.
Common Variations and Edge Cases
Tighter tool validation often increases operational overhead, requiring organisations to balance faster agent iteration against stronger change control. That tradeoff is real, especially in environments where MCP tools are created on demand, delegated across tenants, or assembled from third-party connectors.
There is no universal standard for this yet, so current guidance suggests adapting detection depth to risk. For high-impact agents, teams should require immutable tool manifests, strict version pinning, and deny-by-default rules for any undeclared endpoint. For lower-risk internal tools, a lighter baseline plus anomaly detection may be enough, provided the tool cannot reach sensitive systems.
Edge cases also matter. A benign description update can look suspicious if the tool owner changes terminology, so change tickets and signed releases help reduce false positives. Conversely, a poisoned tool can hide in examples or usage notes while the main description looks clean, which is why validation should inspect the full payload, not just the title field. The Analysis of Claude Code Security is a useful reminder that security-sensitive developer tooling often fails at the instruction layer first, then at execution.
For agent-heavy organisations, the practical limit appears when catalogues are shared across many autonomous systems with inconsistent policy enforcement, because one poisoned tool definition can propagate faster than review teams can contain it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Tool poisoning maps to manipulated agent instructions and unsafe tool use. |
| CSA MAESTRO | T2 | MAESTRO covers agent tool trust and runtime governance for autonomous systems. |
| NIST AI RMF | GOVERN | AI RMF governance supports accountability for agent tool integrity decisions. |
| OWASP Non-Human Identity Top 10 | NHI-05 | MCP tool poisoning often exploits compromised non-human trust boundaries. |
| NIST CSF 2.0 | DE.CM-1 | Continuous monitoring is needed to detect tool metadata drift and malicious changes. |
Treat MCP tools as governed resources with approval, monitoring, and session-bound enforcement.
