MCP finds its permanent home in open agentic AI governance

At a glance

What this is: WorkOS covers the Linux Foundation’s new Agentic AI Foundation and argues that MCP, goose, and AGENTS.md are becoming shared infrastructure for agentic AI.

Why it matters: IAM and NHI teams need to treat agent-tool connectivity as governed access, because standardisation expands adoption faster than security controls mature.

Context

The new Agentic AI Foundation formalises open governance around MCP, goose, and AGENTS.md, three building blocks for agentic software that connects models to tools and project instructions. The identity question is no longer whether these components will be used, but how they will be governed when agents start coordinating across real systems.

For IAM and NHI programmes, the important shift is that agentic infrastructure is becoming a shared standard layer rather than a collection of isolated integrations. That changes where trust, authorisation, and audit responsibility sit, especially when multiple vendors and development teams rely on the same protocol surface.

Key questions

Q: How should security teams govern MCP servers used by AI coding assistants?

A: Treat MCP servers as privileged trust boundaries, not simple data sources. Security teams should classify each server by the authority it can influence, sanitize any user-generated or third-party content before delivery, and limit the agent’s tool access so malicious context cannot easily become destructive action.

Q: Why do open agentic standards increase the need for identity controls?

A: Open standards increase adoption because they lower integration friction, but they also spread the same protocol surface across many teams and vendors. Without strong identity controls, the same openness that improves interoperability also multiplies unreviewed access paths, weak attribution, and inconsistent authorisation decisions.

Q: What is the difference between application-layer security and infrastructure-layer governance for AI agents?

A: Application-layer security protects a single agent or app through built-in logic, SDKs, or model-level checks. Infrastructure-layer governance sits between the agent and the resources it wants to use, enforcing policy centrally in real time. For autonomous systems, governance is stronger because it can block risky actions across many agents without waiting for code changes.

Q: How can organisations tell whether agentic AI is ready for regulated use?

A: A useful test is whether each agent action can be tied to a known identity, an explicit permission boundary, and a durable audit trail. If those three elements are missing, the deployment may be functional, but it is not yet governed enough for regulated environments.

Technical breakdown

MCP as the tool connection layer for agents

MCP acts as the bridge between an AI agent and the tools or data sources it needs at runtime. In practice, that makes it a control surface for identity, because every tool call carries an implied authorisation decision even when the interaction feels like ordinary developer workflow. Under open governance, the protocol becomes more reusable, but also more visible as infrastructure that must be consistently authenticated and logged. The technical risk is not just access to a tool, but the accumulation of many small tool permissions that together define the agent’s effective scope.

Practical implication: treat MCP endpoints as governed access paths, not simple developer integrations.

Why AGENTS.md changes the trust model for coding agents

AGENTS.md gives project-specific instructions to coding agents, which means policy moves closer to the workspace and farther from centralised platform controls. That improves consistency, but it also creates a new trust dependency on local files that shape agent behaviour without a human being present at execution time. In identity terms, the file becomes part of the runtime governance layer, because it can influence what actions an agent attempts and how it interprets the task environment. This makes provenance, review, and scope control more important than the formatting of the guidance itself.

Practical implication: review AGENTS.md files as governance artefacts that influence agent behaviour and scope.

Open governance does not remove authentication and audit requirements

The move to a neutral foundation lowers ecosystem fragmentation, but it does not solve authentication, authorisation, or traceability. Shared governance can align vendors around common implementation patterns, yet enterprises still need to know which identity initiated a request, which tool was invoked, and whether the action was authorised for that context. In regulated environments, that distinction matters because interoperability only helps if the resulting actions can still be attributed and constrained. The real technical test is whether the standards ecosystem makes audit trails easier to produce, not just easier to discuss.

Practical implication: demand per-request identity, authorisation, and audit records before broadening agentic AI deployment.

NHI Mgmt Group analysis

Open governance turns agent-tool connectivity into identity infrastructure, not just developer ergonomics. MCP is no longer a niche integration pattern when thousands of servers and multiple major AI products depend on it. That makes protocol governance relevant to access control, auditability, and enterprise assurance, because the tool layer is now part of the identity perimeter. Practitioners should stop treating agent connectivity as a plugin problem and start treating it as governed access.

AGENTS.md shifts policy closer to execution, which changes where control failures emerge. A project file that steers agent behaviour is not the same as centrally enforced policy, because it lives in the workspace and travels with the code. That creates a governance gap between intent and enforcement: teams may believe the agent is following standards while the effective scope is being shaped locally. The practitioner conclusion is that local instruction files need the same review discipline as other identity-scoping artefacts.

Authentication and authorisation become the decisive trust layer for open agentic standards. Shared governance can reduce fragmentation, but it also increases the number of parties that will build on the same protocol surface. That makes the core question less about whether MCP becomes universal and more about whether universal adoption produces uniform control quality. If identity, permissioning, and logging are not designed in alongside the standard, interoperability simply scales inconsistency faster.

Agentic standardisation is repeating the container lesson, but with a deeper trust problem. Containers succeeded because the ecosystem aligned on a common abstraction layer; agentic AI is following a similar path. The difference is that agents do not just move code, they make runtime decisions about tools, context, and action timing. That means the governance model has to cover not only portability, but the identity consequences of autonomous or semi-autonomous execution.

Identity teams should expect governance pressure to move from application boundaries to protocol boundaries. The foundation model signals that more agent activity will occur through shared standards rather than bespoke point integrations. That increases the value of common policy, common logging, and common review models across development and production. The practitioner takeaway is straightforward: align IAM and NHI governance with the protocol layer before those standards become hard dependencies.

From our research library:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Protocol standardisation will shift attention from integration count to control quality. As agentic ecosystems converge around shared interfaces, the programme risk moves from “can we connect?” to “can we govern the connection?” That means IAM, PAM, and NHI teams will be asked to prove authorisation, revocation, and traceability at the protocol boundary rather than inside each application.

Identity governance for agents starts where runtime decisions are made. If an agent can select tools, read instructions from the workspace, and act without a human in the loop, then the governance model has to cover the entire request path. Mature programmes will map the identity of the requesting system, the context that shaped the request, and the controls that limit downstream action.

For practitioners

• Map MCP endpoints to governed access paths Inventory every MCP server and tie it to an owning team, an approved identity source, and a documented permission boundary so the protocol surface is visible to IAM and NHI governance.
• Review AGENTS.md files as policy inputs Treat project-level agent instructions as controlled artefacts, with review, versioning, and change approval wherever they can affect tool choice or task scope.
• Require per-request authorisation evidence Capture which identity initiated each tool request, what was approved, and which response or action was returned so audit trails can prove control, not just activity.
• Separate developer convenience from production trust Allow experimentation in lower-risk environments, but gate promotion of agentic workflows on explicit logging, authorisation, and revocation paths for connected tools.

Key takeaways

• The article frames the Agentic AI Foundation as an inflection point for agent-tool interoperability, but the practical consequence is that identity and authorisation move to the centre of the design.
• Open governance can reduce fragmentation across MCP, goose, and AGENTS.md, yet it also increases the number of systems that must share the same control expectations.
• For practitioners, the priority is to make agent requests auditable, permissioned, and revocable before open standards become hard dependencies in production.

Key terms

• MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.
• Agentic Artificial Intelligence Foundation: The Agentic Artificial Intelligence Foundation is an industry body created to steward foundational projects for agentic AI under a neutral governance structure. Its purpose is to coordinate open development and adoption, especially for shared infrastructure such as protocols and agent tooling used across enterprise environments.
• AGENTS.md: A project-level instruction file that an AI coding agent may load before handling a task. In autonomous workflows it behaves like executable context, so any command, path, or setup step inside it must be treated as potentially adversarial until reviewed and approved.
• Agent-to-tool access: The permission path that lets an AI agent call a real system, query data, or trigger an operation. Unlike ordinary application access, this path can span multiple tools in one session, so the effective privilege of the server matters as much as the agent's intent.

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 identity security programme, it is worth exploring.