Agentic AI Foundation signals a new governance layer for MCP

At a glance

What this is: This is a governance shift around MCP and the new Agentic AI Foundation, with the key finding that shared protocol stewardship is becoming the control plane for agent connectivity.

Why it matters: It matters because IAM, NHI, and emerging agentic AI programmes will increasingly depend on protocol governance to define who or what can connect, act, and be trusted across systems.

👉 Read WorkOS's recap of the Agentic AI Foundation and MCP governance panel

Context

MCP is the protocol layer that lets AI systems connect to tools, data sources, and applications. The article is about what happens when that layer moves from a vendor-led project into a shared governance model, because identity and access decisions will increasingly be mediated through protocol rules, not just application policy.

For IAM and NHI programmes, this matters because tool access is only as trustworthy as the identity controls behind the protocol. Once multiple vendors and open source contributors govern the same agentic interface, organisations need to treat MCP as part of their access architecture, not just a developer convenience.

Key questions

Q: How should security teams govern AI agents that connect through MCP?

A: Security teams should govern MCP-connected agents as non-human identities with explicit tool boundaries, monitored delegation, and auditable action paths. The key is to bind agent identity to each tool call, not just to the session, so access decisions remain visible and revocable across clients and connectors.

Q: What should IAM teams review before allowing MCP in production?

A: IAM teams should review how the protocol establishes identity, how tool permissions are assigned, and whether the same policy is enforced consistently across clients. If the answer differs by implementation, the organisation has a governance gap that can produce uneven access and weak audit trails.

Q: Why does shared governance matter for agentic AI protocols?

A: Shared governance matters because agentic protocols shape how identities reach tools and data, which makes protocol design part of the authorisation model. When many parties influence the standard, security teams need to watch for inconsistent enforcement, unclear accountability, and policy drift across implementations.

Q: What is the difference between agent identity policy and tool policy?

A: Agent identity policy governs who or what is allowed to initiate action, while tool policy governs what that identity can reach once a request is made. Both must align, because a strong agent policy with weak tool policy still allows overbroad actions through permitted integrations.

Technical breakdown

Why MCP governance becomes an access-control problem

MCP is not just a transport for messages. It defines how an AI system discovers tools, requests context, and executes actions across external systems. That makes the protocol part of the authorisation path, because the identity attached to an agent or client determines what it can reach and what it can do. When governance shifts into a foundation model, the key technical issue is whether protocol changes preserve predictable trust boundaries across vendors, clients, and tools. If those boundaries are unclear, access decisions become inconsistent across implementations.

Practical implication: treat MCP policy as part of your identity architecture and review how tool access is authorised at the protocol layer.

Open source reference implementations reduce ambiguity, not risk

A vendor-neutral client such as Goose gives the ecosystem something to test against, but reference implementations do not eliminate identity risk. They make protocol behavior more observable, which helps surface edge cases in authentication, delegation, and tool invocation. The harder issue is that any agentic protocol can be implemented differently by each client, connector, or platform. That variation matters because security teams often assume one control model will behave uniformly across all endpoints, which is rarely true once agents, plugins, and external tools are involved.

Practical implication: validate protocol behavior in your own environment rather than assuming one MCP implementation represents all of them.

Agent-to-tool communication needs governance beyond the model layer

The article makes clear that the ecosystem is bigger than one standard, which is exactly why identity governance has to extend beyond the model itself. In practice, the model may decide to act, but the protocol determines how that action reaches a tool, API, or dataset. That means the real control point is the combination of agent identity, tool identity, and policy enforcement at connection time. If those identities are weakly governed, the protocol becomes a path for overreach even when the model is behaving as designed.

Practical implication: define which identities may initiate tool calls and enforce those boundaries before agent execution reaches production systems.

NHI Mgmt Group analysis

Shared protocol governance is becoming the new identity boundary for agentic systems. Once multiple vendors and open source contributors govern MCP together, the security question shifts from isolated product trust to ecosystem trust. That creates a control surface where tool access, context access, and execution permissions must be consistent across implementations. For identity teams, the practical conclusion is that protocol governance now sits inside the access model, not outside it.

MCP turns agent authorization into a multi-party policy problem. Anthropic, OpenAI, Block, and the Linux Foundation are not just coordinating code, they are coordinating the rules that define how agents interact with tools. That changes the security conversation for IAM and NHI teams because the same identity may behave differently depending on the client, connector, or steering decision. The implication is that entitlement management for agents cannot rely on application-by-application assumptions.

Agentic AI needs a governance layer that looks more like infrastructure stewardship than product management. The article’s core signal is that the market is converging on a common substrate, which usually means security controls will follow standardization pressure. That is good for consistency, but it also means policy failures can propagate faster across the ecosystem. Practitioners should expect MCP governance to become part of broader enterprise identity design, not a niche integration detail.

Protocol neutrality does not equal security neutrality. A shared standard can improve interoperability while still leaving gaps in authentication strength, delegation boundaries, and auditability. The foundation model will likely accelerate adoption, but adoption without identity discipline simply scales inconsistency. The practitioner takeaway is to interrogate how each MCP deployment binds agent identity to action authority before production use.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, 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.
• For the governance layer behind this trend, see OWASP Agentic Applications Top 10 for the control patterns practitioners are now mapping to agentic access.

What this signals

Agentic protocol adoption will force identity teams to move policy closer to the connection layer. When agents connect through a shared standard, the old assumption that application teams can handle access locally starts to break down. The practical shift is toward connector-level policy, agent-specific logging, and tighter ownership of non-human access paths, especially where external tools and internal data systems intersect.

Protocol standardisation will expose the weakest part of many AI programmes: auditability. If teams cannot tie a tool call back to a specific agent identity and policy decision, they will struggle to certify access or investigate misuse. That is why the governance problem is not just interoperability. It is whether the enterprise can prove who acted, through which connector, and under what authority.

For practitioners

• Map MCP into your identity architecture Document where agent identity is established, where tool authorization occurs, and which control owns each decision point before MCP reaches production.
• Review connector-level access boundaries Check whether each tool connector enforces least privilege independently or inherits broad permissions from the host agent or platform.
• Test protocol behavior across implementations Compare how different clients handle authentication, delegation, and context exposure so your policy does not depend on one vendor's assumptions.
• Add auditability to agent-to-tool calls Require logs that tie the requesting identity, the tool invoked, and the action outcome together for incident review and access certification.

Key takeaways

• MCP governance is becoming part of enterprise identity architecture, not a separate developer concern.
• Shared protocol stewardship can improve consistency, but it also scales any weakness in authentication, delegation, or audit design.
• Practitioners should test how agent identity maps to tool authority before allowing MCP-driven access into production systems.

Key terms

• Agentic AI Foundation: A shared governance body for standards that let AI agents connect to tools, data, and other systems. In identity terms, it matters because protocol stewardship increasingly shapes access, delegation, and auditability across multiple vendors and implementations.
• Mcp: A protocol that defines how AI systems discover and use external tools and data sources. For security teams, it functions as part of the authorisation path, because the protocol determines how an agent identity reaches and interacts with resources.
• Agent Identity: The identity assigned to an AI system or agent when it acts on behalf of a user or application. It must be governed like a non-human identity, with clear boundaries for initiation, delegation, logging, and revocation across tools and sessions.
• Tool Authority: The set of permissions that determines what an agent or application can do once it reaches a tool, API, or service. It is distinct from session identity and must be controlled separately so permitted connections do not become overbroad actions.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by WorkOS: The Agentic AI Foundation and the MCP governance panel recap. Read the original.