MCP Is Becoming the Nervous System of AI. IAM Must Be Its Control Plane.

MCP may become one of the most consequential technologies in the enterprise AI stack, not because it makes artificial intelligence smarter, but because it gives AI something intelligence has always wanted: reach. The Model Context Protocol (MCP) is rapidly creating a common way for AI systems and agents to communicate with tools, applications, databases, files, APIs, development environments, and enterprise services. Anthropic originally introduced MCP as an open standard for connecting AI assistants with the systems where data lives. Since then, its growth has been extraordinary. By July 2026, the MCP project reported that its Tier-1 SDKs were approaching half a billion downloads per month, with its TypeScript and Python SDKs each having crossed one billion total downloads. MCP is no longer an interesting laboratory experiment. It is becoming infrastructure.

That should excite us. It should also make every CISO, CIO, identity architect, and risk executive slightly uncomfortable, because every new connection between an AI agent and an enterprise system creates another pathway through which authority can travel. That is the part of the MCP discussion we are not talking about nearly enough.

We are spending enormous amounts of time asking how AI agents will connect to enterprise systems. We are spending considerably less time asking what happens after they connect. Who authorized the agent? Whose authority is it using? What exactly is it allowed to do? Why is it performing the action? Should the permission exist for five seconds, five minutes, or five months? Can the agent delegate that authority to another agent? What happens when the context changes halfway through the transaction? And perhaps most importantly, who has the ability to stop it?

These are not primarily AI questions. They are identity questions.

For years I have argued that the old IAM model was reaching the end of its useful life. Identity architectures built around static accounts, periodic certification, fixed roles, authentication events, and relatively predictable human behavior were already struggling with cloud, APIs, workloads, service accounts, and non-human identities. AI agents did not create that weakness. They exposed it. MCP could now amplify it on an entirely different scale.

MCP provides connectivity. IAM 3.0 must provide control.

MCP Changes the Identity Equation

At its simplest, MCP gives AI systems a standardized way to discover and interact with capabilities outside the model itself. MCP servers can expose resources, prompts, and tools, and those tools can allow an AI system to perform actions rather than merely generate text. The MCP specification itself acknowledges the significance of this capability, warning that the protocol enables powerful paths involving arbitrary data access and code execution.

That distinction matters enormously. We spent the first era of generative AI worrying about what the model could say. The next era is about what the model can do.

An AI system that answers a question incorrectly is a problem. An AI agent that can access a database, modify a customer record, initiate a business process, change source code, query financial information, provision infrastructure, send communications, or invoke another system is something entirely different. It possesses authority.

Once AI possesses authority, identity becomes inseparable from AI governance.

MCP itself is not inherently insecure. In fact, the protocol has continued to mature its security architecture. Current MCP specifications include OAuth-based authorization for HTTP transports, audience restrictions, protected resource metadata, short-lived-token recommendations, PKCE protections, and explicit rules intended to prevent dangerous practices such as token passthrough. Those are important protections.

But OAuth does not answer the larger enterprise question. A perfectly authenticated AI agent can still make a catastrophically wrong decision. A valid access token can still authorize too much. A legitimate agent can still act outside the business purpose for which its authority was delegated. An agent can be properly authenticated at 9:00:00 and become an unacceptable risk at 9:00:05.

Authentication tells us who, or increasingly what, is presenting itself. It does not necessarily tell us whether the action it is about to perform should occur. That difference is the heart of the MCP identity problem.

The Attack Surface Is No Longer Just Connectivity. It Is Authority.

Traditional cybersecurity thinking tends to measure attack surface by counting devices, applications, APIs, accounts, endpoints, and network connections. Agentic AI forces us to add another dimension: the attack surface of authority.

MCP can dramatically increase the number of systems an AI agent can reach. That interoperability is exactly why the protocol is valuable. Instead of developers creating separate proprietary integrations for every model-to-system relationship, MCP provides a common mechanism through which AI can interact with enterprise capabilities. But abstraction works both ways. The easier we make legitimate connectivity, the more important governance of that connectivity becomes.

Imagine an enterprise agent originally designed to summarize customer information. It is given access through MCP to a CRM platform, a customer database, an email service, an analytics platform, and a document repository. Today it reads. Tomorrow somebody adds another MCP tool and now it can update. Another server appears and now it can execute. Another agent delegates work to it and suddenly it may possess authority that no human security architect explicitly designed.

Nothing necessarily failed. That is precisely the problem. The architecture evolved faster than the governance model.

The blast radius of a compromised or malfunctioning agent is therefore no longer determined simply by the application in which that agent resides. It can increasingly be defined by everything that agent can reach, everything its credentials authorize, every tool available through its MCP environment, and every downstream authority it can invoke.

That is a profoundly different security model.

The Identity Population Has Already Escaped the Human Model

This is occurring while enterprise identity itself is undergoing an enormous demographic shift. Palo Alto Networks' 2026 Identity Security Landscape research reports that machine identities now outnumber human identities by 109 to 1, up from 82 to 1 the previous year. The same research also reports widespread adoption of AI agents and substantial gaps in organizations' ability to revoke agent credentials and maintain immutable records of what those agents have done.

That should end any remaining argument that IAM can continue to be designed primarily around employees logging into applications. Humans are becoming the minority identity population.

AI agents make the difference even more profound because they are not merely another type of service account. Traditional machine identities generally execute predefined logic. An AI agent can interpret an objective, choose a tool, evaluate information, alter its approach, invoke another service, and take actions based upon changing context.

That means we are introducing identities whose behavior cannot always be predicted simply by examining their permissions. An entitlement tells us what the agent can do. It does not tell us what the agent will do.

That gap is where runtime identity becomes critical.

Authentication Is Not Authorization, and Authorization Is No Longer Enough

For decades we have repeated one of IAM's most basic lessons: authentication is not authorization. MCP makes that distinction more important than ever.

Suppose an authenticated financial AI agent has permission to access a corporate database. Fine. Should it read the database? Probably. Should it update a record? Perhaps. Should it delete ten million records? Almost certainly not. Should it initiate a $20 million payment because the information it received from another AI system told it that the payment was legitimate? Now we have moved far beyond authentication.

The difficult question is no longer simply whether an identity has an entitlement. The question is whether a particular identity should be allowed to perform this action, against this resource, at this moment, for this purpose, under this delegated authority, given the current risk and business context.

That is runtime authorization, and it must occur at machine speed because the actors themselves are operating at machine speed.

The industry can no longer pretend that quarterly access certifications constitute meaningful governance for autonomous systems capable of completing thousands of actions before a human analyst has finished opening an incident ticket. As I have argued in my work on IAM 3.0, periodic governance becomes irrelevant when the attack surface is continuous. The control architecture must become continuous as well.

Every MCP Interaction Should Be Treated as an Identity Transaction

This is where I believe enterprise MCP architectures need to change. An MCP request should never be viewed simply as a technical request between a client and server. It should be treated as an identity transaction.

That transaction should contain, or be associated with, enough information to answer some very basic questions. Who is the agent? Who or what created it? Who authorized it to act? On whose behalf is it operating? What authority was delegated? What is the requested action? What business purpose or objective caused that action? What resource will be affected? What is the current risk context? What policy applies? How long should the authority remain valid? Can the authority be delegated again? And what must be recorded so that the enterprise can reconstruct the decision afterward?

That is the identity envelope that must surround agentic computing.

A username and bearer token are not enough anymore.

MCP Cannot Become Trusted Plumbing

One of the most dangerous mistakes enterprises can make is allowing MCP to become what I call trusted plumbing. Trusted plumbing is infrastructure everyone assumes somebody else secured. The connection works. The token validates. The API responds. The agent completes the task. Therefore, everybody assumes the system behaved correctly.

But connectivity is not governance.

An MCP server may correctly authenticate a client and validate that a token was intended for that server. That is necessary protocol security. It still does not automatically establish whether the requested enterprise action conforms to corporate policy, whether the delegated authority remains appropriate, or whether a chain of agents has accumulated privilege that no longer resembles the authority originally granted.

This distinction is crucial. MCP should secure MCP. The enterprise must govern the authority flowing through MCP. Those are related responsibilities, but they are not identical.

The protocol team cannot know whether a particular financial transaction violates your segregation-of-duties policy. It cannot inherently know whether a medical AI agent should see a particular patient record given the agent's current purpose. It cannot determine whether a procurement agent that normally places $5,000 orders should suddenly purchase $900,000 of equipment. It cannot know whether an employee who originally delegated authority to an agent has changed roles, been terminated, entered a restricted geography, or had his or her account compromised three minutes earlier.

Those decisions belong in the enterprise identity and policy architecture.

This Is Why Identity Fabric Alone Is Not Enough

The identity industry has spent years talking about identity fabrics. The concept has value. An identity fabric can connect directories, identity providers, governance platforms, authentication services, privileged-access systems, authorization engines, applications, and other identity infrastructure.

But connection alone does not create control.

I have made this distinction repeatedly in my writing on IAM 3.0: the fabric is the means. Governed access is the outcome.

A fabric primarily tells systems how to work together. An orchestration layer determines what should happen when conditions change. That difference becomes enormous in an MCP environment.

An enterprise may have excellent identity infrastructure underneath its AI architecture: modern directories, strong MFA, sophisticated IGA, PAM, CIEM, authorization platforms, fraud systems, behavioral analytics, and threat detection. Every one of those systems may function perfectly, and the enterprise may still have no single mechanism capable of coordinating the decision when an AI agent attempts an unexpected action across several of them.

This is the architectural gap IAM 3.0 was designed to address.

IAM 3.0 Becomes the Control Plane

IAM 3.0 is not another IAM product. It is an architectural model.

The fundamental idea is simple. Instead of replacing every identity technology an enterprise already owns, place a dynamic orchestration and control layer around the identity fabric. That layer observes context, coordinates systems, evaluates policy, responds to changing risk, and changes the identity journey without forcing every underlying platform to be redesigned.

MCP makes this architecture even more important.

Think of MCP as part of the nervous system through which AI agents communicate with enterprise capabilities. IAM 3.0 becomes the control plane determining which signals are permitted to travel through that nervous system, what authority accompanies them, and when that authority must be changed or terminated.

That orchestration layer could evaluate identity and policy before a tool invocation occurs. It could request additional authorization, reduce privilege, issue a just-in-time entitlement, substitute a read-only connection for a write connection, deny the transaction, terminate an agent session, invoke fraud detection, trigger step-up authentication from the human principal, force human approval, or quarantine the identity.

And because IAM 3.0 is an orchestration architecture rather than another silo, those decisions can coordinate capabilities that already exist across the enterprise.

That is the difference between owning identity technologies and possessing an identity control plane.

Delegation May Become the Hardest Identity Problem of the AI Era

There is another issue hiding underneath MCP that deserves far more attention: delegation.

AI agents frequently operate on behalf of someone else. A person authorizes an agent. That agent invokes a tool. The tool interacts with a service. One agent may call another agent. The second agent may invoke another MCP server. Soon we are several levels removed from the human or business process that originated the authority.

Who owns the authorization at that point?

This is not an academic question. Delegation chains could become one of the defining identity problems of the agentic era.

We need to preserve the relationship between the principal, the agent, the delegated authority, the requested action, and the resulting transaction. Otherwise authority will become detached from accountability, and once authority becomes detached from accountability, governance collapses.

Traditional IAM was designed largely around direct relationships. Joseph can access Application A. Agentic computing increasingly creates chained relationships. Joseph authorized Agent A to perform Task X. Agent A invoked Agent B to obtain information from Tool C, which triggered Service D, which used Identity E to modify System F.

Now answer a simple audit question: who changed the record?

The traditional identity stack may give you five technically correct answers and still fail to tell you who was actually responsible.

IAM 3.0 must preserve that chain of authority.

Context Must Travel With Authority

This leads to another principle I believe will become fundamental: authority without context is dangerous.

Traditional entitlements tend to answer questions in binary terms. Allowed or denied. Member or not a member. Administrator or user. Agentic AI requires a richer model.

An agent may have permission to perform an action only when acting for a specific user, only for a specific workflow, only against a specific dataset, only below a transaction threshold, only from an approved environment, only during a particular time window, only while the originating user's employment status remains valid, only while the risk score remains beneath a defined level, or only while the business purpose remains unchanged.

In other words, authorization becomes conditional.

Context must therefore travel with authority. The enterprise cannot simply give AI an access token and hope that the assumptions under which that token was created remain true for the next hour. AI moves too quickly. The world around the identity can change before the token expires.

The Economics Make Waiting Increasingly Dangerous

We are already seeing what happens when AI increases the speed of cyber operations.

IBM's 2026 Cost of a Data Breach research found that AI-enabled malicious breaches increased 56 percent year over year and averaged roughly $6 million per incident, about $1 million above the overall global breach average of $4.99 million. IBM also reported that AI is compressing attack timelines while increasing the importance of rapid detection and remediation.

This is the larger security lesson. Attackers no longer need humans to perform every step. Defenders cannot continue requiring humans to approve every defensive step.

Machine-speed attacks require machine-speed identity decisions.

That does not mean removing humans from governance. It means moving human governance into policy so that machines can enforce the decisions humans have established. That is an important distinction.

Automation without governance creates chaos. Governance without automation becomes too slow to matter.

IAM 3.0 sits between them.

MCP Security Ultimately Becomes an Identity Orchestration Problem

We will continue improving MCP security, and we should. The protocol needs strong authentication, secure authorization flows, audience-bound tokens, hardened servers, protected credentials, good client isolation, consent mechanisms, logging, and secure development practices.

But none of those eliminate the larger enterprise problem.

Once MCP enables an autonomous actor to interact with multiple systems, security becomes an orchestration problem across identity domains. The database knows its permissions. The SaaS platform knows its permissions. The API gateway knows its permissions. The authorization platform knows its policies. The identity provider knows the identity. The IGA system knows the entitlement. The PAM platform knows privileged access. The SIEM knows the alerts. The fraud platform knows suspicious behavior. The MCP server knows the tool.

But who knows the whole transaction?

That is the missing layer.

IAM 3.0 is designed to become that layer. It does not eliminate those technologies. It conducts them.

The Architecture I Believe Enterprises Need

The enterprise AI architecture that emerges over the next several years should treat MCP connectivity as one component of a larger identity-controlled environment. MCP provides standardized connectivity. The identity fabric supplies identity services and integrations. Authorization systems provide policy enforcement. Security systems contribute risk signals. And above them sits a dynamic IAM 3.0 orchestration layer capable of evaluating the complete transaction in real time.

Conceptually, the flow becomes simple: human or business authority moves to an AI agent, through an IAM 3.0 policy and orchestration layer, through MCP, and then to the enterprise tool or service, with continuous monitoring and reevaluation throughout the transaction.

That control plane should be able to continuously answer four questions: Who is acting? Under whose authority? What are they attempting to do? Should they still be allowed to do it right now?

If the enterprise cannot answer those four questions, it does not control its AI agents.

It merely connects them.

The Industry Is Catching Up to the Problem

I have spent years arguing that identity would eventually become the primary control plane of the enterprise. Not because networks disappear. Not because endpoints disappear. Not because application security becomes irrelevant. But because every meaningful digital action eventually reduces to some form of authority.

Who can do what? To what? Under what conditions? For how long? And who decided?

The arrival of autonomous AI agents validates the urgency of that model.

The old IAM playbook was designed for a world in which humans initiated most meaningful actions, machines followed predictable instructions, and authorization decisions remained valid long enough to be managed through relatively static policies.

That world is disappearing.

Real revolutions do not politely integrate with existing architectures. They expose their assumptions.

AI has exposed one of IAM's biggest assumptions: that authentication happens near the beginning of a predictable journey and that everything afterward largely follows from that original decision.

That assumption no longer holds.

With autonomous agents, the journey itself must continually earn the right to continue.

That is IAM 3.0.

The Window to Build the Guardrails Is Now

There is a tendency in technology to deploy first and govern later. We did it with cloud. We did it with SaaS. We did it with mobile devices. We did it with APIs. We did it with service accounts.

Then security teams spent the next decade discovering everything nobody knew existed.

We cannot afford to repeat that pattern with autonomous AI.

The warning signs are already visible. Palo Alto Networks reported in 2026 that 68 percent of organizations lacked visibility into the AI tools their developers were actually using, while agentic systems increasingly possess the ability to access corporate resources, alter files, and execute commands at machine speed.

MCP is accelerating because it solves a real problem. That is precisely why this matters now.

Trying to retrofit governance after millions of autonomous connections have been deployed throughout the enterprise will be infinitely harder than designing governance into the architecture today.

The protocol will continue improving. Agents will become more capable. MCP servers will multiply. AI-to-AI delegation will increase. Non-human identities will continue expanding. The amount of authority moving without direct human involvement will grow exponentially.

We have a narrow window in which to establish the architecture before the architecture establishes itself.

MCP Provides Connectivity. IAM 3.0 Must Provide Control.

MCP could become the nervous system of enterprise AI. I believe it probably will, or something very much like it will.

That is good news.

Interoperability is necessary if agentic AI is going to deliver the productivity and transformation being promised. But nervous systems without governance are not intelligent organizations. They are uncontrolled reflexes.

The next generation of enterprise identity cannot merely authenticate agents and issue tokens to them. It must understand authority. It must understand delegation. It must understand context. It must govern actions at runtime. It must coordinate policy across technologies that were never designed to work together. It must observe continuously, and when the conditions change, it must be able to change the decision.

That is why I continue to believe IAM 3.0 represents more than the next generation of identity architecture.

It is becoming the control architecture required for autonomous computing.

The real MCP security question is not whether the agent can connect. The question is who authorized the connection, what authority is moving through it, what the agent is attempting to do with that authority, and whether that authority should still exist right now.

If your identity architecture cannot answer those questions in real time, MCP has given your AI connectivity.

It has not given you control.

And in the age of autonomous AI, that distinction may determine the difference between transformation and catastrophe.

MCP provides connectivity. IAM 3.0 must provide control.

The choice is not whether enterprises will connect AI to their infrastructure. That decision is already being made. The choice is whether we govern what happens after the connection is made.

The cost of getting that wrong will not be measured in breaches.

It will be measured in catastrophic failures.