Agent Identity, Authorization and Spend Control

Agent governance is three problems wearing one name

Ask three people what agent governance means and you get identity, authorization and cost, in some order, usually with the speaker's own job at the top. All three answers are right. They are also three different purchases, from three different vendors, owned by three different teams, and the reason so many agent programmes stall at pilot is that nobody owns the third one.

• Identity. Who is this agent? A principal in the directory with an owner, a lifecycle and a way to prove itself. An IAM problem, owned by the identity team.
• Authorization. What may it reach, and on whose behalf? Scoped, expiring access to applications and tools. A protocol problem, owned by platform engineering.
• Spend control. How much may it consume before something stops it? A hard cap in the request path. A FinOps problem, enforced by whoever owns the gateway.

Nothing on that list is exotic. What is new is that the thing being governed acts on its own schedule, at machine speed, in a loop, and will happily retry a failing call several thousand times before anyone reads a dashboard.

How agents get an identity

Through the identity provider, as first-class principals rather than a shared service account with a token in an environment variable. Microsoft Entra Agent ID issues each agent an identity that Conditional Access, ID Protection and access packages apply to, with a sponsor recorded so there is a human on the hook for its lifecycle. Microsoft is explicit that this is not a service principal with a new label: service principals assume long-term stability and known ownership, while agents get created and destroyed at automation speed, sometimes thousands of times a day, and the identity model has to survive that without leaving orphaned credentials behind.

Amazon Bedrock AgentCore Identity plays the same role on the AWS side, as a standalone service usable by agents running on ECS, EKS, Lambda or on-premises: it brokers the OAuth flow to whatever the agent needs to reach and keeps the resulting tokens in a vault the agent draws from per call, with API keys and client credentials held in Secrets Manager.

The two products differ in plenty of ways and agree on the part that matters. The agent is not where the durable secret lives. Every Entra agent identity is provisioned from an agent identity blueprint, and the credentials that authenticate it are configured on that blueprint and used to request a token from Entra, which is why disabling the blueprint stops every agent created from it from authenticating at all. AgentCore keeps the token in the vault and hands out access per call. Both designs assume the agent will eventually be compromised or talked into something, and both make sure that when it happens there is no long-lived secret inside it to take, and one control that switches the whole family off. Judge any agent identity story against those two properties first.

What it may do, and on whose behalf

Identity establishes who is calling. Authorization is the harder half, because an agent usually acts for a human and needs an access scope that reflects both. The pre-agent answer was an OAuth consent screen and a person clicking approve, which does not survive contact with something that runs unattended at 2am.

Cross App Access is the current answer, and it is a standards effort rather than one vendor's feature. The grant underneath it, the Identity Assertion Authorization Grant, is an IETF OAuth working group draft (draft-ietf-oauth-identity-assertion-authz-grant) that lets the enterprise identity provider mediate the connection between two applications by token exchange instead of a consent screen, carrying context about both the user and the agent, with the whole path logged centrally. Okta describes the result as zero-touch OAuth for MCP, and says the extension has been formally incorporated as an MCP authorization extension. Its own rollout runs through the Okta Integration Network from August 2026, with more than twenty-five launch integrations covering both the requesting side (Claude, Cursor, VS Code) and the resource side (Atlassian, Datadog, Linear, Slack).

The tool side is converging just as fast. The Model Context Protocol specification requires remote MCP servers to behave as OAuth 2.1 resource servers, with PKCE, resource indicators (RFC 8707) so a token cannot be replayed against a different server, and protected resource metadata (RFC 9728) for discovery. The 2026-07-28 release candidate tightened this further, adding issuer validation on authorization responses to close mix-up attacks. If you were waiting for agent authorization to settle before investing, it is settling into ordinary OAuth, which is the best available outcome.

Spend control is the layer everyone skips

A budget alert tells you an agent spent the money. Enforcement stops it spending the next dollar. That is the entire distinction and it decides whether a runaway loop costs you a rounding error or a quarter's inference budget, because an agent that retries a failing tool call does not get bored.

Enforcement only works at a choke point every request already crosses, which is the AI gateway. That is where budgets can be scoped per key, per session, per team, per model and per provider, where hitting a ceiling can downgrade to a cheaper model rather than failing the request, and where the spend telemetry is already being emitted. LiteLLM and Portkey both do this, the latter nesting the controls down its organisation, workspace and key hierarchy, with periodic resets and alert thresholds per workspace. The wider category, including where Helicone sits on the observability line, is in our AI gateways cluster.

Worth being blunt about the sequencing: identity and authorization tend to get funded because security asks for them, and spend control tends to get funded after the first surprise invoice. It is the cheapest of the three to implement and the one most often missing at pilot.

This is not AI governance

AI governance is the organisational layer: policy, risk classification, model approval, documentation, regulatory alignment, the committee that signs off. Agent governance is runtime: this agent, this call, this moment, allowed or not, and paid for out of which budget. An organisation can hold a mature AI governance programme and still run agents on a shared key with no ceiling, because the two are built by different people out of different parts.

If the layer you actually need is the organisational one, start from our AI governance framework guide, which covers policy and structure rather than tokens and scopes. This page stays on the runtime side.

Governance without observability is a policy document

Every control described here produces evidence only if something is recording what the agent did. Scoped credentials with no trace of which tools were called, a budget ceiling with no per-agent attribution, an audit trail that stops at the identity provider and never reaches the model call: each is a control you can describe in a meeting and cannot verify afterwards.

That is where this page rejoins the cluster it belongs to. The tracing and evaluation layer that makes agent behaviour legible is scored in the LLM observability rankings, and the hub explains why observing AI and AI doing the observing keep getting sold as one thing. Governance decides what an agent is allowed to do. Observability is how you find out what it did.

Sources

• Microsoft Learn · Microsoft Entra Agent ID documentation (Primary source)
• AWS · Amazon Bedrock AgentCore general availability (13 October 2025) (Primary source)
• AWS Docs · AgentCore Identity: obtain an OAuth 2.0 access token (Primary source)
• OAuth.net · Cross-App Access (Identity Assertion Authorization Grant) (Standards body)
• Okta · Expanding the Cross App Access ecosystem (Primary source)
• Model Context Protocol · The 2026-07-28 specification release candidate (Primary source)
• Model Context Protocol · Authorization specification (Standards body)
• Microsoft Learn · Agent identity blueprints in Microsoft Entra Agent ID (Primary source)

Last verified 2026-07-29. Product capabilities and availability dates are taken from the vendor's own documentation or announcement in each case; the standards claims are cited to the specification text and to the OAuth working group's own page for Cross App Access.

What is agent governance?

Agent governance is the runtime control layer around an autonomous agent, and it covers three separate questions. Identity: which principal is this agent, who sponsors it, and how does it prove that without holding a permanent secret. Authorization: which applications, tools and data may it reach, on whose behalf, and for how long. Spend control: how many tokens or dollars may it consume before something stops it. Each has its own vendors and its own standards, and enterprises typically assemble the three rather than buy them together.

How do AI agents get an enterprise identity?

Through the identity provider, as first-class principals rather than shared service accounts. Microsoft Entra Agent ID gives each agent an identity in the directory, distinct from a service principal and designed for agents that may be created and destroyed thousands of times a day, with a sponsor recorded, Conditional Access and ID Protection applying to it, and access that can be autonomous or delegated from a specific user. Every agent identity is provisioned from an agent identity blueprint, and the credentials used to authenticate it are configured on that blueprint rather than embedded in the agent, which is also why disabling a blueprint prevents all of its agents from authenticating. Amazon Bedrock AgentCore Identity takes the equivalent approach on the AWS side, brokering OAuth flows and holding the resulting tokens in a vault the agent retrieves from at call time.

What standard governs agent access to applications?

Two efforts matter right now. Cross App Access, built on the Identity Assertion Authorization Grant that is an IETF OAuth working group draft, lets the enterprise identity provider mediate agent-to-application connections by token exchange instead of a user clicking an approval screen, so every connection carries both the human and the agent context and lands in one audit trail. Separately, the Model Context Protocol specification requires remote MCP servers to act as OAuth 2.1 resource servers, with PKCE, resource indicators from RFC 8707 and protected resource metadata from RFC 9728. Between them, agent access is converging on ordinary OAuth machinery rather than a new bespoke protocol.

How do you stop an AI agent from burning the budget?

By enforcing the limit at the point where the request leaves, not by watching a dashboard. Budget alerts are retrospective: they tell you what an agent already spent. Enforcement is a hard cap in the request path that terminates or pauses the agent when a token or cost threshold is crossed, so no further model call is placed until a human or a policy resumes it. In practice that lives in an AI gateway, where budgets can be scoped per key, per session, per team and per model, and where hitting a limit can downgrade the request to a cheaper model instead of failing it outright.

Is agent governance the same as AI governance?

No, and conflating them wastes time in both directions. AI governance is the organisational layer: policy, risk classification, model approval, documentation, regulatory alignment. Agent governance is the runtime layer: identity, authorization and spend enforcement on a specific agent making a specific call at a specific moment. A company can have a mature AI governance programme on paper and still have agents running on a shared API key with no budget ceiling. The two need each other, but they are built by different people out of different parts.