Agents are not configured all at once and left alone. They have been built, deployed, deployed and retired. An identity that doesn’t follow this entire arc is a record you wrote down and forgot about, and that way you end up with credentials that outlast the clients they belong to.
Therefore, treat identity as a life cycle. Provide credentials at a specific gateway, not ad hoc when someone needs one. Cancellation is as easy as creation. If standing up to an agent requires one controlled move and knocking it down requires a ticket and a week, you’ve built a system that pools risk by default.
Gates are the floor, not the ceiling
Provisioning and cancellation gateways are essential. They are not the strong version of this idea. The strong version, which is worth building on in 2026, is the abolition of status privilege.
The agent must not have persistent permissions. Access is granted at the appropriate time, scoped to the task in front of it, and released the moment the task is completed. Between tasks, the access of the primary agent is nil. Permissions appear when work needs them and disappear when the work is done.
This has been the unfulfilled aspiration of human identity for a decade. Timely arrival of people remains at a standstill, because human workflow is chaotic and people resent friction. Agents change the account in both directions.
They make it more urgent. Agents spawn by the thousands. It is fleeting. The perpetual grant multiplied by a fleet of this size, which remains idle most of the time, is the radius of an unsigned explosion.
It also makes it more achievable. An agent can request and release credentials programmatically, in the context of its own execution, in ways that a human workflow never could. Friction that kills timely access as people barely register for programs. What was aspirational for humans is operationally realistic for customers.
There are binding standards for mechanics. Lifecycle operations such as activate, suspend, cancel, and delete are exactly what the OpenID provider commands specify. You don’t have to invent verbs to manage an identity all its life. They are connected to the gateways in your agent platform so that provisioning and deprecation are first-class operations, not manual cleanup.
Close the loop
This is where the whole series falls flat.
This started with a simple observation. The agent is non-deterministic. It can’t know what set of actions it will take when you grant it permissions, because it chooses its toolchain at runtime based on its prompt, its context, and the output of whatever it calls. This single fact is why aliased credentials fail, why the scope must be narrow, why the authorization chain must be scannable, and why authorization must live in the control plane that decides at runtime.
This is also why a mandate cannot be a one-time grant for the design period. You can’t decide in advance what an actor might do when the actor decides what to do by just running it. Delegation must be persistent and evaluated at runtime, against the task actually in front of the agent.
The life cycle is what makes this effective. Just-in-time provisioning is a runtime license expressed by identity: the agent gets exactly the access this task needs, at the moment it needs it, and returns it. Cancellation is the same idea from the other side. Continuous re-evaluation is the life cycle that runs while the agent is running, not a configuration that you set and move away from.
An agent identity that you cannot provision, scope, invalidate, and re-evaluate at runtime, in an explicit lifecycle, is not an identity. It’s a responsibility with a name attached.
What to do next
Choose one agent that is already running in your environment. Answer five questions in order.
Does it have its own identity or does it borrow human identity? Are its permissions specific to its task or are they inherited wholesale? When you invoke another tool or agent, does the authorization chain continue or does it turn into a re-minted token? Is its license determined at runtime by a control plane, or is it hard-coded at deployment time? And can you provision, scope, and invalidate it in a clear lifecycle, or is it a static record that someone wrote once?
Wherever the answer is wrong, you’ve found the next thing to fix. Start with the agent that can do the most damage and work your way up.
