Offensive MCP security is becoming the baseline for agentic AI

At a glance

What this is: Equixly argues that MCP security now has to be treated as offensive, runtime validation because agents can discover tools, chain actions, and exploit weak boundaries far beyond the original intent.

Why it matters: For IAM, PAM, and NHI practitioners, the issue is that dynamic tool orchestration turns permissions into an exploit path unless discovery, authorization, and execution are continuously tested.

Context

MCP creates a structured way for AI systems to discover tools and call external services at runtime, which makes the security problem less about static endpoint protection and more about whether the agent is allowed to do what it can discover. In practical terms, the control gap appears when broad permissions and weak policy boundaries let runtime behaviour drift far beyond original intent.

This matters to identity governance because the agent is not just using an API key or service account. It is exercising delegated authority through a tool layer that can amplify privilege, hide confused-deputy conditions, and blur who or what actually authorised the action.

Key questions

Q: What breaks when AI tools are exposed through loosely governed MCP servers?

A: Loose governance lets model-driven tools cross from context retrieval into state-changing actions without enough oversight. That can expose sensitive data, trigger unauthorized system changes, or widen lateral movement paths. The failure is a control boundary mismatch between what the AI can ask for and what it can safely do.

Q: Why do MCP deployments increase the need for continuous adversarial testing?

A: Because the attack surface changes whenever a tool, schema, or model changes. Static review can show whether a design looked safe at one point in time, but it cannot reliably model live orchestration paths, tool chaining, or adversarial parameter combinations. Continuous testing is the only practical way to verify that security boundaries still hold.

Q: How should teams handle authorisation beneath an MCP layer?

A: They should treat the MCP server as a translation layer, not a trust boundary. The wrapped APIs still need object-level authorisation, least privilege, and confusion-resistant identity checks, because an autonomous agent can otherwise use a valid tool path to reach data or actions it was never meant to access.

Q: What is the difference between prompt injection and MCP tool injection?

A: Prompt injection targets the model conversation, while MCP tool injection targets the metadata and instructions tied to external tools. The second is often harder to spot because the user may never see the malicious text. Both can steer behavior, but tool injection can directly influence privileged actions.

Technical breakdown

How MCP server discovery changes the attack surface

MCP servers advertise tools and resources dynamically through JSON-RPC sessions, which means the client can enumerate capabilities at runtime instead of relying on a fixed API contract. That discovery model helps orchestration, but it also means the security boundary shifts from known endpoints to a fluid set of callable functions, many of which may be exposed with inconsistent authentication, excessive privilege, or weak integrity checks. Once a model can see available tools, the real risk is not merely access, but what the runtime can infer, chain, and attempt.

Practical implication: treat tool discovery as a governed control point, not a convenience feature.

Why prompt injection and tool poisoning become execution paths

Prompt injection in MCP environments works when untrusted content is allowed to influence the agent’s next tool choice. Tool poisoning is adjacent but distinct: it manipulates tool descriptions, schemas, or metadata so the agent selects the wrong capability or sends unsafe parameters. In both cases, the model becomes the decision layer, while the backend tool performs the harmful action. The weakness is semantic trust, where the system assumes instructions and data are clearly separated even though the agent is actively interpreting both.

Practical implication: validate tool intent and context before execution, not after the model has already formed a call.

Why API security still governs the layer beneath MCP

MCP does not replace the underlying APIs, business logic, or authorisation model. It wraps them, which means classic API failures such as broken object-level authorisation, SSRF, command injection, and confused deputy conditions remain central. If an MCP server aggregates permissions from several back-end systems, one weakness can become a multi-service compromise path. The key architectural point is that autonomous orchestration magnifies existing API flaws rather than inventing entirely new ones.

Practical implication: test the APIs behind MCP with the same rigour you would apply to a privileged production integration.

Threat narrative

Attacker objective: The attacker wants to turn the agent into a high-speed intermediary that discovers tools, expands reach, and executes privileged actions against internal systems.

1. Entry occurs when a malicious document, poisoned tool metadata, or an exposed capability influences the agent’s next action inside the MCP session.
2. Credential or privilege abuse follows when the agent invokes a privileged MCP tool that inherits broader access than the initiating user intended.
3. Impact appears when chained tool calls reach internal APIs and sensitive data leaves the environment, or when the agent completes multi-step exploitation without human intervention.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP security is now an identity and authorisation problem, not just an application-security problem. The article shows that the real control issue is delegated runtime authority: the agent can discover tools, infer paths, and act inside permissions that were never designed for autonomous use. That makes intent validation and privilege scoping the governing question, not just input sanitisation. Practitioners should treat MCP as a delegated-access boundary that needs continuous assurance.

Offensive testing is becoming the only credible way to validate MCP trust boundaries. Static review cannot model multi-step tool calls, changing connector states, or adversarial parameter combinations at machine speed. That is why the article’s core thesis matters: defenders need empirical proof that the orchestration layer fails closed when agents behave unexpectedly. The named concept here is runtime authority drift, where allowed capability outgrows intended purpose. Practitioners should test for it continuously.

Agentic AI makes confused deputy failure modes more dangerous because the agent and the backend both appear to be legitimate actors. When MCP servers aggregate credentials and expose high-privilege tool metadata, a request can look valid while still violating the user’s real intent. That creates a governance gap between authentication and authorisation that conventional API controls do not fully close. Practitioners should force explicit intent checks at the tool boundary, not just at login.

MCP validation has to include the API layer beneath the orchestration layer. The article is right to treat MCP as a translation layer rather than a security boundary. If BOLA, SSRF, command injection, or weak auth already exist in the underlying APIs, MCP simply makes exploitation easier to scale and harder to notice. Practitioners should align MCP testing with API security and adversarial AI validation together.

Dynamic tool ecosystems invalidate point-in-time assurance models. Every new tool, schema change, or model update can change the reachable attack surface, so a one-off review quickly becomes stale. The governance implication is broader than MCP itself: as agentic systems spread, security teams will need continuous validation as a standard operating model. Practitioners should plan for ongoing adversarial assurance, not periodic certification.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: Agentic AI Security Guide

What this signals

Runtime authority drift: MCP and agentic systems create a control problem where permitted actions expand faster than governance can track them. That means identity teams need to move verification closer to tool invocation, because the decisive question is no longer whether the agent is authenticated, but whether its current action still fits the intended authority boundary.

The operational shift is toward continuous assurance across model behaviour, tool metadata, and backend API controls. MCP server security is therefore not a niche protocol topic but a preview of how delegated AI authority will need to be governed across future agentic environments.

AI adoption is moving faster than governance maturity, and the gap is already visible in security posture. Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey, so most programmes will have to close the control gap while systems are already in production.

For practitioners

• Govern tool discovery as an access decision Restrict which tools an MCP client can enumerate, and validate that exposed tool metadata does not reveal privileged operations that exceed the user’s intended scope.
• Separate instruction input from trusted data Apply strong context boundaries so retrieved content, external documents, and user prompts cannot directly influence tool selection or privileged execution.
• Test the APIs beneath MCP for broken authorisation Review the wrapped APIs for object-level authorisation failures, confused deputy conditions, and overbroad service permissions that an agent can chain through.
• Add continuous adversarial testing for tool chains Use runtime testing that exercises multi-step orchestration, unexpected parameter combinations, and alternate tool paths whenever tools or models change.
• Scope privileged connectors to the minimum usable intent Design connector permissions so an MCP server cannot aggregate more access than each task requires, especially where internal APIs and sensitive data sources converge.

Key takeaways

• MCP turns agentic AI into a live control plane where discovery, delegation, and execution can be abused if permissions exceed intent.
• The main risk is not a novel protocol flaw but the way familiar API weaknesses and semantic trust failures combine inside autonomous workflows.
• Continuous offensive validation is the control theme that matters most, because static review cannot keep pace with changing tools, models, and connector states.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• Action Validation: A control that checks whether a requested action is allowed before the system carries it out. For autonomous agents, validation is more than logging or alerting because it must evaluate the action in context and block unsafe execution before tools or data are touched.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for security and identity practitioners who need to govern delegated access, machine identities, and emerging agentic risk.