The tool broker becomes an untested privilege boundary, which means poisoned descriptions, confused-deputy paths, and over-broad permissions can slip through. Agents may then use legitimate access on an attacker’s behalf. Without MCP testing, the organisation can validate the model while leaving the access path exposed.
Why This Matters for Security Teams
When red teaming focuses only on the model and ignores MCP, it tests the assistant while leaving the broker, tool registry, and permission boundary largely unexamined. That is a serious gap because MCP is where prompts become actions, and actions become access. A poisoned tool description, an over-broad connector, or a weakly scoped token can turn a harmless-seeming agent into an unwitting proxy.
This is why current guidance increasingly treats MCP as part of the attack surface, not just an integration detail. The issue is visible in research on The State of MCP Server Security 2025 and in the OWASP Agentic AI Top 10, both of which point to tool-layer weakness as a practical path to abuse. In practice, many security teams discover this only after an agent has already exercised legitimate access in an unexpected way, rather than through a deliberate MCP-aware red team exercise.
How It Works in Practice
Effective ai red teaming for MCP starts by treating the broker, tools, and schemas as test targets, not just the model prompt and output. The tester should verify whether tool metadata can be poisoned, whether the agent can be induced to call higher-privilege tools than intended, and whether the broker enforces context-aware restrictions at request time. This aligns with broader agentic guidance in OWASP Agentic Applications Top 10 and the implementation focus described in the CSA AI Agent Disclosure Accountability Gap whitepaper.
Practitioners should test for three failure classes:
- Confused deputy paths, where the agent uses a legitimate tool on an attacker’s behalf.
- Tool poisoning, where misleading descriptions or schema fields steer the agent toward unsafe actions.
- Permission drift, where tokens, scopes, or delegated rights exceed the task boundary.
That means validating the full chain: model decision, broker policy, tool authorization, and secret handling. Red teams should also simulate prompt injection through tool outputs, because MCP often passes untrusted content back into the reasoning loop. The goal is not just to see whether the model refuses a bad prompt, but whether the access path stays constrained when the model does not. These controls tend to break down in environments with many loosely governed internal connectors because the broker inherits broad service trust and the agent can chain tools faster than manual review can detect.
Common Variations and Edge Cases
Tighter MCP testing often increases operational overhead, requiring organisations to balance depth of assurance against release speed and tool sprawl. There is no universal standard for this yet, so current guidance suggests risk-based scoping rather than a one-size-fits-all test pack.
High-risk environments need more aggressive coverage. Shared developer sandboxes, ticketing integrations, code execution tools, and data retrieval connectors deserve the strongest scrutiny because they can turn a single compromised instruction into lateral movement. Low-risk read-only tools still matter, but the test emphasis shifts toward data leakage and policy bypass rather than destructive action. Where agents rely on long-lived credentials or broad workspace tokens, red team findings are often more severe because the broker failure persists after the test session ends.
NHIMG research on Analysis of Claude Code Security shows why code-connected agents deserve special care, while the Anthropic Frontier Red Team material reinforces the need to test tool-mediated behavior, not just prompt adherence. The practical edge case is environments that delegate trust through multiple brokers and gateways, because accountability gets blurred and a single missed policy boundary can invalidate the whole exercise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Tool abuse and confused-deputy paths are core agentic application risks. |
| CSA MAESTRO | TRUST | MAESTRO emphasizes trust boundaries around agent orchestration and tool use. |
| NIST AI RMF | MAP | AI RMF mapping helps identify MCP as part of the full AI system risk surface. |
| OWASP Non-Human Identity Top 10 | NHI-02 | MCP often fails through over-privileged service identities and weak secret handling. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero trust requires continuous authorization of every brokered access request. |
Scope and rotate MCP service credentials so no connector has broader access than the task requires.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
