MCP Tool Poisoning Defense

You lock down your API, encrypt your secrets and scan your code—but what happens when the attack comes through the tool itself? Tool poisoning is a security risk where tool metadata, tool responses or external context influence an agent into unsafe behavior. The dangerous part is that the attack does not always look like a direct exploit. It can look like documentation, issue text, a tool description or a returned value.

Why tool poisoning matters

When a model sees hidden or malicious instructions in the context window, it may treat them as relevant guidance. If that model also has access to tools, the result can be unauthorized reads, writes or exfiltration.

Defense layers

• Review and scan tool descriptions before registration.
• Separate trusted instructions from untrusted content.
• Limit tool visibility per agent and task.
• Validate tool-call arguments at runtime.
• Audit every sensitive call.

What a capability contract adds

A raw tool description is not enough. A capability contract can define the allowed use case, expected input shape, denied paths, safe defaults and audit requirements.

Example policy

validate:
  repoAllowlist:
    - example/app
  forbidPaths:
    - ".env"
    - "secrets/**"
  limits:
    maxFiles: 20
mutate:
  branchPrefix: ai/
  draft: true

Runtime protection

Even if an agent is manipulated into attempting a dangerous call, the policy layer can reject it because the final arguments violate the contract.

Practical takeaway

Do not rely only on cleaner prompts or better tool descriptions. Treat every mutating tool-call as an object that must pass policy before execution.