← All posts

The Agentic Identity Control Plane · Part 2

The AI control plane moves from protocol to principal

By Mike Carroll ·
The AI control plane moves from protocol to principal

The layer you were going to govern your AI agents at is disappearing. Plan accordingly.

In Part 1 I argued your AI agents are non-human identities, and you should run them through the same lifecycle as any service account. That is the discipline. The question is where it lives, because the obvious place to put it is moving out from under us.

Start with the protocol

The Model Context Protocol is the connective tissue between agents and tools, and its next spec goes stateless: no initialize handshake, no session to anchor authorization to. Any request can land on any server instance with no remembered context, so the spec itself recommends moving authorization to per-call enforcement. The convenient chokepoint is going away by design.

(One precision worth keeping: the per-call security guidance in the relevant proposal is non-normative. The spec recommends, it does not require.)

Now the other end

Base models are absorbing capability that used to need a tool integration. Google is explicit about it: built-in tools like Search and Code Execution run on Google’s infrastructure with Google’s credentials, while function calling runs on yours. So some capability leaves your control plane entirely. The gap is bounded today. Provider-native connectors into enterprise SaaS are the trend that turns it into a real one.

Squeeze from both ends and the conclusion is the same. The control plane for AI does not live in the protocol anymore. It moves to the principal: the identity, the credentials it carries, and the purpose of its actions.

Two of those three already have standards momentum

Human-to-agent delegation is becoming an IdP feature, not a custom build. OAuth token exchange (RFC 8693) defines the delegation primitive and its act claim, and the IETF’s Cross-App Access draft lets your IdP broker app-to-app access for a user. Its Appendix A.4 covers AI agents explicitly. This is going to be a toggle you flip.

Here is the nuance the toggle hides. Brokering at issuance gives you visibility, but it still hands the agent an access token to the downstream API. Issuance-time brokering is necessary, not sufficient. The control that holds up is just-in-time, per-call, scoped, short-lived authorization enforced in front of the sensitive resource.

The third piece nobody has standardized

Delegation carries who acted and who brokered it. Nothing carries why. OWASP’s 2026 agentic top ten names the attribution gap under ASI03. NIST’s AI Risk Management Framework and ISO/IEC 42001 demand traceability that today’s plumbing does not deliver. Declared purpose is not yet a signed, auditable claim. It should be.

The shape of the answer

Govern the identity. Enforce at the resource, per call. Audit the intent. The protocol was never going to be the place this lived.

When your agents start acting on behalf of your people next quarter, which of these three do you already have?

Sources

AI x IdentityMCPNHIIGAAI agents