Brokers should not configured as soon as and left alone. They get constructed, revealed, deployed, and retired. An id that doesn’t monitor that complete arc is a report you wrote and forgot, which is how you find yourself with credentials outliving the brokers they belonged to.
So deal with id as a lifecycle. Credentials provision at an outlined gate, not advert hoc each time somebody wants one. Revocation is as simple as creation. If standing up an agent takes one managed step and tearing it down takes a ticket and per week, you might have constructed a system that accumulates threat by default.
Gates are the ground, not the ceiling
Provisioning and revocation gates are needed. They don’t seem to be the sturdy model of this concept. The sturdy model, and the one value constructing towards in 2026, is to remove standing privilege.
An agent shouldn’t maintain persistent permissions. Entry is granted just-in-time, scoped to the duty in entrance of it, and launched the second the duty completes. Between duties, the agent’s baseline entry is nothing. Permissions seem when there’s work that wants them and disappear when the work is finished.
This has been the unrealized aspiration for human id for a decade. Simply-in-time entry for individuals retains stalling, as a result of human workflows are messy and other people resent friction. Brokers change the calculation in each instructions.
They make it extra pressing. Brokers spawn by the 1000’s. They’re ephemeral. A standing grant multiplied throughout a fleet that measurement, sitting idle more often than not, is a blast radius nobody signed off on.
Additionally they make it extra achievable. An agent can request a credential and launch it programmatically, within the stream of its personal execution, in methods a human workflow by no means might. The friction that kills just-in-time entry for individuals barely registers for software program. What was aspirational for people is operationally sensible for brokers.
There’s a requirements hook for the mechanics. Lifecycle operations like activate, droop, revoke, and delete are precisely what OpenID Supplier Instructions defines. You shouldn’t have to invent the verbs for managing an id throughout its life. The work is wiring them to the gates in your agent platform in order that provisioning and revocation are first-class operations, not guide cleanup.
Shut the loop
Right here is the place the entire sequence lands.
This began with a easy commentary. An agent is non-deterministic. The set of actions it’s going to take just isn’t knowable once you grant its permissions, as a result of it picks its device chain at runtime based mostly on its immediate, its context, and the output of no matter referred to as it. That single reality is why borrowed credentials fail, why scope must be slim, why the delegation chain must be inspectable, and why authorization has to dwell in a management airplane that decides at runtime.
Additionally it is why authorization can’t be a one-time, design-time grant. You can’t resolve upfront what an actor could do when the actor decides what to do solely as soon as it’s working. Authorization must be steady and evaluated at runtime, towards the duty really in entrance of the agent.
The lifecycle is what makes that operational. Simply-in-time provisioning is runtime authorization expressed as id: the agent will get precisely the entry this activity wants, in the meanwhile it wants it, and offers it again. Revocation is identical concept from the opposite aspect. Steady re-evaluation is the lifecycle working whereas the agent runs, not a config you set and stroll away from.
An agent id you can’t provision, scope, revoke, and re-evaluate at runtime, on a transparent lifecycle, just isn’t an id. It’s a legal responsibility with a reputation connected.
What to do subsequent
Decide one agent already working in your atmosphere. Stroll it by means of 5 questions, so as.
Does it have its personal id, or is it borrowing a human’s? Are its permissions scoped to its activity, or inherited wholesale? When it calls a device or one other agent, does the delegation chain survive, or does it flatten right into a re-minted token? Does its authorization get determined at runtime by a management airplane, or hardcoded at deploy time? And might you provision, scope, and revoke it on a transparent lifecycle, or is it a static report somebody wrote as soon as?
Wherever the reply is the flawed one, you might have discovered the subsequent factor to repair. Begin with the agent that may do essentially the most harm, and work down.
