MCP and agent tool trust

Tags: mcp, tool-trust, llm

Level: advanced

Method

1. List the tools and their tokens

   For each tool the product exposes, record what the tool is allowed to do and which credential it uses. One connection token reused for every tool is the first note.

   Tools: browser

2. Compare user authority and tool authority

   If the tool can read or send data the signed-in user cannot, the tool is a confused deputy. Show both sides with accounts you own.

   Tools: Burp Suite

3. Tenant constraint

   A static server credential with no tenant check will answer for every org the server can see. Cross-tenant proof needs two orgs you own.

   Tools: Burp Suite

4. Human approval

   If the product says a person must approve a tool call, see whether a second call in the same session skips that approval. The missing check is the bug.

   Tools: browser

5. Tool descriptions are data

   Text in a tool description or a connected document can steer the model. Treat that as untrusted input. Do not publish a jailbreak. Show which tool ran and with whose token.

   Tools: browser

6. Stop at the authority gap

   The report is the token audience, the tool that accepted it, and the data or action that should have been refused.

   Tools: browser

Field notes

• A token that can only do what the user can already do is often informational.
• Do not ask a production agent to email, pay, or delete on a real customer.
• The current MCP revision is 2026-07-28. Tool descriptions are untrusted unless the server is trusted. Cite the revision you tested.

References

• https://modelcontextprotocol.io/specification/2026-07-28
• https://owasp.org/www-project-top-10-for-large-language-model-applications/