Model context protocol leaves NHI governance to the caller

At a glance

What this is: Model Context Protocol is a structured interface for connecting AI models to tools and data, and its central limitation is that security and governance are not enforced by the protocol itself.

Why it matters: For IAM and NHI practitioners, MCP turns every connected tool into a governed access path, which means identity, privilege, and audit controls must be added outside the protocol.

👉 Read Teleport's analysis of Model Context Protocol security and governance

Context

Model Context Protocol, or MCP, is the control plane for how AI models discover and invoke tools, but it does not decide who is allowed to do what. That distinction matters for NHI governance because every MCP-connected agent, service, or automation now behaves like a non-human identity with potential access to systems, data, and workflows.

The governance gap is straightforward: a protocol can standardise requests and responses without standardising trust, authorisation, or revocation. In enterprise settings that means the risk sits not in MCP alone, but in the way teams wrap it with identity, policy, and logging. That is a familiar starting point for early adopters, but it is not yet a safe operating model by default.

Key questions

Q: How should security teams govern MCP-connected AI agents?

A: Start by treating every MCP-connected agent as a non-human identity with bounded authority. Verify caller identity at the gateway, enforce least privilege per tool, require short-lived credentials, and log every invocation with enough context for investigation. Governance fails when teams secure the model interface but ignore the downstream access path.

Q: Why do MCP deployments create new IAM risks?

A: MCP creates IAM risk because it standardises tool access without enforcing authorisation, revocation, or audit by default. That means the organisation must supply those controls externally, or every connected tool becomes a potential privileged action path. The bigger the tool estate, the faster the blast radius grows.

Q: What is the difference between MCP and an API from a security perspective?

A: An API exposes software functions, while MCP standardises how a model discovers and invokes those functions. From a security perspective, both need identity and access control, but MCP adds a new layer of risk because the caller may be an autonomous agent acting across multiple tools. The control problem is broader than endpoint protection.

Q: When does MCP become too risky for production use?

A: MCP becomes too risky when the connected tools can change state, expose sensitive data, or trigger downstream workflows without strong policy enforcement. If the organisation cannot verify identity, constrain scope, and revoke sessions quickly, production use should remain limited to low-risk or read-only tasks. Security should lead deployment, not follow it.

Technical breakdown

MCP architecture and tool discovery

MCP uses a client-server model in which a host runs the model and client, while servers expose discoverable capabilities such as resources, tools, and prompts. Resources provide read-only context, tools execute side effects, and prompts guide reusable workflows. The model first discovers available tools, then receives schema metadata, then submits structured JSON requests. That separation is useful because it makes tool use more predictable than ad hoc plugins, but it also expands the identity surface: every server becomes a potential access path, and every tool becomes a policy decision point.

Practical implication: Treat each MCP server as a governed service identity, not a convenience integration.

Why MCP shifts risk from integration to authorisation

MCP reduces custom integration work by standardising how models call tools, but the protocol deliberately stops short of enforcing security boundaries. It does not validate the calling model's identity, does not enforce role scope, and does not provide native revocation or session expiry. In practice, that means the security model depends on external enforcement such as mTLS, OAuth-bound tokens, API gateways, or policy engines. For practitioners, the mechanism is familiar: a normalised interface can still expose privileged capabilities if authorisation is bolted on too late.

Practical implication: Assume every tool call is a privileged action unless an external control proves otherwise.

How structured tool use changes audit and blast radius

Because MCP formalises tool invocation, it can improve observability relative to opaque prompt-to-action chains, but only if logging is implemented at the server and gateway layers. Without that, teams lose traceability over which agent invoked which tool, with what parameters, and under what identity. The blast radius is therefore determined by the least controlled tool, not the protocol itself. In agentic environments, a single over-permissioned server can expose data, trigger workflows, or chain into downstream systems at machine speed.

Practical implication: Instrument every invocation and segment tools by sensitivity before connecting them to autonomous agents.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP is not an identity control. It is an execution interface that must inherit identity from somewhere else. That makes MCP governance an IAM problem as much as an AI problem. If the model can discover and invoke tools without strong caller verification, the organisation has created a machine-speed access path with human-style assumptions. Practitioners should treat the protocol as transport, not trust.

The real risk is privilege translation, not protocol adoption. MCP turns model intent into side effects, which means old assumptions about read-only assistants break the moment a tool can write, delete, or trigger workflows. That is why access scope, tool classification, and approval gates matter more than protocol familiarity. The practitioner takeaway is simple: map each tool to a privilege tier before any agent can call it.

Identity blast radius becomes the decisive metric for agentic systems. Once multiple servers, tools, and prompts are linked to a single agent workflow, one weak control can multiply across the chain. This is where Zero Trust Architecture and Zero Standing Privilege should be applied operationally, not rhetorically. Teams should design for containment first and productivity second.

Open protocols will attract enterprise adoption faster than enterprise governance catches up. That pattern is already visible across agentic AI tooling: standardisation lowers friction, while control maturity lags behind. The market will keep rewarding interoperability, but security leaders need to decide where that interoperability is allowed to reach production. The practitioner conclusion is to govern rollout by use case, not by enthusiasm.

Named concept: tool-call trust debt. MCP creates tool-call trust debt when teams connect models to systems faster than they can enforce identity, scope, logging, and revocation. The debt compounds with every additional server because the protocol makes connection easy and governance optional. Practitioners should measure and reduce that debt before autonomous workflows become business-critical.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 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.
• See also OWASP Agentic Applications Top 10 for the agentic risk patterns that make this governance gap operationally urgent.

What this signals

Tool-call trust debt will become a recurring pattern in agentic environments: organisations will connect more systems to AI faster than they can enforce identity, scope, and revocation. The practical response is to align MCP rollout with policy maturity, not with integration backlog, and to anchor that work in the NIST AI Risk Management Framework.

When 92% of organisations say governance is critical but only 44% have policies in place, the gap is structural rather than tactical. That gap is likely to widen as autonomous workflows move from pilot to production, so programme owners should prioritise tool inventory, approval gating, and auditability before broad agent enablement.

The near-term signal for security teams is that MCP will push more responsibility into access infrastructure, where IAM, PAM, and NHI controls already live. Teams that can bind model identity to session-scoped access and constrain tool permissions will be better positioned to absorb agentic growth without expanding their attack surface uncontrollably.

For practitioners

• Classify MCP tools by privilege tier Separate read-only resources from write-capable tools and high-impact workflows, then require different approval and access paths for each tier. This is the fastest way to prevent a convenience integration from becoming an unreviewed control path.
• Enforce caller identity at the gateway Use mTLS, signed tokens, or OAuth-bound identities so the server can verify which client is invoking a tool. Do not rely on the model or host environment as proof of trust.
• Apply RBAC and ABAC outside the protocol Map tool permissions to policy engines that evaluate caller identity, environment, and task context before execution. External RBAC and ABAC should decide whether the call is allowed, not the schema alone.
• Log every invocation with identity context Capture tool name, input parameters, caller identity, and outcome in a tamper-resistant audit trail. Without that data, you cannot investigate misuse, reconstruct access, or prove compliance.
• Use short-lived credentials for agent sessions Issue session-bound certificates or tokens with expiry and revocation, then rotate them on a schedule that matches the sensitivity of the tool. Persistent access is the wrong default for autonomous callers.

Key takeaways

• MCP standardises model-to-tool interactions, but it does not solve identity or authorisation on its own.
• The security issue is not protocol adoption itself, but the unchecked privilege it can expose when tools are connected too quickly.
• Teams should govern MCP as an NHI problem, with external identity checks, scoped permissions, and full audit logging from day one.

Key terms

• Model Context Protocol: A standard that lets AI models discover and invoke external tools through a structured interface. It normalises request and response flow, but it does not itself enforce identity, privilege, or revocation, so those controls must be added by the organisation.
• Tool-call trust debt: The accumulated risk created when teams connect models to tools faster than they can enforce identity, scope, logging, and revocation. In MCP environments, this debt grows with every additional server because integration is easy and governance is optional.
• Identity blast radius: The amount of damage a compromised identity can cause across connected systems. For agentic workflows, the blast radius expands when one agent can reach multiple tools, making privilege boundaries and session limits essential to containment.
• Non-human identity: A machine account, token, certificate, workload, bot, or AI agent that authenticates to systems and exercises access rights. In practice, NHI governance is about controlling how these identities are issued, scoped, monitored, and revoked.

What's in the full article

Teleport's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step MCP server setup guidance, including schema definition and request handling.
• Implementation notes for JSON-RPC transport choices such as HTTP, STDIO, and SSE.
• Teleport's access-layer design for short-lived credentials, RBAC, and JIT access around MCP tools.
• Example deployment patterns for securing enterprise MCP use cases across internal systems.

👉 Teleport's full article covers MCP architecture, implementation flow, and control gaps in more detail.

Deepen your knowledge

MCP governance and agentic AI access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for autonomous tool use, it is worth exploring.