New MCP spec shifts AI agent governance from trust to verification

At a glance

What this is: This article explains how the new MCP specification changes AI agent security by adding identity, authorization, task, streaming, and registry controls.

Why it matters: It matters because IAM, NHI, and agentic AI teams now have to govern tool discovery and runtime access as an identity problem, not just an integration problem.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Lakera's analysis of the new MCP specification and agent identity risk

Context

MCP, or Model Context Protocol, is becoming the control plane for how AI agents discover tools, authenticate, and carry out work. The security gap is that early MCP treated tool access as a trust problem, while production agent environments now need identity, authorization, and session control.

For IAM and NHI teams, that matters because the protocol shifts governance from static permissions to runtime interactions that can change after a connection is established. Once agents can discover capabilities, start tasks, and resume work later, access control becomes a living identity issue rather than a one-time integration decision.

The new MCP specification tries to make those interactions more inspectable, but it also confirms that agent security now depends on governing server identity, tool metadata, and long-running execution paths together. That is a familiar IAM problem wearing an AI wrapper, and it is already past the proof-of-concept stage.

Key questions

Q: How should security teams govern MCP access for AI agents?

A: Security teams should govern MCP access as a privileged identity path, not as a simple plugin connection. That means approving servers, binding tools to specific resources, monitoring task state, and revoking access when the declared capability set changes. The goal is to make agent access verifiable across the full session lifecycle.

Q: Why do MCP servers create new identity risk for AI agents?

A: MCP servers create identity risk because agents discover capabilities dynamically and often trust the server’s description of those capabilities. If the server identity, tool list, or manifest changes after approval, the agent may inherit more authority than intended. That turns capability discovery into a governance checkpoint, not a convenience feature.

Q: What breaks when long-running MCP tasks are not governed?

A: When long-running MCP tasks are not governed, the security boundary shifts beyond the original approval moment. An agent can start work under one context, resume later, and complete actions after the original session has ended. That breaks auditability and makes traditional recertification too late to stop misuse.

Q: How can organisations reduce the risk of untrusted MCP tool registries?

A: Organisations should require provenance checks for any MCP registry entry before production onboarding. The key is to verify where the tool came from, whether the manifest matches the live server, and whether the approved capability set still reflects runtime behaviour. Without provenance, registry convenience becomes supply-chain exposure.

Technical breakdown

MCP server identity and capability discovery

MCP begins with capability discovery, where an agent learns what a server can do before it asks for tools or resources. The security change in the new spec is not that discovery exists, but that discovery can now be compared against a published identity document. That matters because the attack surface is not only malicious tools, but also capability drift, where a server’s advertised function changes over time. Identity verification gives defenders a reference point for detecting that drift, even if it does not stop a compromised or deceptive server from lying in the first place.

Practical implication: track server identity changes and compare declared capabilities against approved inventory before allowing agent use.

Protected resource metadata and authorization boundaries

Protected Resource Metadata formalizes how an MCP server expects authentication and what permissions are required for specific operations. This is a governance shift from informal trust to explicit authorization boundaries, which is exactly where IAM controls belong. In practice, it makes the permission model visible to policy engines, but only if teams map tool access to actual resource sensitivity. Without that mapping, the metadata becomes documentation rather than enforcement, and agents can still inherit broad access through loosely defined tool scopes.

Practical implication: bind MCP permissions to specific resources and review whether tool scopes are broader than the underlying data or action they expose.

Tasks, streaming, and long-running agent execution

The new task model turns MCP into more than a request-response protocol. Agents can now start work, disconnect, resume later, and retrieve results after the original session has moved on. That is useful for real workloads, but it also creates a governance problem because the security state is no longer tied to a single live exchange. Streaming and task resumption make the control boundary temporal as well as logical, which means monitoring must follow the task lifecycle, not just the login event.

Practical implication: monitor task initiation, resumption, and completion as separate identity events with policy checks at each transition.

NHI Mgmt Group analysis

MCP is turning agent access into an identity governance problem, not just an integration layer. The specification now exposes identity documents, authorization metadata, task state, and registry controls as separate enforcement points. That means the control question is no longer whether an agent can connect, but whether the connection is verifiable, scoped, and revocable across its full lifecycle. Practitioners should treat MCP as part of the identity stack, not as middleware.

Capability discovery is where trust assumptions collapse first. MCP was designed for servers that truthfully describe their tools at request time. That assumption fails when a server can change identity, alter capability claims, or register new functions after approval because the agent has no inherent way to know whether the advertised surface still matches reality. The implication is that tool discovery must be governed like any other privileged inventory, with change detection and approval boundaries.

Long-running tasks create a runtime governance gap that standard access reviews do not see. Access review processes assume privilege is stable long enough to be observed, recertified, and removed. MCP tasks break that premise by letting an agent initiate work, pause, and resume outside the original decision window. Practitioners should rethink how they evidence control over actions that outlive the session in which they were authorized.

Agentic AI inherits NHI problems, but with faster failure modes and less human friction. The more MCP becomes the backbone of production AI workflows, the more its identity model resembles machine identity governance under higher velocity. Tool scope, registry provenance, and task persistence are classic NHI concerns, but agent timing and decision autonomy make weak controls fail sooner. Security teams should assume that any gap in tooling identity governance will be exploited at machine speed.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• That same research shows organisations maintain an average of 6 distinct secrets manager instances, a fragmentation pattern that makes MCP-style governance harder to centralize, according to The State of Secrets in AppSec.

What this signals

MCP will force security teams to treat agent tool access as lifecycle-governed identity, not convenience plumbing. As agents start discovering tools, resuming tasks, and inheriting metadata-driven permissions, the old divide between integration and access control disappears. Teams that already struggle with fragmented secrets management will feel the pressure first, because the control surface is expanding faster than the governance model.

Task persistence is the named concept that matters here. Once an agent can initiate work and continue it after the original interaction, policy has to follow the task rather than the session. That shifts monitoring toward task provenance, resumption controls, and runtime authorization checks, which should be aligned with the NHI Lifecycle Management Guide and the OWASP Agentic AI Top 10.

With 43% of security professionals concerned about AI systems learning and reproducing sensitive information patterns from codebases, per The State of Secrets in AppSec, agent tool governance is now a data-loss issue as much as an access issue. That makes provenance, task logging, and capability drift detection part of the same control conversation. NHI and IAM teams should prepare for MCP to become a standard place where secrets, permissions, and execution state intersect.

For practitioners

• Inventory MCP servers and their declared capabilities Maintain an approved list of MCP servers, compare declared tools against actual runtime behavior, and flag capability drift as a policy exception. Treat a new server identity the same way you would treat a new privileged integration.
• Bind tool access to resource-level authorization Map each MCP tool to the specific data, action, or system it can touch, then reject broad scopes that are not justified by the underlying business function. Resource metadata should drive enforcement, not just documentation.
• Monitor task lifecycle events as security events Track task creation, pause, resume, and completion as distinct audit points, and require policy checks when a task crosses session boundaries. This closes the gap between one-time approval and later execution.
• Add registry provenance checks to agent onboarding Validate where an MCP server was published, who approved it, and whether the manifest matches the live server before allowing production use. Registry provenance is a supply-chain control for agent tools.

Key takeaways

• MCP is no longer just an AI integration protocol, it is becoming a governed identity surface for agent actions.
• The main risk shift is from static tool trust to runtime control over identity, authorization, and task persistence.
• Teams that already struggle with secrets fragmentation will need to extend those controls into agent discovery, registry provenance, and task lifecycle monitoring.

Key terms

• Model Context Protocol: A standard that lets AI agents discover tools, request resources, and interact with external systems through a common interface. In practice, it becomes an identity and authorization layer because the agent must trust what the server says it can do, unless the deployment adds verification and scope controls.
• Capability Discovery: The step where an agent learns what actions, tools, or resources a server offers before using them. For agentic systems, this is not just a usability feature. It is a security checkpoint because discovery determines the authority the agent may inherit and the controls that must validate that authority.
• Task Persistence: The ability for a request to continue beyond the original interaction, then resume later with the same or related context. In agentic environments this extends the security boundary across time, which means governance must follow the task lifecycle rather than rely on a single access decision.
• Registry Provenance: Evidence showing where a tool, server, or manifest came from and who approved it. For MCP and other agent ecosystems, provenance helps teams distinguish approved components from spoofed or unverified ones, which is essential when tool discovery can automatically expand an agent’s effective privileges.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.

This post draws on content published by Lakera: What the New MCP Specification Means to You, and Your Agents. Read the original.