Mcp security shifts trust into third-party servers and agent access

At a glance

What this is: This is a primer on MCP security, with the central finding that connected Model Context Protocol servers expand the agent trust boundary and create a distinct attack surface for instruction injection, scope abuse, credential theft, and exfiltration.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern third-party server access as part of agent trust, not as a separate integration concern.

Context

MCP security starts with a simple but uncomfortable premise: when an AI agent connects to a third-party server, that server can influence the agent’s next action as well as its data access. The governance gap is that many organisations still treat tool connectivity as an integration problem rather than an identity and trust problem.

In practice, the issue is not just whether a server is reachable. It is whether the agent should trust the server’s tool definitions, returned content, and runtime behaviour once that server sits inside the agent’s operational boundary. Model Context Protocol changes the control point from API access alone to the behaviour of the connected server.

Key questions

Q: What breaks when a third-party MCP server is installed without pre-install review?

A: The trust model breaks first. An installed MCP server can inherit agent permissions, read files, call tools and act on behalf of the user, so skipping pre-install review turns a bounded integration into an unreviewed extension of privilege. The practical failure is not only compromise, but also the inability to prove what the server was allowed to do before it was trusted.

Q: Why does MCP security need runtime monitoring as well as approval checks?

A: Because approval only validates the server at one moment in time. A connected MCP server can drift later through updates, dependency changes, or altered tool behaviour, so the original trust decision may no longer match reality. Runtime monitoring catches that drift and shows when a server’s behaviour has moved outside the approved boundary.

Q: How should security teams govern third-party servers that agents can call?

A: They should govern them as delegated access relationships, not as ordinary integrations. That means defining who approves the server, what scopes it can inherit, what behaviour is acceptable, and what evidence is required to keep that access in place. The aim is to control trust continuously, not just to register the connection.

Q: What is the difference between API security and MCP security?

A: API security focuses on protecting known endpoints and request boundaries. MCP security must also govern the agent’s state, the context it carries, and the sequence of tool actions it can trigger. In practice, that means moving from endpoint-centric controls to workflow-centric access policy and continuous enforcement.

Technical breakdown

Why MCP creates a new trust boundary for agents

MCP, or Model Context Protocol, standardises how an agent discovers and calls external tools, but that convenience also places third-party code directly into the agent’s decision path. Unlike a normal API call, the server can shape context the agent later uses for reasoning and action. That means the trust boundary is not the transport layer alone, but the combination of tool definitions, returned data, and the agent’s interpretation of both. Security therefore has to assess the server as an extension of the agent runtime, not as a passive upstream service. See the MCP Security Guide.

Practical implication: treat every connected MCP server as trusted only after explicit review of what it can influence.

How instruction injection travels through tool output

Indirect prompt injection happens when malicious instructions are embedded in tool names, descriptions, or returned data and then consumed by the agent as if they were legitimate context. The attack succeeds because the agent processes the content, not just the metadata around it. This is why an MCP server can be dangerous even when its transport and authentication look clean. The issue is semantic trust: the agent cannot safely assume that a response is merely data. A server that can shape the agent’s context can also shape its next action. Read OWASP Agentic Applications Top 10.

Practical implication: inspect tool content and returned payloads for malicious instruction patterns before allowing agent consumption.

Why runtime monitoring matters after pre-install audit

A pre-install audit checks scope, dependencies, and known bad patterns, but it does not freeze behaviour forever. Supply-chain drift, later updates, and changing server responses can all create new risk after approval. Runtime monitoring closes that gap by comparing observed behaviour with the audited baseline and flagging scope overreach, credential use, or unexpected data movement. In other words, MCP security is lifecycle governance, not a one-time gate. That distinction matters because the server may remain technically reachable while its trustworthiness changes materially.

Practical implication: monitor post-approval server behaviour for drift, not just initial access and install-time checks.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

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

Third-party MCP access is an identity problem, not just an integration problem: Once an MCP server sits inside the agent’s trust boundary, it becomes part of the identity control plane whether teams model it that way or not. The relevant question is no longer only whether the server is reachable, but whether it is allowed to influence agent decisions, scopes, and downstream actions. That makes governance, not connectivity, the primary control dimension.

Tool trust now has its own governance failure mode: MCP collapses the old separation between data retrieval and instruction source. A server can return content that the agent treats as actionable context, which means the control failure is not simple API exposure but unvetted semantic authority. Practitioners should recognise this as a distinct class of risk, where the problem is what the agent believes the server is allowed to say.

Runtime oversight is the only way to hold the boundary after install: Pre-connection checks cannot account for later drift, updated tool behaviour, or changed dependency chains. The field needs to stop treating approval as a durable state and start treating it as a time-bounded assumption. The practical conclusion is that connected servers need continuous scrutiny, not a one-time trust decision.

Model Context Protocol security is really delegated access governance for agents: The server developer, the host application, and the operator all influence the final access outcome, but the operator often inherits the most exposure with the least visibility. That asymmetry is now a repeatable governance pattern, not an edge case. Teams should design accountability for delegated agent access as they would for any other high-trust third-party identity relationship.

Named concept: tool-level trust boundary drift: MCP shifts trust from a fixed integration boundary to a moving runtime boundary where tools, outputs, and context can all change the agent’s action path. That drift is what makes traditional perimeter thinking fail here. Practitioners should frame MCP review around what the server can alter inside the session, not just what it can reach outside it.

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.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Tool trust boundary drift: MCP pushes identity governance into the runtime path, where a connected server can change what an agent sees, believes, and does after approval. That means agent programmes need controls that measure behaviour over time, not just onboarding checks. agent authorisation becomes the right lens when a third-party server can shape action as well as access.

For practitioners, the next phase is to stop treating agent tools as neutral plumbing. Any server that can affect agent context now needs ownership, review, logging, and revocation logic comparable to other delegated access relationships.

For practitioners

• Audit every connected MCP server before approval Review tool definitions, declared scopes, dependencies, and known malicious patterns before any server is connected to an agent.
• Limit the agent reach each server inherits Constrain filesystem, shell, and network access so a connected server cannot inherit more operational reach than its task requires.
• Monitor runtime behaviour against the approved baseline Watch for unexpected tool calls, scope expansion, unusual data movement, and behaviour that diverges from the original review.
• Separate trust decisions from installation convenience Require a conscious approval step for each third-party server rather than assuming that installation alone makes the connection safe.

Key takeaways

• MCP security exists because connected servers can influence an agent’s context, scopes, and next actions, which turns a tooling choice into a trust decision.
• The main failure mode is assuming a third-party server is just a passive integration when it can actually inject instructions, overreach access, or move data through approved calls.
• Practitioners need both pre-install review and runtime monitoring so MCP access remains governed after approval, not just at the point of connection.

Related NHI Mgmt Group resources: MCP Security Guide · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · Agentic AI Security Guide

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.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• 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.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

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.