MCP’s security model exposes new trust gaps for agentic AI

At a glance

What this is: This is a quickstart guide to MCP that explains its client-server model, OAuth2-based remote access, and the security pitfalls that arise when agents call tools at runtime.

Why it matters: It matters because MCP pushes identity, authorisation, and trust-boundary decisions into agentic workflows, which changes how IAM, NHI, and security teams govern tool access and runtime execution.

👉 Read Riptides’s guide to MCP architecture, OAuth2, and security pitfalls

Context

MCP is a protocol for agentic applications that need to discover tools, resources, and prompts at runtime instead of being hardwired to one backend. That matters for identity security because the control plane shifts from static app integration to live tool selection, which creates new trust boundaries for credentials, tokens, and authorization decisions.

The security issue is not just whether MCP works, but whether the identities behind it are constrained tightly enough for production use. Once an LLM can choose among tools and call them dynamically, IAM teams have to think about who or what is allowed to connect, what tokens are exposed, and how much trust a server deserves before it is placed in the path of sensitive actions.

Key questions

Q: How should security teams govern access to MCP servers in production?

A: Security teams should govern MCP servers as production access paths with explicit ownership, allowlists, and lifecycle review. Treat each server like a non-human identity that can reach sensitive tools or data, and verify that its delegated tokens are limited to the smallest useful scope. Do not let agent convenience override access governance.

Q: Why do MCP-based agents create new trust-boundary problems?

A: MCP-based agents create trust-boundary problems because tool selection happens at runtime and may span local and remote servers. That means the decision to call a tool, the credential used to do it, and the backend reached by the call all need coherent policy. Without that alignment, authority becomes fragmented and hard to govern.

Q: What do security teams get wrong about OAuth2 in agentic workflows?

A: Teams often assume OAuth2 makes the whole path safe once the client authenticates. In practice, the server and downstream backends must also accept and constrain the same authority, or the integration becomes inconsistent. The mistake is treating delegated authentication as a complete control instead of one layer in a larger trust chain.

Q: How can organisations reduce prompt injection risk in MCP deployments?

A: Organisations should validate both user prompts and tool responses before they influence the model’s next action. The goal is to stop untrusted input from steering tool calls or shaping later decisions. Add middleware, restrict the available server set, and ensure sensitive actions require policy checks outside the model itself.

Technical breakdown

MCP client-server architecture and runtime tool selection

MCP uses a client-server model where the application, acting as the client, asks a server for tools, resources, or prompts in a standard JSON-RPC format. The point is not just interoperability. It is runtime orchestration: the LLM can decide which tool to call based on the task at hand, rather than relying on a fixed integration path. That flexibility is what makes MCP useful for agentic applications, but it also expands the identity surface because tool use is now a decision made inside the session, not only at build time.

Practical implication: classify every MCP-connected server as a governed access path, not a convenience integration.

OAuth2 and remote MCP server trust boundaries

For remote servers, MCP relies on OAuth2 so clients can authenticate using standard delegated access flows. That helps normalise the transport, but it does not remove the identity problem. The same token must be accepted by the MCP server and by the backend services it calls, which means authorization architecture has to align across layers. If the backend cannot validate the token path, the agent can talk to the server without actually having meaningful end-to-end authority. That makes identity federation, token acceptance, and trust-domain design core implementation concerns.

Practical implication: validate that token acceptance, backend authorisation, and server trust all line up before production rollout.

Prompt injection and tool-call abuse in agentic workflows

Because the LLM selects tools at runtime, MCP inherits prompt injection risk from both directions. A malicious user prompt can try to steer the model into a tool call it should not make. A malicious tool response can also influence later decisions by shaping the model’s context. This is why the protocol is not just an integration layer. It is part of the control surface for execution, and it needs validation, server trust decisions, and boundary checks around both input and output flows.

Practical implication: place validation middleware on both user input and tool responses before allowing sensitive actions.

NHI Mgmt Group analysis

MCP turns tool access into a runtime identity decision, not a static integration choice. The guide’s core architecture lets an LLM select tools dynamically from a server catalogue, which means privilege is exercised at the moment of execution rather than at deployment time. That shifts control from app configuration to session behaviour. For identity governance, the implication is that access policy now has to understand runtime selection paths, not just service endpoints.

Remote MCP only works when delegated authority is coherent across the full trust chain. OAuth2 on its own does not solve the problem if the server’s token acceptance model and downstream backend authorisation model do not match. The article exposes a common governance mismatch: the client can authenticate successfully while the backends that actually hold the data still reject or over-accept the same token. Practitioners should treat this as an end-to-end federation design issue, not a transport detail.

Prompt injection is an identity control problem once the model can choose actions. The risk is not merely that the model is confused. It is that untrusted input can cause an identity-bearing system to invoke tools outside intended scope or to treat a hostile tool response as authority. That means security teams need to think about tool-call governance, response trust, and policy enforcement as one problem, especially where the agent can act on behalf of a user.

Zero-trust for agentic systems depends on restricting where the agent can connect, not trusting the wrapper by default. The article correctly warns that local and remote servers each create different trust assumptions. In practice, the important question is whether connection choices are configurable and reviewable, or silently hardcoded into the application. If the trust boundary is not explicit, the agent’s runtime behaviour becomes the policy, which is the wrong default for production identity governance.

MCP widens the governance surface across NHI, IAM, and agentic AI at the same time. The protocol brings machine credentials, delegated OAuth access, and agent decision-making into one flow. That makes it a useful test case for integrated identity governance, because the same programme that manages service accounts and secrets now has to deal with tool selection and approval timing inside an LLM session. The practitioner conclusion is clear: MCP needs identity policy, not just application plumbing.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap points to the next reading path, including OWASP Agentic Applications Top 10 for a broader control framework.

What this signals

Agentic tool use is moving faster than governance instrumentation. With 80% of organisations already reporting AI agents acting beyond intended scope in the SailPoint research, the pattern is no longer theoretical. For practitioners, MCP should be treated as an access model that needs ownership, entitlement review, and auditability before it is allowed to connect to sensitive backends.

Runtime selection changes the shape of least privilege. Once the model can choose from multiple tools inside the session, least privilege is no longer only a provisioning question. IAM teams should expect pressure to define connection allowlists, token scope boundaries, and approval paths that survive dynamic tool selection.

MCP governance will increasingly sit at the intersection of agentic AI and NHI controls. The organisations that succeed will be the ones that can tie server identity, delegated tokens, and tool-call policy into one reviewable control surface. For deeper framework context, the OWASP Agentic Applications Top 10 remains a useful reference point for threat modelling.

For practitioners

• Inventory every MCP trust boundary Map each local and remote server, the credentials it receives, and the backends it can reach. Treat the inventory as an access review artefact, not just an architecture diagram.
• Require explicit allowlists for agent connections Configure which servers an agent may connect to, and avoid hardcoding those choices into application code. Make the trust boundary reviewable by IAM and security teams before deployment.
• Validate token acceptance across the full path Test that the OAuth2 token issued to the MCP client is accepted by the MCP server and by every backend API the server needs. Break the design if any layer accepts more authority than intended.
• Add middleware for both prompt and tool-response validation Inspect user prompts before tool selection and inspect tool outputs before they re-enter the model context. Block instructions that attempt to expand scope, reveal credentials, or trigger unsafe calls.
• Classify MCP servers as governed non-human identities Apply the same entitlement discipline used for service accounts, API keys, and other NHIs. Require ownership, lifecycle review, and clear revocation for every server identity exposed to agents.

Key takeaways

• MCP expands the identity problem from static application integration to runtime tool selection, which makes trust boundaries part of the control surface.
• OAuth2 helps standardise remote access, but only coherent end-to-end token acceptance keeps delegated authority from breaking or overreaching.
• Agentic deployments need allowlists, validation middleware, and server lifecycle governance before they touch sensitive systems in production.

Key terms

• Model Context Protocol: A standard that lets applications expose tools, resources, and prompts to an AI client in a consistent way. In practice, it moves integration from custom code to runtime discovery, which makes identity, authorisation, and trust boundaries part of the protocol design.
• Agentic Application: An application that uses an LLM to choose actions or tools during execution rather than only generating text. In governance terms, the important issue is not sophistication alone but whether runtime decisions can affect external systems without human approval.
• Delegated Access Token: A token that represents granted authority for a client to act against a service or backend on a user’s or system’s behalf. For MCP deployments, the key question is whether the same token is accepted and constrained consistently across every layer it touches.
• Trust Boundary: The point where one identity, system, or server should no longer be assumed to be safe without verification. In agentic workflows, trust boundaries must be explicit because tool selection, server calls, and downstream API access can all happen inside one session.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Riptides: MCP: A Quickstart Guide. Read the original.