MCP servers expand agent access and create new trust boundaries

At a glance

What this is: This guide defines MCP servers and shows how they extend AI applications into data and tool access while introducing new security and governance boundaries.

Why it matters: It matters because practitioners need to govern MCP servers as identity-bearing access points, not as simple API wrappers, especially when agents can reach databases, code repositories and SaaS tools.

Context

MCP servers create a new governance layer between AI applications and the systems they touch. Instead of a human directly calling a database or SaaS API, the host, client and server split responsibility for discovery, approval and execution.

That split matters because the security question is no longer only whether a system is reachable. It is whether the server's tools, prompts, tokens and outputs are safe to expose to an AI application that can select actions at runtime.

For identity teams, the important shift is that an MCP server becomes part of the access path itself, which means MCP security guide style controls apply around consent, scope and token handling.

Key questions

Q: What breaks when MCP servers are not governed like integrations?

A: What breaks is the trust boundary. If an MCP server can connect an agent to tools or data without clear ownership, logging, and access limits, the server becomes part of the effective attack path. That creates hidden delegation and makes it harder to prove which actions were authorised.

Q: Why do MCP servers need stricter token controls than ordinary service integrations?

A: Because the server becomes a trusted execution point for an AI application, and any token accepted there can influence both access and behaviour. If a server accepts tokens issued for another system, or forwards them unchanged, it expands the blast radius of a single compromise. Audience checks and token isolation are essential.

Q: What should security teams do when an MCP tool description changes unexpectedly?

A: Treat the change as a control exception first and an incident second. Suspend the affected tool, preserve the previous and current descriptions, review whether the new text introduces imperatives or external references, and only restore access after the change is explained and approved. The goal is to stop unreviewed semantic drift before the agent consumes it.

Q: How do organisations decide between single-user, multi-user, and remote MCP servers?

A: Choose the server type that matches the identity and credential model you can actually govern. Single-user servers fit individual credentials, multi-user servers suit shared access with central control, and remote servers require stronger gateway oversight because execution happens outside the local runtime boundary.

Technical breakdown

How an MCP server differs from an API gateway

An MCP server is not just a wrapper around an API. It publishes capabilities in a machine-readable way, lets a host discover them at runtime, and allows the model to choose among tools, resources and prompts based on user intent. That makes the security boundary dynamic rather than static. A traditional API exposes fixed endpoints to developers. An MCP server exposes context and actions to an AI application that may treat descriptions as instructions. The result is that validation, consent and scope enforcement must happen on both sides of the call, not only at the API edge.

Practical implication: Treat MCP servers as policy-bearing access components, not as passive integrations.

Why transport choice changes the trust model

MCP supports stdio for local processes and Streamable HTTP for remote services, and the transport determines who can reach the server and how identity is established. Local stdio servers run with the client's privileges, so compromise risk shifts to the workstation or runtime environment. Remote HTTP servers create a networked trust boundary and need authentication, origin checks and token validation. The protocol revision also removed protocol-level sessions, which reduces hidden state but increases the importance of explicit handles and per-request controls. In practice, transport is not a deployment detail. It defines the attack surface and the control model. See the NHI Authentication Guide.

Practical implication: Choose transport based on privilege exposure, then apply the matching authentication and isolation controls.

Tool descriptions and outputs are part of the attack surface

MCP tools are selected by the model, so the description text, metadata and returned output all influence behaviour. That creates two distinct risks. First, tool poisoning can hide malicious instructions inside descriptions or change them after approval. Second, prompt injection can arrive through tool output that the model later treats as trusted context. This is why the protocol guidance and OWASP both focus on review, output sanitisation, and human approval for sensitive actions. The real issue is not just whether the tool works. It is whether the tool can reshape the agent's next decision. Read OWASP Agentic Applications Top 10.

Practical implication: Review tool text and outputs as untrusted input, especially before high-impact actions.

Threat narrative

Attacker objective: The attacker aims to steer an AI application into exposing data, executing unsafe actions or extending access beyond the original consent boundary.

1. Entry begins when an AI application connects to a local or remote MCP server and gains access to the server's declared tools, resources or prompts.
2. Credential or token abuse can follow if the server accepts credentials meant for another service, trusts overbroad scopes or forwards tokens without checking audience.
3. Impact occurs when poisoned tool descriptions, injected outputs or over-permissioned tools cause the model to carry out actions that should not have been authorised.

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.

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 turns every exposed tool into a governance object: the central mistake is to treat a server as a technical connector rather than an access boundary. Once the model can select actions at runtime, tool descriptions, scopes and outputs become part of the control plane. That changes how identity teams should think about inventory, approval and trust. The implication is that access review must expand beyond accounts and tokens to the server-defined actions themselves.

Transport choice now expresses privilege posture: stdio and Streamable HTTP are not interchangeable deployment styles. Local servers inherit workstation trust and remote servers introduce network authentication and token validation requirements. That means a single governance model will miss different failure modes in different deployments. The implication is that teams need separate control expectations for local developer tooling, shared internal services and externally reachable AI integrations.

Tool poisoning is a named governance failure, not a niche prompt bug: the article's own examples show that descriptions can steer behaviour before any code runs. That means approval based only on a server name or high-level purpose is insufficient. The implication is that practitioners need to govern the text and metadata that define tool intent, because that is where runtime manipulation starts.

Prompt injection and token misuse belong to the same control conversation: one problem alters what the model thinks it should do, the other alters what it is allowed to do. In MCP, those risks compound because the same server can hold credentials, return instructions and execute operations. The implication is that identity governance must join content trust, credential trust and execution trust into one review path.

MCP server sprawl creates a shadow access layer: the article notes that teams may add many local or remote servers, including ones published by vendors or created ad hoc by developers. That broadens the inventory problem beyond ordinary API estates. The implication is that organisations need a clear owner for every server, every scope and every trust decision before an agent is allowed to use 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.
• Read next: MCP Security Guide

What this signals

Identity governance for MCP will move from endpoint review to capability review: teams will need to approve the exact tools, prompts and scopes an AI application can see, not just the backend services those tools reach. That is a material shift for IAM, PAM and NHI programmes because the access boundary now lives inside the server definition as well as in the target system.

Runtime trust will become a recurring control point: MCP servers can be local, remote, vendor-supplied or team-built, and each one creates a different trust model. Organisations that standardise on one approval pattern will miss the difference between workstation privilege, networked authentication and delegated tool execution. The practical effect is that governance will need deployment-aware policy, not one-size-fits-all review.

Tool poisoning will push security teams toward metadata governance: the next control gap is not only credential sprawl but also description sprawl, where the model's behaviour is shaped by text that changes over time. That means the server manifest, not just the server code, becomes an audit object.

For practitioners

• Inventory every MCP server Map each server to an owner, transport, exposed tools, requested scopes and connected AI application before allowing production use.
• Constrain tool scope to the minimum usable set Remove omnibus scopes, split broad functions into narrow tools and require step-up approval for sensitive operations.
• Treat tool descriptions as controlled content Review descriptions, pin approved versions and revalidate the server when metadata changes because the model consumes that text as decision input.
• Validate token audience and origin Reject any token that was not issued for the MCP server and do not pass through credentials intended for another resource.
• Separate local developer servers from shared services Use sandboxing and tighter host controls for stdio deployments, then apply network authentication and policy enforcement to remote HTTP services.

Key takeaways

• MCP servers extend AI access into tools, data and prompts, so the security boundary now includes runtime discovery, consent and server-side validation.
• The biggest risks are not abstract platform concerns but concrete governance failures such as overbroad scopes, token passthrough and tool poisoning.
• Practitioners should inventory servers, constrain scopes, review tool metadata and apply different controls to local and remote deployments.

Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · OWASP Agentic Applications Top 10 · AI Agent Authorisation Guide

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.
• Streamable HTTP: Streamable HTTP is the stateless transport used for modern MCP deployments. It replaces persistent session-style connections with standard HTTP requests and responses. That design makes it easier to scale MCP servers behind load balancers, run multiple replicas, and preserve governance without tying traffic to one server instance.
• 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.
• Token Passthrough: Token passthrough is the practice of forwarding an authentication token through intermediaries instead of validating it at each trust boundary. In MCP this is prohibited because it prevents the server from proving who is actually authorised to act. The result is weaker accountability and a larger attack surface for stolen or replayed credentials.

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 building or maturing an IAM programme, it is worth exploring.