Agent Identity: A Ceiling, Not the Policy

Entra ID and Okta already define the identities, groups, roles and access grants that bound what a human, service principal or agent identity may do. An agent acting for that principal must never exceed that ceiling. That is the hard limit. Everything else is about staying inside it while still giving the agent a precise contract for the work in front of it.

Identity is a necessary input. It is not the policy.

How does the employee analogy apply to agents?

The company directory is critical for people. Okta, Entra ID, or Active Directory supplies identity, group membership, roles, and the tokens that make single sign-on work. That part does not go away for agents.

But a directory is not an employee handbook. It is not training. It is not spending authority and approvals. It is not evaluation, coaching, or the approved processes that actually shape how work gets done. Those other inputs exist because the directory alone cannot express them. They constrain, guide, and remediate behavior beyond what roles and groups can say.

Agents need the same layered inputs. The directory can tell you who the principal is and the maximum they may do. It cannot tell you which tools this agent is actually wired to call, which of those calls fit the current objective, what budget applies, which data the tools may touch beyond the role, what evidence the agent must provide, or when the agent should stop and check back. Those details come from elsewhere. Fuse them with identity and you get a policy. Leave them out and you only have a single ceiling.

What does the identity ceiling cover, and what doesn’t it?

A directory is one part of the identity stack. Identity providers (IdPs) such as Entra ID, Okta, Auth0 and Google Workspace authenticate principals and issue the tokens that carry their roles and scopes. Together they answer the question: What is this principal permitted to do in the systems it already knows about? That answer is the limit or ceiling. An agent must not be granted more.

The directory does not know the rest. It does not see the tools declared in the agent’s code. Newer agent identity features, such as Microsoft Entra Agent ID and Okta for AI Agents, can register agents and subagents as identities, but they do not see which subagents the code will actually spawn, or why. It does not see the data scopes those tools require, the spend envelope for this run, the standing organizational rules that are not expressed as groups, or the evidence from the last time a similar agent ran. Those are additional inputs. The policy is the compiled, versioned contract that results when they are fused with the ceiling and bound to a runtime.

Two things follow. First, do not recreate the directory inside your policy system. That creates a second source of truth that will drift from your corporate directory, and drift undermines agent reliability[C1] . Read the entitlements, groups, and roles from Entra or Okta. Treat them as the non-negotiable outer bound. Second, do not stop there. A token that says “this principal may call these APIs” is not the same as a contract that says “this agent, for this objective, with this budget, may call these specific tools and no others, and must stop when X happens.”

What other inputs make up an agent policy?

Agentic policy is the fusion of several inputs. Identity is one of them. Others include:

• The tools and subagents the code actually declares and is prepared to call.
• Tool-level constraints: what a tool is for, what it must never be used for, timeouts, and idempotency.
• Budget and spend rules for the run.
• Data access boundaries that sit inside, not outside, the principal’s entitlements.
• Standing organizational rules that live in handbooks and process docs rather than directory groups.
• Runtime evidence from prior runs: what the agent actually did, where it drifted, what nearly failed.

The directory supplies the identity and the outer rights. The rest of the inputs supply the precision the directory was never asked to hold. Together they produce a contract the harness or sandbox can enforce. Identity alone cannot.

This is also why a clean import path from Okta and Entra matters. The ceiling has to be current and machine-readable. Manual recreation of roles and groups creates exactly the competing source of truth that drifts. Reading the directory and binding to it keeps identity where it belongs.

Do directories still matter for agents?

Directories will keep answering “who is this principal and what is the maximum they may do.” Agent policy takes that answer as a ceiling and adds the layers the directory cannot see. That division of labor keeps the directory from being asked to do a job it was not built for, and it keeps agent policy from becoming a second copy of the directory.

One consequence is worth noting for later. Agents discover and exercise far more of the surface available to them than humans typically do, and they do it continuously 24/7. The directory was not designed as the place where that volume of precise, short-lived contracts is compiled and enforced. Identity stays the ceiling. The policy is what gets built on top of it.

Additional Reading:

The analogy of agents as employees is a good framework for thinking about policy, but agents do have some unique challenges.

Smarter models don’t render agent policy obsolete, they actually make it more important.

Identity is a critical component of Agent Reliability Engineering[C2]  (ARE), the discipline of making your agents reliable so they can earn autonomy.