Every identity system you've sold answers one question: is this entity allowed to do this thing, right now, in this context? You know how to make that question legible to a buyer who needs to trust the answer. OAuth scopes, service account provisioning, credential rotation, decommissioning. The whole lifecycle, made governable.
AI agents need the same lifecycle. They don't have it yet.
Why this is in the room now
"Production deployment" for most agentic AI systems in May 2026 means the agent authenticates with whatever was convenient at setup time. A long-lived API key. A developer's personal OAuth token that nobody revoked. A shared service account that three other systems also use. The agent reads data, calls APIs, writes to databases, spawns subtasks. Every one of those actions either passes through an identity layer or it doesn't. Mostly, it doesn't.
Your buyers know this is a problem even if they haven't framed it as an identity problem yet. NIST launched its AI Agent Standards Initiative in February 2026 and immediately stood up an NCCoE project on agent identity and authorization with four focus areas that should sound familiar: identification, authorization, access delegation, and logging. CISA's joint guidance on agentic AI, published this month with allied signals agencies, names privilege creep, obscure event records, and unrestricted access as primary risks. That's CISO vocabulary. When your buyer's CAIO starts talking about agent governance, they're circling the same problem you've been solving for a decade. They just haven't connected it to you.
The AE who can make that connection credibly changes the shape of the deal. You get pulled into the architecture conversation, which is a different room than the one where you renew the SSO contract. The buyer planning an agentic deployment needs someone who understands identity lifecycle at the table while the architecture is being drawn, not after it's been procured.
Where the standards actually stand
The Model Context Protocol is the closest thing to a standard for how agents connect to tools and external services. Its authorization spec has changed materially four times in eighteen months. The original stable release in November 2024 didn't address authentication at all. By March 2025, the spec mentioned OAuth's client credentials grant for machine-to-machine auth. Then it was removed. The June 2025 update classified MCP servers as OAuth Resource Servers and mandated RFC 8707 resource indicators for audience binding. The November 2025 revision demoted Dynamic Client Registration in favor of a mechanism still in draft. Each revision is defensible. The cumulative effect is that "MCP support" on a vendor's feature list tells you almost nothing about which authorization model is actually implemented.
At the protocol layer, the IETF has at least five active drafts attempting to define agent identity. A draft mapping OAuth and workload identity onto agents. An Agentic JWT draft addressing what it calls the "intent-execution separation problem." Remember that term. It names a real gap that will surface throughout this section: traditional OAuth assumes the client faithfully represents user intent, and autonomous agents break that assumption by deciding at runtime which tools to invoke and how. There's also an Agent Identity Protocol, a SCIM extension for agents, and a proposed agent identity registry. None has achieved RFC status. None has multi-vendor adoption. All are valid for six months and subject to replacement. This is what "early" looks like in standards work.
The hyperscalers aren't waiting for consensus. AWS shipped Bedrock AgentCore Identity to GA. Microsoft has Entra Agent ID in preview. Google donated the A2A protocol to the Linux Foundation and built agent orchestration into Vertex AI. Three platforms, three identity models, three credential stores, three audit trail structures. An agency deploying agents across two of these clouds faces exactly the kind of fragmentation that makes an identity vendor relevant.
You know how OAuth scopes constrain what a client can request from an authorization server. MCP's authorization model maps scopes onto tool permissions the same way: the agent gets a scoped token for a specific MCP server. Your intuition works here. It stops working here: OAuth scopes constrain what can be requested, but they don't govern what the agent decides to request. An agent may choose different tools mid-task based on model reasoning and retrieved context. The scope permits the action. Nothing governs whether the action matches what the user actually intended. On a call, the question this opens: "Are you scoping tool access at runtime, or only at provisioning time?"
A service account is a non-human identity with fixed permissions executing predictable code paths. You provision it, scope it, audit it, rotate its credentials, decommission it. Agents need all of that. They also break the model in one specific way: a service account always calls the same endpoint with the same parameters. An agent may call different tools, with different parameters, based on what the model infers from the conversation and prior tool results. So the audit question expands: which identity called which API, yes, and also what reasoning drove the decision to call it. On a call: "Can you distinguish human intent, agent decision, and tool execution in your audit trail?"
What this section covers
The rest of this section works through the landscape that produces these identity questions, sequenced to follow the decisions a buyer makes when building an AI architecture.
Who made the model and who hosts it. The company that trained the model and the company that serves it are often different. The identity surface spans both: whose credentials authenticate the API call, whose audit trail captures the activity, whose governance policies apply to the data in transit.
Open weights and what they actually mean. License terms determine governance obligations. MIT license means none. Meta's Llama license means attribution and scale limits. "Open source" is applied loosely enough to matter for procurement.
Where the model runs. The hosting platform determines where agent identity services live and what they can govern. Bedrock, Azure AI Foundry, and Vertex AI handle this differently, and the differences aren't cosmetic.
What it costs. Agentic loops consume dramatically more tokens than single-call patterns. Cost governance is access governance.
Capability tiers and routing. Frontier models, efficient models, small models. Routing decisions have authorization implications because the router itself is a model making classification decisions.
Where the model was trained. Training origin, hosting location, and runtime telemetry destination are three different questions with three different data governance implications.
Specialty inference providers. Each additional provider API is another credential in the non-human identity inventory.
The authorization question runs underneath all of it. A structural fact about the domain: every architectural choice in this section creates or forecloses identity governance options, and the buyer making those choices right now mostly doesn't have anyone in the room who sees that.
Things to follow up on...
- NIST's NCCoE concept paper proposes adapting OAuth 2.0, OpenID Connect, and SPIFFE/SPIRE to treat AI agents as distinct non-human identities requiring enterprise-grade lifecycle management, with SP 800-53 control overlays for agent scenarios in active development.
- MCP's enterprise visibility gap: Until the November 2025 spec revision, connections between MCP clients and servers bypassed enterprise IdPs entirely, creating shadow IT connections invisible to Okta or any other identity provider.
- NIST red-team results on agents: January 2025 research demonstrated that novel attack strategies against AI agents achieved an 81% success rate compared to 11% against baseline defenses, which is the kind of number that moves a CISO conversation.
- CoSAI's agentic IAM framework: The Coalition for Secure AI published its Workstream 4 paper in March 2026 establishing architectural principles for agent identity and access management that the industry will likely converge around over the next 12–18 months.