Identity as a lifecycle, not a setting
Agents are not configured once and left alone. They get built, published, deployed, and retired. An identity that does not track that whole arc is a record you wrote and forgot, which is how you end up with credentials outliving the agents they belonged to.
So treat identity as a lifecycle. Credentials provision at a defined gate, not ad hoc whenever someone needs one. Revocation is as easy as creation. If standing up an agent takes one controlled step and tearing it down takes a ticket and a week, you have built a system that accumulates risk by default.
Figure 1. Identity tracks the agent from build to retirement. Credentials are granted just-in-time, scoped to the task, and released on completion, instead of held as standing privilege.
Gates are the floor, not the ceiling
Provisioning and revocation gates are necessary. They are not the strong version of this idea. The strong version, and the one worth building toward in 2026, is to eliminate standing privilege.
An agent should not hold persistent permissions. Access is granted just-in-time, scoped to the task in front of it, and released the moment the task completes. Between tasks, the agent’s baseline access is nothing. Permissions appear when there is work that needs them and disappear when the work is done.
This has been the unrealized aspiration for human identity for a decade. Just-in-time access for people keeps stalling, because human workflows are messy and people resent friction. Agents change the calculation in both directions.
They make it more urgent. Agents spawn by the thousands. They are ephemeral. A standing grant multiplied across a fleet that size, sitting idle most of the time, is a blast radius no one signed off on.
They also make it more achievable. An agent can request a credential and release it programmatically, in the flow of its own execution, in ways a human workflow never could. The friction that kills just-in-time access for people barely registers for software. What was aspirational for humans is operationally realistic for agents.
There is a standards hook for the mechanics. Lifecycle operations like activate, suspend, revoke, and delete are exactly what OpenID Provider Commands defines. You do not have to invent the verbs for managing an identity across its life. The work is wiring them to the gates in your agent platform so that provisioning and revocation are first-class operations, not manual cleanup.
Figure 2. Lifecycle operations (activate, suspend, revoke, delete) map to the gates in the agent platform, so provisioning and revocation are first-class operations rather than manual cleanup.
Close the loop
Here is where the whole series lands.
This started with a simple observation. An agent is non-deterministic. The set of actions it will take is not knowable when you grant its permissions, because it picks its tool chain at runtime based on its prompt, its context, and the output of whatever called it. That single fact is why borrowed credentials fail, why scope has to be narrow, why the delegation chain has to be inspectable, and why authorization has to live in a control plane that decides at runtime.
It is also why authorization cannot be a one-time, design-time grant. You cannot decide in advance what an actor may do when the actor decides what to do only once it is running. Authorization has to be continuous and evaluated at runtime, against the task actually in front of the agent.
The lifecycle is what makes that operational. Just-in-time provisioning is runtime authorization expressed as identity: the agent gets exactly the access this task needs, at the moment it needs it, and gives it back. Revocation is the same idea from the other side. Continuous re-evaluation is the lifecycle running while the agent runs, not a config you set and walk away from.
An agent identity you cannot provision, scope, revoke, and re-evaluate at runtime, on a clear lifecycle, is not an identity. It is a liability with a name attached.
What to do next
Pick one agent already running in your environment. Walk it through five questions, in order.
Does it have its own identity, or is it borrowing a human’s? Are its permissions scoped to its task, or inherited wholesale? When it calls a tool or another agent, does the delegation chain survive, or does it flatten into a re-minted token? Does its authorization get decided at runtime by a control plane, or hardcoded at deploy time? And can you provision, scope, and revoke it on a clear lifecycle, or is it a static record someone wrote once?
Wherever the answer is the wrong one, you have found the next thing to fix. Start with the agent that can do the most damage, and work down.
The post Identity as a lifecycle, not a setting appeared first on DataRobot.