Join our Newsletter — 33% off our NHI Course
Home FAQ Threats, Abuse & Incident Response Why do MCP security failures often turn into…
Threats, Abuse & Incident Response

Why do MCP security failures often turn into confused deputy or SSRF problems in agentic workflows?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated September 8, 2026 Domain: Threats, Abuse & Incident Response

MCP failures become dangerous when an agent or server acts on attacker-controlled input using its own privileges. That creates a confused deputy condition, where the wrong party triggers a trusted action, and it can also pass credentials or requests through to unintended targets. The result is misuse of legitimate trust, not just a simple application bug.

Why MCP Trust Breaks in Agentic Workflows

Model Context Protocol becomes risky when an agent can trigger tools, fetch resources, or relay requests using authority that is broader than the instruction that caused the action. In an agentic workflow, the agent is not just passing along user intent; it is also selecting actions, preserving context, and sometimes carrying its own credentials. That combination makes it easy for attacker-controlled input to inherit trust it should never have received.

This is why confused deputy behaviour shows up so often: the server or agent can distinguish neither the true requester nor the true purpose of the request, yet it still performs a privileged action. The same trust failure can also look like SSRF when the protocol or tool layer allows the agent to send outbound requests to internal or unintended destinations. For readers who want a broader view of this attack surface, the OWASP OWASP Top 10 for Agentic Applications 2026 is a useful companion reference.

In practice, many teams discover the issue only after a benign-looking tool call has already reached a sensitive backend or exposed credentials through the agent’s own trusted path.

How the Failure Becomes SSRF or a Confused Deputy

The mechanism is usually simple, even when the workflow is not. An agent receives a prompt, tool output, or upstream message that contains attacker influence. It then uses MCP to call a server, retrieve data, or invoke a side effect. If that server trusts the agent, and the agent trusts the content it was given, the attacker can steer a legitimate deputy into doing the wrong thing.

Confused deputy conditions appear when authorization is attached to the tool runner instead of the actual business intent. The agent may have access to a service account, API token, or internal network route that the human user never should have reached directly. If the protocol allows parameterised URLs, callback targets, embedded resource locators, or indirect fetches, the same trust path can become SSRF-like behaviour. The request is still legitimate from the system’s point of view, which is exactly why it is dangerous.

  • Attacker-controlled input changes the destination, scope, or payload of a tool call.
  • The agent preserves authority while losing context about who benefits from the action.
  • The MCP server executes with its own network reach or credential set.
  • Internal services, metadata endpoints, or unintended tenants may receive the request.

Current guidance suggests treating any tool that can fetch, relay, or transform external content as a potential trust bridge, not just a convenience feature. The NHIMG analysis of OWASP Agentic Applications Top 10 is especially relevant here because it frames how autonomous orchestration expands the blast radius of normal application bugs. These controls tend to break down when the agent can choose destinations dynamically and the server cannot separate intended recipients from attacker-influenced ones.

Where the Pattern Breaks Down in Real Deployments

Tighter protocol controls often reduce flexibility, so organisations have to balance agent usefulness against the risk of delegated abuse. The failure becomes more likely when developers assume that “internal” equals “safe,” or when they allow a generic fetch, browser, or connector tool to operate without destination filtering and scope constraints.

There is no universal standard for this yet, but best practice is evolving toward explicit trust boundaries around tool invocation, constrained egress, and per-action authorization rather than blanket agent credentials. That matters because the agentic model is inherently dynamic: the same workflow can be safe in one step and unsafe in the next if the context, target, or user intent changes.

A practical edge case is delegation across multiple agents or servers. One component may be well-scoped, while a downstream component silently widens access by reusing the upstream identity or forwarding arbitrary URLs. Another edge case is prompt injection through retrieved content, where the attacker never touches the tool directly but still manipulates the request path through the model’s reasoning layer. The NHIMG research on the CoPhish OAuth Token Theft via Copilot Studio shows why delegated trust and token handling need to be designed as one problem, not two separate ones.

These patterns are hardest to control when agents are allowed to chain tools across environments, because the original decision context is usually lost before the final privileged request is made.

Risk and Threat Considerations

The material risk is not just an application flaw but a trust-abuse problem. Once an agent or MCP server can reach internal services, metadata endpoints, or privileged APIs, attacker influence over the request path can turn ordinary automation into a lateral access channel.

Failure mechanism: The attacker supplies content that changes where the agent sends a request or what resource it retrieves, while the system continues to apply the agent’s own authority. That creates confused deputy behaviour, and when the destination is a network location or internal service, the same mechanism can function as SSRF.

Impact: Sensitive data may be disclosed, internal services may be reached without intended authorization, and secrets or session material may be forwarded into places that were never meant to receive them. At scale, this becomes a governance problem because the system can no longer prove that each privileged action matched the intended requester and target.

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 MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10A1 — Prompt Injection and Tool AbuseAgent-influenced tool calls are central to confused deputy and SSRF-style misuse.
Recommendation — Constrain tool execution paths and block attacker-influenced requests from reaching privileged actions.
CSA MAESTROT1 — Agent Threat ModelingThe issue is a delegated-trust failure in autonomous orchestration.
Recommendation — Model agent tool trust boundaries and separate user intent from execution authority.
NIST AI RMFGOV 4 — Govern, Map, Measure, and ManageAgentic trust failures need explicit governance and risk treatment.
Recommendation — Define who may authorize agent actions and measure whether delegated access stays bounded.
NIST CSF 2.0PR.AA-01 — Identity and Access ManagementThe core failure is overbroad access applied to delegated agent actions.
Recommendation — Scope agent credentials to the minimum access needed for each approved action.
MITRE ATT&CKT1190 — Exploit Public-Facing ApplicationSSRF-like abuse often starts by exploiting exposed request handling paths.
Recommendation — Hunt for request-splitting and server-side fetch paths that can be steered by untrusted input.

Practitioner Guidance

What to prioritise: Treat every MCP tool that can fetch, relay, or act on external content as a delegated-privilege boundary. If the tool can reach internal networks or authenticated backends, verify whether it is constrained by destination allowlists and action-specific authorization rather than by the agent’s standing identity.

What to verify: Confirm that the server can bind a request to the right user intent, not merely to a valid session or token. Check whether the agent can be induced to forward URLs, headers, or tokens to unintended destinations, and whether those paths are logged with enough detail to reconstruct the trust chain.

Decision rule: If a tool can influence network reach or credential use, do not treat a successful functional test as evidence of safety. Require an explicit review of destination control, credential scoping, and prompt-injection resistance before broad rollout.

Practitioner takeaway: The real control objective is to prevent agent authority from becoming attacker-amplified authority, because once the system can no longer separate intent from transport, confused deputy and SSRF failures are the same trust collapse.

Deepen Your Knowledge

Sign up to our weekly newsletter — get 33% off our NHI Foundation Level Course

    NHIMG Editorial Note
    Reviewed and updated by the NHIMG editorial team on September 8, 2026.
    NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org