Offensive MCP security is becoming the baseline for agentic AI

At a glance

What this is: This is an analysis of why MCP server security now needs offensive testing, with Equixly arguing that dynamic tool discovery and chained API use create new exploitation paths.

Why it matters: It matters because MCP turns agent access into a governed identity and authorization problem, so IAM, PAM, and NHI teams have to treat tools, credentials, and permissions as one attack surface.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Equixly's analysis of offensive security for MCP servers and agentic AI

Context

MCP security is emerging as an identity and authorization problem as much as an application security problem. When an AI system can discover tools at runtime, chain actions, and invoke internal APIs through a server acting as a translation layer, the boundary between valid access and excessive access becomes the real control point. That is why broad permissions and weak policy validation matter here more than the protocol label itself.

The article argues that conventional security checks are too static for agentic workflows, especially when tool metadata, connector state, and runtime paths can change quickly. For IAM and NHI teams, the intersection is clear: MCP servers often concentrate credentials, permissions, and access to downstream systems in a way that can amplify confused deputy failures and privileged misuse if governance is not explicit. For organisations already dealing with secret sprawl, this is a familiar but more dynamic version of the same control problem.

Key questions

Q: How should security teams monitor AI agents and MCP servers in production?

A: They should monitor the AI interaction layer directly by collecting prompts, responses, tool calls, and MCP traffic in one telemetry stream. That gives analysts enough context to see whether a benign request triggered unsafe behaviour, data leakage, or unauthorized tool use. Infrastructure logs alone are not sufficient for runtime AI risk.

Q: Why do MCP implementations create confused deputy risk?

A: MCP creates confused deputy risk when a server treats user authentication as enough to authorise any client that can present the token. The user may have approved one application, but another component can reuse that trust relationship and act with the same privileges. The failure is in delegation logic, not in the original sign-in event.

Q: What breaks when AI agents can chain tools through MCP without tight policy controls?

A: What breaks is the separation between request, authorisation, and execution. A single agent session can move from one system to another, combine partial permissions, and create a wider blast radius than any individual entitlement suggests. Traditional access reviews miss this because they rarely model chained tool behaviour in real time.

Q: Should organisations test MCP security with offensive methods or rely on static review?

A: They should do both, but static review alone is not enough. MCP environments change when tools, metadata, or models change, and those changes alter the attack surface in ways point-in-time analysis misses. Offensive testing is what reveals whether access scoping, identity checks, and backend controls actually hold under realistic abuse.

Technical breakdown

Why MCP tool discovery changes the security model

MCP uses a structured JSON-RPC session where clients can query servers for available tools and resources at runtime. That discovery model is useful for orchestration, but it means the agent is not operating against a fixed API contract. Instead, it is navigating a changing capability surface, which expands the risk of overbroad permissions, unsafe tool selection, and unintended tool chaining. In practice, the server becomes a policy decision point for what the agent can see and do, not just a connector to backend systems.

Practical implication: treat tool discovery and permission scoping as a governance control, not a convenience feature.

How prompt injection and tool poisoning reach privileged APIs

Prompt injection exploits semantic trust by inserting malicious instructions into retrieved content, while tool poisoning manipulates tool descriptions, schemas, or expected parameters. In MCP environments, those manipulations can push an agent toward the wrong tool, unsafe parameters, or an unintended context, after which the underlying API executes the request. The important point is that the model is often only the decision layer; the actual impact comes when a privileged tool wrapper calls a backend service with insufficient validation or authorization checks.

Practical implication: separate instruction handling from data handling and enforce policy validation before any tool call is executed.

Why API security remains the foundation beneath MCP

MCP does not replace the business logic, identity checks, or object-level authorization in the APIs it wraps. If those APIs allow broken object-level authorization, excessive permissions, or weak request validation, MCP simply provides a more efficient path to exploit them. That is why the article frames MCP as a translation layer that can concentrate risk when it aggregates access to multiple systems. Security teams need to assume that a flaw at the API layer will be easier to reach once the agent can orchestrate around constraints.

Practical implication: review the underlying APIs for authorization, input validation, and identity enforcement before expanding MCP exposure.

Threat narrative

Attacker objective: The attacker wants to use the agent’s legitimate orchestration path to reach internal data, privileged operations, or lateral movement without needing a traditional exploit payload.

1. Entry begins when a malicious document or poisoned tool metadata enters the agent context and influences the next tool decision.
2. Escalation occurs when the agent invokes a privileged MCP tool that wraps internal APIs, allowing the attacker to move from semantic manipulation to concrete system access.
3. Impact follows when chained API calls return internal data or enable lateral movement across connected systems, turning the MCP server into a single point of failure.

NHI Mgmt Group analysis

MCP security is now an access-governance problem, not just a protocol-hardening problem. The article is right to frame the main failure mode as broad permissions meeting runtime tool discovery. Once an agent can enumerate and chain tools, the question becomes whether the server is enforcing intent, scope, and object-level authorization. For IAM and PAM teams, that makes MCP governance part of the same control plane as secrets and service account management.

Tool metadata is becoming a new policy surface. Descriptions, schemas, and capability labels now influence machine decisions in ways that resemble identity assertions for humans. If those fields can be poisoned or remain too permissive, the agent is guided into actions its operator never intended. The emerging control gap is not just bad code, but bad trust architecture around machine-readable capability discovery.

Offensive validation should be treated as a standing control for agentic systems. Static review misses the multi-step, non-deterministic paths that agents can explore at runtime, especially when tools can be chained into unexpected sequences. That aligns with the broader move in OWASP Agentic AI guidance toward adversarial testing for prompt injection, tool misuse, and privilege abuse. Practitioners should assume the first safe deployment is the one that has already been tested under attack conditions.

API security remains the governing layer underneath every MCP deployment. The protocol can standardise orchestration, but it cannot fix broken object-level authorization, weak input validation, or confused deputy conditions in backend services. That means security teams should not create a separate MCP exception process. They should fold MCP into existing identity, authorization, and API control reviews so the same governance model applies end to end.

Agentic AI extends the NHI problem from credential management into decision management. An MCP-connected agent is not just another service account consumer. It is a software actor making runtime choices across multiple tools, which means privilege and purpose can diverge very quickly. The practical conclusion is that NHI governance must now include how machine actors discover, select, and sequence access, not only what credentials they hold.

What this signals

MCP adoption will force security teams to merge application trust, IAM policy, and NHI governance into one operational review cycle. The practical shift is toward continuous validation of tool permissions, connector state, and authorization outcomes rather than periodic approval of access lists.

Capability discovery drift: when an agent can enumerate new tools at runtime, the security boundary moves every time the server changes. That means inventory alone is not enough. Teams need governance that can detect when new machine-readable capabilities expand the agent's effective privilege set.

For identity programmes, the lesson is that machine actors now create their own access pathways if policy is not explicit. The best starting point is to align MCP reviews with existing identity and API control reviews so that the same accountability model covers credentials, entitlements, and runtime behaviour.

For practitioners

• Scope every MCP tool to a minimum viable permission set Map each advertised tool to the smallest backend capability it needs, then remove broad or inherited privileges that let one tool pivot into many services. Treat tool visibility and tool execution as separate controls so discovery does not equal authority.
• Validate instruction boundaries before the agent can call tools Enforce a clear separation between retrieved data, user instructions, and tool directives, then block any transition from untrusted context to privileged execution without policy checks. This is especially important where RAG content can trigger an MCP action.
• Pen test MCP servers with adversarial tool chaining Use controlled adversarial testing to exercise parameter combinations, alternate tool paths, and multi-step sequences that normal review will miss. Include command injection, SSRF, path traversal, and confused deputy cases in the test plan.
• Review the APIs beneath MCP for object-level authorization failures Audit backend services for broken object-level authorization, weak request validation, and ambiguous identity propagation. If the API layer can be tricked, MCP will amplify the blast radius rather than contain it.

Key takeaways

• MCP changes the security problem from API consumption to runtime orchestration, which makes intent validation and tool scoping the main control points.
• The article shows how prompt injection, tool poisoning, and API-layer weaknesses combine into a single attack path when agents can chain tools.
• Practitioners should treat offensive testing, object-level authorization, and permission scoping as baseline requirements for agentic deployments.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• 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.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.

What's in the full article

Equixly's full blog post covers the attack mechanics and testing details this post intentionally leaves for the source:

• A walkthrough of how the Agentic AI Hacker enumerates MCP tools and probes multi-step attack paths
• Examples of command injection, SSRF, path traversal, and confused deputy conditions across MCP deployments
• The relationship between MCP testing, API security, and LLM risk validation in a single offensive workflow
• Practical validation scenarios for teams that need to test runtime connector states and tool metadata changes

👉 The full Equixly blog post covers the attack chains, tool poisoning examples, and testing approach in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance and secrets management for teams responsible for machine and human identity controls. It helps practitioners align identity policy with the realities of agentic systems and runtime access.