Notifications
Clear all
Topic starter
11/08/2026 3:16 pm
TL;DR: MCP server metadata can carry plain-English instructions that influence AI agent behaviour, creating a second trust path beyond code, according to Island’s analysis of 33,563 published builds and 475,865 tools. Conventional software scanning misses this instruction supply chain, so agent governance now has to cover descriptions, return values, and runtime approval as well as package integrity.
NHIMG editorial — based on content published by Island: Your AI Can Be Given Secret Instructions in Plain English
By the numbers:
- 49% of server builds produced at least one non-informational finding in our scan, after excluding benign inventory markers.
- 7.8% matched at least one execution rule, including taint-reachable injection paths, shell or subprocess calls, unsafe deserialization, and distinctive reverse-shell patterns.
Questions worth separating out
Q: What breaks when MCP tool descriptions can influence AI agents?
A: Package-centric review breaks down because the risky behaviour may live in plain-English metadata rather than executable code.
Q: Why do AI assistants create a new trust problem for identity governance?
A: AI assistants create a new trust problem because they can read data, choose tools, and act on external text in ways traditional review processes do not expect.
Q: What do security teams get wrong about shadow MCP servers?
A: They often treat them as developer convenience rather than identity-bearing infrastructure.
Practitioner guidance
- Treat MCP descriptions as untrusted inputs Review tool descriptions, prompt templates, and returned text as if they were user-supplied content.
- Scope tool permissions by capability, not by package reputation Separate read, write, network, and execution capabilities into distinct approval paths.
- Revalidate every MCP version and configuration change Treat version bumps and config edits as permission changes, not routine updates.
What's in the full report
Island's full research covers the operational detail this post intentionally leaves for the source:
- The full scanner methodology used to evaluate 33,563 published MCP server builds and classify execution, exposure, and manipulation signals.
- Examples of tool-description poisoning and runtime instruction patterns that are easier to verify in the source than in a summary.
- The detailed breakdown of network exposure, unauthenticated access markers, and command-execution primitives across the sample.
- The discussion of how approval, configuration, and runtime monitoring should be combined into a single agent control plane.
👉 Read Island's analysis of MCP instruction supply chains and AI agent risk →
MCP tool descriptions and hidden instructions: what teams miss?
Explore further
11/08/2026 3:28 pm
Instruction-bearing metadata is now part of the identity perimeter for agents. MCP turns tool descriptions and returned text into governance-relevant inputs because they can influence how an agent decides and acts. That means the boundary of trust is no longer just the server binary or package hash. For identity teams, the practical conclusion is clear: if the agent has delegated authority, the text it consumes must be treated as potentially privileged instruction.
A question worth separating out:
Q: Who is accountable when an AI agent takes an unsafe action?
A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.
👉 Read our full editorial: MCP instruction supply chains are creating new AI security risk
