How should security teams red team agentic AI systems across the model, orchestration, and MCP layers?

Security teams should test the full AI stack as one attack surface, not as isolated components. Use probes that cover prompt injection, agent goal hijacking, tool poisoning, privilege escalation, and secret exposure across LLMs, autonomous agents, and MCP servers. The goal is to find chained failures before an attacker can move from model compromise to unauthorized actions.

Why This Matters for Security Teams

Agentic systems fail differently from conventional applications because compromise rarely stays inside one layer. A prompt injection may alter the model’s output, but the operational risk appears when an orchestration layer turns that output into tool calls, and an MCP server then exposes data or actions the agent was never meant to reach. Security teams should treat the model, orchestration, and MCP stack as one attack surface, not three separate audits.

The threat is not theoretical. NHIMG’s AI Agents: The New Attack Surface report found that 80% of organisations report agents have already performed actions beyond intended scope, including unauthorised system access and credential exposure. That is why red teaming must look for chained failures, not just isolated defects in prompts or policies. The OWASP view of OWASP Top 10 for Agentic Applications 2026 and NIST’s AI Risk Management Framework both point toward system-level testing, because the failure mode is emergent behaviour across components. In practice, many security teams encounter agent abuse only after a tool chain has already executed an unintended action.

How It Works in Practice

Effective red teaming starts with attack paths, not prompts. Build test cases that begin with model manipulation, then force the orchestration layer to interpret a malicious or misleading output, and finally validate whether the MCP layer will honour the resulting request. Use scenarios that combine prompt injection, goal hijacking, tool poisoning, secrets exposure, and privilege escalation, because single-step tests often miss the real failure chain.

At the model layer, probes should try to override system intent, leak hidden instructions, or induce unsafe tool selection. At the orchestration layer, test whether the agent can be tricked into re-planning around guardrails, repeating actions, or escalating to higher-privilege tools. At the MCP layer, validate whether servers enforce least privilege, scope controls, and strong request validation even when the agent presents a plausible task. The practical question is whether the stack enforces policy at runtime, not whether it looks safe in documentation. Guidance from CSA MAESTRO agentic AI threat modeling framework and the OWASP Agentic Applications Top 10 both support layered testing that follows the control flow from model output to real-world action.

Where possible, use realistic tooling: short-lived test secrets, scoped sandbox MCP endpoints, synthetic data, and instrumentation that records each tool call, policy decision, and credential request. Red teams should also verify whether a compromised model can pivot into adjacent tools through token reuse or session confusion. These controls tend to break down in loosely governed multi-agent environments because one agent’s output becomes another agent’s trusted input.

Common Variations and Edge Cases

Tighter red team coverage often increases coordination overhead, requiring organisations to balance test depth against deployment speed. That tradeoff matters because agentic systems are often shipped in iterative workflows where permissions, tools, and prompts change weekly.

Current guidance suggests treating MCP servers as security-relevant infrastructure, not just integration plumbing. In mature environments, that means testing server-side authorization, schema validation, logging, rate limits, and secret handling independently of the model. In weaker environments, the same test may need to prove that the agent can exfiltrate data through a benign-looking tool call or chain small permissions into a larger unauthorized action. The Analysis of Claude Code Security is useful here because it illustrates how agentic coding workflows can turn ordinary tool access into high-impact actions when controls are not enforced end to end.

There is no universal standard yet for how much autonomy is acceptable before a red team scenario becomes production-realistic, so teams should define test thresholds based on the highest-risk action an agent can take. In practice, the hardest cases involve multi-agent handoffs, hidden memory, and shared credentials, where compromise can spread faster than a human tester can observe.

Related resources from NHI Mgmt Group

• How should security teams govern AI agent orchestration across multiple systems?
• How should security teams red team non-deterministic AI systems?
• How should security teams evaluate AI red teaming vendors for agentic systems?
• How should security teams model AI agents that can read, act, and delegate across systems?