How to Red Team MCP Tool Permissions

MCP tool permission red teaming checks whether an agent can call tools outside the user's intent, escalate from read to write, or let untrusted content authorize an external action.

Quick Answer

1. Inventory every tool and scope.
2. Classify read, write, external-send, and destructive methods.
3. Test prompt injection against each input source.
4. Require confirmation for risky calls.
5. Log tool calls with enough detail to replay failures.

Start with the tool map

List every MCP server, every exposed tool, and the account or resource each tool can touch. A vague "calendar access" grant is not enough. Read-only event listing and attendee edits are different risks.

The red team cannot test what it has not named.

Try read-to-write escalation

Common failures happen when an agent reads an email, doc, ticket, page, or calendar event and treats that content as authorization to write somewhere else.

The test is simple: put instructions inside the data source and ask the agent to do normal work.

Confirmation gates need content

"Are you sure?" is weak if the user cannot see the exact target and effect. A better confirmation summarizes the tool, account, resource, before and after state, and any external recipient.

Where BreakMyAgent fits

BreakMyAgent turns each permission failure into a repeatable test case for future MCP server and prompt changes.

FAQ

Which MCP tools are highest risk?

Tools that send messages, edit records, delete data, manage permissions, move money, or expose secrets.

Is read-only access safe?

Safer, but not risk-free. Read-only sources can still inject instructions or leak private context into answers.

How often should MCP tools be retested?

After every tool-surface change, model change, prompt change, or new connected account.