Topic starter
15/08/2026 6:07 pm
TL;DR: Unosecur's analysis finds that tool poisoning in MCP lets a manipulated tool description steer an AI agent into actions the SOC never sees, because the runtime metadata is treated as authoritative instruction. The control gap is that current approval and monitoring models assume tool context is static, but MCP metadata can change after deployment.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “MCP Tool Poisoning Explained: Detection Guide for SOC Analysts”.
Key questions
Q: What breaks when MCP tool definitions change without re-approval?
A: What breaks is the assumption that a previously trusted tool still behaves the same way.
Q: Why do tool descriptors create a security risk in AI systems?
A: Tool descriptors are risky because models read them as instructions, not just metadata.
Q: How do security teams detect MCP tool poisoning in practice?
A: Start with three signals: a stored baseline of approved descriptions, runtime diffing against the live version, and validation rules for imperatives or undeclared endpoints.
Practitioner guidance
- Baseline every approved tool description Capture the exact text and hash of each MCP tool description at approval time so later comparisons have a trusted reference point.
- Compare live metadata before each session Fetch the current description at agent session start and block invocation when the live text differs from the approved baseline.
- Quarantine descriptions with imperative language Flag instructions that tell the agent to search, append, send, ignore, or otherwise act outside the declared tool purpose.
Bottom line: MCP tool poisoning works because AI agents trust tool descriptions as instruction-bearing context, creating a security gap that is invisible to ordinary monitoring.
What's in the full article
Unosecur's full blog post covers the operational detail this post intentionally leaves for the source:
- Exact detection-rule logic for tool description hash mismatches and alert severity
- Example schema-validation patterns for imperative language and undeclared endpoints
- How the MCP Gateway captures session context and compares live metadata
- Practical logging fields needed to reconstruct a poisoned tool invocation
👉 Read Unosecur's analysis of MCP tool poisoning and AI agent metadata governance →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
15/08/2026 6:15 pm
Metadata trust is the new control plane problem for AI agents: MCP tool poisoning shows that governance cannot stop at tool approval, because the agent reads live descriptions at runtime. If those descriptions can change on a remote server, the security boundary has moved from code review to metadata custody. Practitioners need to treat tool descriptions as controlled security artefacts, not documentation.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What should security teams do when an MCP tool description changes unexpectedly?
A: Treat the change as a control exception first and an incident second. Suspend the affected tool, preserve the previous and current descriptions, review whether the new text introduces imperatives or external references, and only restore access after the change is explained and approved. The goal is to stop unreviewed semantic drift before the agent consumes it.
👉 Read our full editorial: MCP tool poisoning shows why AI agent metadata needs governance