Model context protocol leaves NHI governance to the caller

At a glance

What this is: This is a Teleport explainer on Model Context Protocol that finds MCP standardises model-to-tool interaction but leaves the hard security and governance decisions outside the protocol.

Why it matters: IAM, NHI, and platform teams need to treat MCP as an integration layer that still requires identity verification, scoped authorisation, logging, and revocation controls around every connected tool.

👉 Read Teleport's article on Model Context Protocol security and governance gaps

Context

MCP is a protocol for connecting LLMs to tools, data, and services through structured requests. The governance gap is that the protocol standardises communication, not trust, so identity checks and access decisions must be imposed by the implementation.

That matters because enterprise MCP deployments often expose databases, cloud APIs, SaaS systems, and infrastructure tooling through the same interface. Without external control layers, the protocol can turn ordinary model connectivity into an ungoverned action surface for NHI-style access.

Teleport's article is useful because it separates interoperability from security. The central question for practitioners is not whether MCP works, but which identity, logging, and revocation controls have to surround it before it is safe to use at scale.

Key questions

Q: What fails when MCP tools are exposed without external identity controls?

A: The failure is not the protocol itself but the gap between discovery and enforcement. MCP can tell a model what tools exist, yet without external identity checks, every authorised client can potentially reach tools beyond its intended scope. That breaks least privilege because the server is still responsible for deciding who may invoke which action.

Q: Why do MCP deployments need short-lived credentials and revocation controls?

A: Because persistent tokens turn a temporary model session into durable access. If the client credential cannot be expired quickly, a leaked key or compromised integration can continue to call tools long after it should have been cut off. Short-lived credentials reduce the blast radius and make revocation meaningful in real time.

Q: How do security teams know whether MCP server governance is working?

A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.

Q: How should security teams handle approval for high-risk MCP actions?

A: Approval should be reserved for actions that are irreversible, high impact, or likely to change access, data exposure, or production state. The goal is not to slow every task, but to stop the few actions that create real business risk if executed incorrectly. Approval should occur before the sensitive permission is granted or the action executes.

Technical breakdown

How MCP client-server discovery works

MCP uses a client-server model in which a host runs the model and one or more clients connect to servers that expose tools, resources, and prompts. The model first discovers what is available, then receives structured metadata about parameters and expected outputs, and finally sends a JSON request to invoke a selected tool. That structure reduces integration sprawl, but it does not itself decide who may call what or under which trust conditions.

Practical implication: govern discovery and invocation separately, because protocol visibility is not the same as authorisation.

Why MCP tool schemas do not equal security policy

MCP tool schemas describe names, inputs, outputs, and access scope, but they are contracts for communication rather than enforcement engines. The article is explicit that security, access control, and observability are left to the implementation. In practice, that means a schema can declare role-restricted access while the server still has to verify identity, enforce privilege, and reject unauthorised calls at runtime.

Practical implication: treat tool schemas as metadata and enforce policy in a separate identity-aware control layer.

Why revocation and audit are outside the protocol boundary

MCP has no native mechanism for session expiry, revocation, human approval, or built-in logging of tool invocations. Once a client is connected, the article notes that persistent access can remain in place unless the implementation adds short-lived credentials, telemetry, and external approval flows. That makes the runtime control plane more important than the protocol itself for environments where tool calls can change state, trigger workflows, or reach privileged systems.

Practical implication: add session-bound credentials, audit logs, and approval gates outside MCP before exposing high-impact tools.

Threat narrative

Attacker objective: The objective is to turn a structured model-to-tool interface into a durable path for unauthorised actions that are hard to detect, constrain, or revoke.

1. Entry occurs when an MCP client is allowed to connect to a server that exposes discoverable tools and callable actions.
2. Credential exposure or misuse follows when the implementation relies on long-lived API keys or tokens that are difficult to monitor and revoke.
3. Escalation happens when declared scopes are not enforced by an external authorisation layer and the model can invoke higher-impact tools than intended.
4. Impact appears when unaudited tool calls trigger data access, workflow changes, or containment actions without revocation or approval controls.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP does not create governance, it exposes where governance must already exist. The protocol standardises discovery and invocation, but the article makes clear that identity verification, scope enforcement, logging, and revocation are all external responsibilities. That means MCP is not a control plane for trust, only a transport for action. Practitioners should treat every MCP deployment as an identity architecture decision, not a plugin decision.

The assumption that a tool schema can describe trust is too weak for enterprise access control. A schema can name a role or input format, but it cannot prove who is calling, whether the caller should still have access, or whether the session should continue. This is why MCP governance has to be layered with policy enforcement, not inferred from the protocol contract. The implication is that access scope must be validated at runtime, not merely declared at build time.

Long-lived credentials are the most obvious failure mode in MCP deployments. The article warns that hardcoded keys and tokens create access that is difficult to monitor or revoke, which is exactly the pattern identity teams have spent years trying to remove from machine access. In MCP, that risk is amplified because the same credential can unlock multiple tools, systems, and workflows. The practitioner takeaway is to assume every persistent token expands blast radius across tool boundaries.

Identity-aware governance is the real product requirement around MCP. Zero trust, short-lived credentials, RBAC, audit logging, and just-in-time access are not add-ons in this model. They are the conditions that decide whether MCP stays a structured integration protocol or becomes a high-risk control bypass for tool invocation. Teams that cannot enforce those controls should treat MCP as not yet production-ready for privileged workflows.

Runtime accountability is the missing layer in most MCP conversations. The article's strongest point is that monitoring and compliance depend on logging every invocation with client identity, tool name, and parameters. Without that record, organisations cannot reconstruct model behaviour or defend access decisions after the fact. The implication for governance teams is that observability must be designed as part of authorisation, not as a downstream SOC concern.

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

MCP adoption should be read as a governance test, not just an integration pattern. When tool discovery and action execution sit behind the same interface, identity teams have to prove that authorisation, telemetry, and revocation operate outside the protocol and not merely in the application code.

Protocol boundary control: the useful design pattern is to keep MCP at the transport layer while moving trust decisions into an external policy and identity plane. That is the difference between an orchestrated workflow and an ungoverned action surface.

The strongest immediate signal for practitioners is whether their MCP implementation can issue short-lived, session-bound access and produce an audit trail for every call. If not, the programme is already depending on assumptions that the protocol itself does not enforce.

For practitioners

• Layer identity verification around MCP servers Require mutual TLS, signed tokens, or gateway-enforced identity checks before any client can discover or invoke tools.
• Enforce runtime authorisation on declared scopes Validate every tool call against caller identity and current policy instead of trusting role labels embedded in schemas.
• Replace persistent credentials with short-lived access Use session-bound certificates or tokens with expiry and rotation so compromised MCP clients do not retain durable access.
• Log every tool invocation with identity context Capture tool name, parameters, client identity, and outcome so security and compliance teams can trace model actions end to end.
• Gate high-risk tools behind external approval Require separate approval workflows for state-changing actions such as infrastructure updates, data exports, or containment steps.

Key takeaways

• MCP standardises model-to-tool communication, but it does not provide the trust enforcement needed for enterprise access decisions.
• The main risk is that discoverable tools become callable actions without equivalent identity verification, auditing, or revocation.
• Practitioners should put policy, logging, and short-lived credentials outside the protocol before using MCP for privileged workflows.

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.
• Tool Schema: A tool schema is the structured description of a tool’s inputs and expected response. For agents, it acts like an interface contract that reduces ambiguity and helps the model choose the right action. Weak schemas create confusion, failed calls, and inconsistent behaviour across integrations.
• Session-Bound Credential: A short-lived token or certificate tied to a specific interaction window rather than a durable integration. For MCP, this is the practical control that prevents a connected client from keeping standing access after the intended task ends.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

What's in the full article

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

• Step-by-step explanation of MCP hosts, clients, servers, and tool schemas
• Examples of MCP deployment models across local machines, enterprise networks, and cloud services
• Teleport's control-layer approach for adding identity checks, RBAC, and audit logging around MCP
• The article's FAQ section on using MCP with existing APIs and SDKs

👉 Teleport's full article covers MCP architecture, deployment patterns, and control gaps in more operational detail

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.