We are getting good at handing AI agents work. We are slower at asking whether they should still have that access five minutes later.

That gap is turning into an identity problem. Old authorization assumes a fairly stable actor. A person signs in. A service gets a token. A role is checked. The request is allowed or it is not.

Agents do not sit still. They can run for a long time, call tools, hit APIs, pass work to sub-agents, change the plan, and keep going after the human who started the job has left the thread. If you only decide access at the start, the decision can go stale while the agent is still live.

Access for agents is not a one-time yes. It has to be a loop you keep running.

Where old IAM assumptions fall over

Most identity systems were built for people, apps, and fairly boring machine identities. A user sits in a department. A service account has a job. A role maps to a known pile of entitlements. Someone reviews that pile every so often.

Agents punch several of those assumptions at once.

An agent can start on a fair goal, say summarizing a customer issue, then decide it needs a database, a file, a support tool, and another agent for a specialist step. Each hop can be legal on its own. The risk is the chain.

"Can this identity call this API?" is the old question. The better one is whether this action is still consistent with the task you authorized. That is harder because identity, intent, context, delegation, and what the agent is doing right now all show up in the same decision.

A token is not a hall pass for the whole session

A lot of software authenticates once, issues a token, and trusts it until expiry or revocation. That works when the token still matches a known identity and a known authorization context.

With agents, the token can outlive the story that justified it.

Say the agent may read a set of documents because a user asked for a report. Mid-workflow, it gets new context from a tool, changes path, and starts poking resources that only loosely relate to the report. The token looks the same. The behavior does not.

That is why I care more about runtime authorization than "the session is still valid." Keep asking: is this action still inside policy, has the risk moved, does this still match the original intent?

The missing signal is intent drift

Security stacks already eat risk signals. Odd login. Impossible travel. Dead device. Revoked account. Agent systems need the same kind of signal for behavior.

I call it intent drift: the observable path peeling away from the purpose under which access was granted.

Unexpected is not the same as hostile. Agents are supposed to adapt. You are not trying to punish variation. You are trying to notice when the path has moved far enough that the original yes should not be trusted without another look.

A useful runtime picture holds several things next to each other: the objective the user stated, the plan the agent is on now, the tools it is calling, the data it wants, how deep the delegation has gone, recent security signals, and how sensitive the target is. The more those drift apart, the stronger the case for a fresh decision.

Here is the question people skip. What if the channel that would revoke or update that decision is down?

For a long-running agent, this is not academic. If it keeps working for hours while revocation and risk updates cannot get through, a default-allow posture turns an outage into a bypass.

For high-risk actions, I want fail-closed. If the agent cannot confirm its authorization is still valid, it should stop, shrink what it can do, or ask for a new approval. It should not wander on forever.

You already see that idea in work on continuous access evaluation for autonomous systems. Agents will not politely re-login the way a person does. If revoke is supposed to mean something, the runtime has to receive it and honor it.

Delegation makes this messier

Now add sub-agents.

Agent A is allowed to do a task and hands part of it to Agent B. Should B inherit all of A's power? Probably not. Inherit none of it? Also a non-starter. The saner pattern is constrained delegation: authority moves down with explicit edges.

Those edges should answer the dull questions. What can the sub-agent do, on which resources, for how long, under whose authority, and can it delegate again? The chain should be something you can inspect and enforce, not a comment in a ticket.

This is where classic role-based access control starts to feel blunt. Roles still help. They need context, policy, purpose, and runtime signals sitting next to them. The unit of decision is shifting from "what role is this?" to "is this action justified right now?"

Writing the policy is only half of it

People are excited about using large language models to turn messy natural-language security requirements into policy a machine can execute. I have worked on that. It is useful. Requirements are sloppy. Policy languages are not. Structured generation can shrink the gap.

A clean generated policy still does nothing if the runtime never notices the agent has wandered. Generation answers what should be allowed. Runtime governance answers whether the system is still inside that fence. Agent security that is worth shipping needs both.

Same story as the rest of software security. Writing safer code is not the finish. You still need runtime controls, observability, incident response, and a way to pull trust when the conditions change.

Standards beat a pile of product quirks

Contributing to identity and AI security standards taught me this the slow way. These problems are too basic to solve as one vendor's feature.

If every shop invents its own agent identity, delegation, risk signals, and authorization responses, enterprises get a pile that does not compose. The agent speaks one model. The tool expects another. The security platform emits a risk signal neither side knows how to eat.

Shared specs are how the industry agrees on the boring parts. What does an authorization request look like? How do you tell a policy denial from an internal error? How does a risk update get from the security plane to the agent runtime, and what is the agent required to do when it arrives?

If those answers stay proprietary, revoke will keep meaning whatever the last vendor decided it meant. That is not an access model. That is a hope.

What I would put in an agent authorization layer

If I were designing an authorization layer for enterprise agents today, I would start with five ideas.

First, evaluate every agent action with context, not identity alone. The request should carry the user, the agent, the task, the target resource, the tool, the delegation path, and the risk signals that apply.

Second, keep permissions narrow and short-lived. Give the agent the least authority the current task needs, on grants that expire quickly and are easy to pull.

Third, make delegation explicit. A sub-agent should not quietly inherit broad upstream power. Record who delegated what, under which constraints, and whether it may delegate again.

Fourth, re-evaluate while the work is running. A real shift in tools, data sensitivity, behavior, or risk should force a new decision. Do not lean on the original grant as if the world froze.

Fifth, treat revocation as a runtime feature. If a risk event says access is dead, the agent has to stop using it now. If the runtime cannot receive or verify that state for a high-risk action, fail closed.

Govern the autonomy. Do not smother it.

Security people can make any new technology sound like a list of reasons not to ship. That is not the argument I want.

The interesting part of agentic AI is that it can act. It can move across tools instead of waiting for a person to click every step. If the response is a human approval before every action, you have killed the product.

Make the autonomy governable. Let the agent move fast inside clear fences. Re-check access when the context changes. Shrink or revoke capability when risk goes up. Keep a record of why an action was allowed. Make delegation visible. Give security a way to step in without rebuilding the workflow from zero.

That is how I think identity evolves for AI agents. Not a bigger login screen. Not another static role matrix. A control plane that keeps asking, while the agent is still running, whether this system should still be trusted to do what it is doing.

The first wave of enterprise AI asked whether models could answer. This wave asks whether agents can act. Once software can act on its own, authorization cannot stay frozen at the token you issued at the start.