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.
NHIMG editorial — based on content published by Lakera: What the New MCP Specification Means to You, and Your Agents
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
Lakera's full blog post covers the operational detail this post intentionally leaves for the source:
- The exact MCP request and response flow that governs tool discovery, including how servers present capability lists.
- The new identity and authorization metadata patterns that practitioners need to map into policy enforcement.
- The task model details for long-running agent operations, including how pause and resume change the attack surface.
- The registry and manifest mechanics that create supply-chain risk for agent tools.
👉 Read Lakera's analysis of the new MCP specification and agent identity risk →
New MCP spec: what changes for AI agent governance now?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: New MCP spec shifts AI agent governance from trust to verification