Count the Standing Grants Before You Shorten Them

The identity industry has settled on an answer to agent permissions. Zero standing privileges, credentials issued at the moment of need, scoped to the task, expiring when it completes. The reasoning is sound and the architecture is coherent.

‍

Almost nobody has deployed it for non-human principals. So the useful question is not whether just-in-time authorization is correct, it is what to do about the standing grants an organization already has while that architecture remains a roadmap item.

‍

Why Is Duration the Harder Half of the Problem?

‍

Scope is negotiated once and duration compounds. A grant that persists between tasks means every future compromise of that agent inherits the same reach as the first, whatever the task at the time required.

‍

An agent given read access to a customer database for a reconciliation job holds that access on the eleven months of the year it is not reconciling anything. The scope was appropriate to the task and the duration was appropriate to nothing, because nobody specified one. Permissions are requested per task and granted per lifetime, and the difference between those two is where the exposure accumulates.

‍

How Does That Change the Blast Radius?

‍

The radius becomes a property of history rather than of the current task. An agent that has performed six different jobs over a year holds the union of what all six needed, so the consequence of a compromise is determined by everything it was ever asked to do. Reading the current task description understates the exposure by however much has accumulated behind it.

‍

Why Hasn't Just-in-Time Been Deployed for Agents?

‍

Three obstacles, and none is a matter of will.

‍

The requester writes its own justification. A human asking for access states a business reason an authorization engine can weigh against a role. An agent mid-task produces a request whose reasoning was generated by the same process seeking the access, so the engine is evaluating a case written by the applicant. The problem differs from evaluating a human request and the identity literature largely assumes it away.

‍

The User-Bound Cap Stops Binding in a Chain

‍

The standard control says an agent may never exceed the rights of the human driving it, which works cleanly at one hop. Where an agent invokes another agent, the second one's principal is the first, and two hops out there is no human for the cap to reference. Chains of agents break the assumption the control rests on.

‍

Short-Lived Credentials Fit Short Tasks

‍

An ephemeral token suits a task measured in seconds. A task running for hours either renews the credential repeatedly, which is standing access with additional machinery, or fails partway. Much of the available guidance implicitly assumes brief interactions, and long-running autonomous work is exactly the category organizations are deploying.

‍

What Matters More Than Duration?

‍

Whether the grant is observable and whether revocation has been tested. A standing grant somebody can see and withdraw in minutes is a better position than an ephemeral system nobody has exercised.

‍

The ranking inverts, and it follows from what happens during an incident. The question is never how long the credential was designed to last. It is whether anyone can enumerate what the agent holds and remove it now, with a measured time rather than a described capability. Programs pursuing a JIT roadmap while unable to answer either question have optimized the wrong variable.

‍

Which Suggests a Different First Step

‍

Enumerate before you shorten. A list of which agents hold which grants, under whose authority, since when, is achievable with current tooling and is the input every later control requires. Nothing about just-in-time authorization is possible without it, and quite a lot is possible with it alone.

‍

Can Scope Substitute for Duration?

‍

They trade off, which is the most useful practical point available and rarely stated. Where a grant cannot be shortened, it can be narrowed, and the exposure calculation responds to either.

‍

An agent holding read access to one table indefinitely is a smaller exposure than one holding read-write across a schema for an hour, depending on the table. Most programs achieve neither, because the scope conversation ended at deployment and the duration conversation is waiting on an architecture nobody has funded.

‍

Where Narrowing Is Easiest

‍

Write access is the first thing to remove, since a large share of agent tasks need to read and report rather than change anything. Separating the read path from the write path, and requiring confirmation on the write, addresses much of the consequence without touching duration at all. Irreversible actions deserve the same treatment, and classifying actions by reversibility is the exercise that identifies them.

‍

What Should End a Grant?

‍

Three events, and watching for them approximates much of what just-in-time authorization would deliver.

‍

• Purpose Completion: The project concluded, the pilot ended, or the workflow was replaced, and the grant persists because nobody linked the two.
• Sponsor Departure: The person who authorized the agent left or changed role, and the authorization outlived their relationship with the organization.
• Replacement: A newer agent took over the function while the previous one kept its credentials.

‍

All three are knowable from systems already running, principally the directory and whatever tracks project status. None fires automatically in most environments, which makes the absence a configuration decision rather than a technical limit, and retiring an agent properly is what should follow when one does.

‍

How Do You Price the Difference?

‍

Treat duration as a multiplier on the exposure rather than as a separate concern. The window during which a grant is live is the window during which any compromise of that agent produces its full reach.

‍

An agent needing access for two hours a month and holding it continuously carries roughly three hundred and sixty times the exposure window the task requires. The figure is crude and it is the kind of arithmetic that moves a conversation, because it converts an architectural preference into a number somebody can weigh against the cost of implementing narrower access.

‍

Which Agents Deserve the Effort First?

‍

The ones where reach multiplied by window is largest, which rarely matches the ones drawing the most attention. An agent with narrow access held permanently may rank below one with broad access held for a week, and ranking them requires the enumeration described above. AI risk quantification turns that ordering into a figure rather than an intuition.

‍

Where Does the Enumeration Come From?

‍

Not from a single system, which is why the enumeration is the step most programs skip. No one source holds which agent has which grant under whose authority.

‍

The identity provider knows what was issued to a service principal and frequently cannot name the human behind it. The target systems know what was accessed and nothing about the chain that produced the request. The agent platform knows what it invoked and is written by the party being observed. An AI Interaction Data Fabric assembles the grant record by joining those, since the useful fact sits in the overlap rather than in any one of them.

‍

What Does the Joined Record Have to Contain?

‍

Five fields, and the third is the one that breaks. The agent identifier. The grant and its scope. The human authority it descends from. The date it was issued. Finally, whether it has been exercised recently, since a grant nobody has used in six months is the cheapest thing on the list to remove.

‍

Why Does the Third Field Break?

‍

Because delegation chains lose the human. Where an agent acts under a service account created by someone who has since left, or under another agent's authority, the trace to a person is broken and cannot be reconstructed after the fact. Recording it at issuance is the only reliable route, which makes it a design requirement rather than a reporting one, and identity at population scale is where that gets established.

‍

What Can Be Done This Quarter?

‍

Four steps, in order, and none waits on a new architecture.

‍

Enumerate the grants, recording which agent holds what, under whose authority, and since when. Remove write access wherever read access satisfies the task, which is the cheapest reduction available. Measure revocation on one live agent and record the elapsed time, since a capability nobody has exercised is an intention. An AI data fabric supplies the list that makes the test possible on more than one agent at a time. Then wire the three termination events to something that notices them, because a grant nobody ends will not end.

‍

Where Does That Leave Just-in-Time?

‍

Worth building toward and not worth waiting for. Every step above is a prerequisite for it rather than an alternative, so a program doing the enumeration and the narrowing arrives at a JIT implementation with the inputs it needs. A program waiting for the architecture arrives with standing grants nobody has counted.

‍

Count Them Before You Shorten Them

‍

Standing authorization is the real agent permissions problem and just-in-time access is the right answer to it, held back by three obstacles nobody has solved. The requester writes its own justification, the user-bound cap stops binding once agents invoke each other, and short-lived credentials suit short tasks rather than long autonomous ones. In the meantime, whether a grant is enumerable and whether revocation has been timed matter more than how long it was designed to last, and narrowing scope substitutes for shortening duration when the second is unavailable. Kovrr's AI Security and Governance Platform records which agents hold which authority and under whose identity, which is the enumeration every later control depends on.

‍

To see which agents in your environment hold standing access and under whose authority, book a demo mapped to your own estate.