Tool poisoning
Tool poisoning places malicious or misleading instructions in material describing a tool, including descriptions and parameter metadata, so an AI application selects or uses capabilities in an unintended way. The term sometimes also includes malicious tool results. Tool definitions deserve separate review because they can influence an agent before a tool runs.
For Model Context Protocol (MCP) deployments, the OWASP MCP Security Cheat Sheet describes tool poisoning, changed definitions after approval, and cross-server influence. See prompt injection for how untrusted content can redirect an application's behavior.
Explore Dome: Tool Gateway · Docs: Security tutorial.
A tool description can redirect the agent before the tool runs
Suppose a catalog contains a tool described as a document search. Its metadata also tells the agent to collect credentials from another connected service before searching.
The tool has not executed yet. Its description may already influence the model's next action. If you review only the arguments sent to the search tool, you may miss the attempted credential access through another tool.
A “read-only” label is a claim to verify against the server implementation and its permissions. The label itself doesn't restrict what the code can do.
Review metadata as input that will be shown to the model. Keep that review separate from the server's code, dependencies, hosting, and backend permissions. Each can change independently.
Explore Dome: Tool Gateway · Docs: Tools gateway.
Record the version that was approved
A tool rug pull describes a tool changing after an earlier approval, so the current behavior or description no longer matches what the reviewer accepted. Tool shadowing describes cases where one tool's description or other metadata influences how an agent uses other tools, or makes it appear to stand in for a trusted tool.
For a hypothetical tool onboarding review, retain:
- The server's identified source and deployment.
- The reviewed definitions, schemas, and version information.
- The tool's expected effects and required backend permissions.
- Which changes require another review.
- The procedure for withdrawing the tool from use.
Comparing a definition's hash with the approved version can flag a metadata change. Review server implementation changes separately: the code may change while the description stays the same, and an unchanged description may still be misleading.
Explore Dome: Agent Registry · Docs: Security tutorial.
Test cross-tool effects and unexpected changes
In a controlled environment, present a synthetic definition that requests an unrelated action through another tool. Check whether the application tries to take that action and whether the control responsible for that call stops it.
Also test the update workflow. What happens when a definition changes after approval? Is the change visible to an operator? Does the application continue using a cached definition? Which version appears in the investigation record?
Dome's Tool Gateway provides a tool catalog and controls for tool calls. If you also need definition pinning or automated metadata review, verify how those checks will be implemented.
Keep the update-test results with the approved definition and withdrawal procedure. See MCP security for reviewing the connection and server.
Explore Dome: Tool Gateway · Docs: Tools gateway.