TL;DR: The new MCP specification adds server identity checks, formal authorization metadata, long-running tasks, HTTP streaming, and registry-based discovery, reflecting a shift from trusted tool access to verifiable agent interactions according to Lakera. That changes the governance problem from simple connectivity to runtime control over what agents can discover, do, and keep doing.
At a glance
What this is: This analysis of the new MCP specification shows a move from implicit trust toward verifiable agent interactions through identity, authorization, tasks, streaming, and registry controls.
Why it matters: IAM and AI security teams need to treat MCP as governance infrastructure because discovery, delegated access, and long-running execution now create persistent control points for agent behaviour.
Context
MCP, or Model Context Protocol, is the layer that lets AI agents discover tools, fetch resources, and act through connected services. Lakera argues that the new specification changes the security model from asking what an agent can reach to verifying who the server is, what the agent is allowed to do, and how long that permission continues to matter.
The governance gap is not connectivity. It is the assumption that tool access can be trusted once a server responds to a request. As MCP matures into enterprise plumbing for agentic systems, identity verification, authorization metadata, task persistence, and registry trust become the controls that determine whether the protocol is governable at all.
Key questions
Q: What breaks when MCP servers are not vetted before use?
A: When MCP servers are not vetted, the enterprise loses control over privileged tool access inside AI workflows. A server can read files, call APIs, run commands, or mutate workflows before anyone confirms it is legitimate or minimally scoped. That creates a supply-chain path to secret exposure, workflow manipulation, and lateral movement through trusted automation.
Q: Why do long-running MCP tasks change the security model?
A: They turn a tool call into durable state. That means the governance problem is no longer only whether access was granted correctly, but whether the task can persist, resume, and keep acting after the original session has lost operator attention.
Q: How do security teams know whether MCP authorization is actually working?
A: Look for evidence that consent is stored per client, tokens are validated at each hop, and invalid audience or redirect values are rejected consistently. If a server accepts session-only state, relayed tokens, or vague consent prompts, authorization is functioning as a convenience layer rather than a control.
Q: What is the difference between MCP discovery and MCP provenance controls?
A: Discovery tells an agent what exists, while provenance tells the organisation what is trusted. Discovery is about finding tools and servers; provenance is about proving they are the right ones and that their runtime behaviour matches the approved record.
Technical breakdown
Server identity documents and capability verification
The new MCP model introduces a discoverable identity document for servers, which means the agent can compare what a server claims now with what it claimed before. That matters because the older trust model assumed the server’s self-description was stable and honest. In practice, capability sets, names, and descriptions can shift without the agent noticing unless there is an external reference point. Identity checks do not eliminate deception, but they make drift and impersonation observable, which is the minimum requirement for governance.
Practical implication: treat server identity as a control plane artifact and verify changes against an approved baseline before allowing agent use.
Protected resource metadata and authorization scope
Protected Resource Metadata formalises how a server declares authentication requirements, permissions, and eligible users. That shifts MCP from informal token handling to explicit authorization semantics, which is critical when agents request access on behalf of workflows rather than humans. Without declared scope, the agent cannot distinguish between a tool that is merely reachable and a tool that is legitimately usable. The result is ambiguous delegation, which is exactly how overreach enters agentic systems.
Practical implication: enforce explicit authorization metadata for every server and reject tools whose access requirements are not machine-readable.
Tasks, streaming, and persistent execution state
Tasks turn MCP from a synchronous request-response pattern into a long-running execution model. An agent can start work, disconnect, return later, and resume state that still exists on the server. HTTP streaming improves observability, but it also fragments the evidence trail across sessions and reconnections. That creates governance problems that look less like classic API calls and more like workflow state management, where the security question is no longer only what was called, but what remains active after the original call ends.
Practical implication: track task lifecycle, not just invocation, and bind monitoring to session continuity and resumption events.
Threat narrative
Attacker objective: The objective is to get an agent to execute or continue high-risk actions through a trusted MCP path that the operator believes is controlled.
- Entry occurs when an agent discovers and trusts an MCP server based on claimed capabilities and metadata rather than independently verified identity.
- Escalation follows when authorization is implicit, letting the agent inherit tool permissions that exceed the original trust boundary.
- Impact occurs when long-running tasks, streaming sessions, or registry-distributed servers keep operating after the initial interaction has faded from view.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
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
Verifiable discovery is now a governance requirement, not a convenience feature. MCP’s shift toward server identity documents reflects a broader lesson for agentic systems: discovery without verification is just delegated trust. Once agents can pull capabilities from registries or well-known locations, identity becomes part of the policy boundary, not a side detail. Practitioners should read this as a control-plane change, because the thing being governed is no longer just access, but discoverable authority.
Authorization metadata is the missing bridge between agent autonomy and enterprise accountability. The old MCP pattern let capability and permission blur together, which is tolerable only in demos. Formal metadata forces the environment to state what is permitted, by whom, and under what conditions. That matters because agentic systems do not merely use tools, they negotiate execution paths. The governance implication is clear: if permission cannot be expressed in metadata, it cannot be reliably governed at scale.
Tasks create an identity lifecycle problem inside the protocol itself. A task that outlives the session that created it is no longer a simple tool call, it is a managed execution object. That means the security team has to think about activation, persistence, resumption, and termination as lifecycle states rather than one-off events. Registry-based discovery compounds this because trusted onboarding now extends into ongoing provenance checks. Practitioner takeaway: govern MCP the way you would govern any durable non-human executor.
Long-running agent work invalidates assumptions built for synchronous control. Access review processes were designed for privileges that persist long enough to be reviewed. MCP tasks can appear, pause, and resume across time in ways that compress or bypass that review window. The implication is not merely that existing controls need tuning, but that the audit model itself must move closer to issuance and execution time. Practitioners should assume stateful agent behaviour will outpace periodic certification unless controls shift earlier in the lifecycle.
Registry trust will become the new supply-chain fault line for agentic infrastructure. Once MCP servers are installed, discovered, and trusted through manifests, the category inherits the same provenance and integrity questions that already trouble software packages. The article points to a coming control problem: declared capability and runtime behaviour may diverge. Practitioners should treat MCP registries as security-bound inventories, not convenience catalogs.
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: Shadow AI and AI Agent Discovery Guide
What this signals
Identity has moved into the protocol layer: once agents can discover tools through registries and well-known locations, server identity becomes a governance input rather than an implementation detail. That changes how security teams think about approval, because discovery now needs the same scrutiny as direct access.
Runtime verification matters more than static registration: an MCP server that is approved once can still change its capabilities later, so registry trust must be paired with runtime comparison. The practical implication is that control owners need a way to detect drift between declared tools and actual behaviour before agents consume it.
MCP configuration files are already a secrets exposure surface: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to the State of Secrets Sprawl 2026. That makes registry hygiene, secret scanning, and offboarding discipline part of MCP governance, not separate chores.
For practitioners
- Verify server identity before tool exposure Require a stable identity record for every MCP server and compare declared capabilities against an approved baseline before any agent is allowed to call tools.
- Formalise authorization metadata for each server Block any MCP integration that does not expose machine-readable permissions, eligible users, and authentication requirements for every tool and resource.
- Track task lifecycle as a security object Monitor task creation, resumption, and completion as separate governance events so long-running agent work cannot disappear between sessions.
- Treat registry entries as provenance-controlled inventory Compare registry declarations with runtime behaviour and investigate any server that appears locally but is missing from the approved registry.
Key takeaways
- MCP is moving agent governance from implicit trust to verifiable control over identity, authorization, and persistence.
- Long-running tasks and registry-based discovery create new governance states that periodic reviews do not capture well.
- Teams need to shift MCP oversight closer to issuance, runtime verification, and provenance checking if they want agent behaviour to remain governable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on agent identity, delegated authority, and runtime verification. |
| Recommendation — Treat MCP identity and authorization as agent-privilege controls and block unverified capability expansion. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Server identity checks and formal auth metadata address how MCP servers and agents authenticate. |
| NHI-05 — Overprivileged NHI | The article warns that agents can inherit excessive tool authority from loosely governed servers. | |
| NHI-07 — Long-Lived Secrets | Long-running tasks and registry trust extend the lifetime of access and the exposure window for secrets. | |
| Recommendation — Verify MCP server identity and require explicit authentication metadata before any agent tool access. Constrain MCP tool permissions to least privilege and reject servers whose declared access is broader than needed. Shorten MCP credential lifetime and bind long-running tasks to tightly controlled session state. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes trust abuse paths that can expose credentials and spread through connected tooling. |
| Recommendation — Map MCP trust failures to credential access and lateral movement patterns in your detection logic. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The topic is enterprise governance of agentic AI systems and their runtime accountability. |
| Recommendation — Define ownership, approval, and oversight for MCP-connected agents inside your AI governance programme. | ||
Key terms
- Mcp Server Identity: The identity assigned to the gateway that mediates agent requests to tools and data sources. It matters because the gateway can become a privilege concentration point if it shares credentials with the agent or inherits broader permissions than the task requires.
- Protected Resource Metadata: Protected resource metadata is machine-readable discovery data published by a service so clients can find its authorization expectations. For agent registration, it tells the actor where to look for supported flows and how to discover the trust model without relying on ad hoc integration.
- MCP Task: An MCP Task is a discrete unit of work an AI agent performs through the Model Context Protocol. It usually includes a goal, required context, tool calls, and expected output. In practice, it helps structure agent actions, control tool access, and support auditability across connected systems.
- Registry-based discovery: A model in which agents find MCP servers through structured listings or manifests instead of ad hoc connection details. The security concern is provenance, because discovery tells you what is available, while governance must still prove what is trusted and whether runtime behaviour matches the declaration.
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.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org