Agent permissions should expire like leases, not persist like roles

I think agent permissions should expire like leases, not persist like roles. A role describes what a person or service is generally trusted to do; an agent lease should describe what this task may do, for whom, against which resources, and until when. The distinction matters because an agent can keep acting after the moment that justified its access has passed. Standing authority turns yesterday’s legitimate task into today’s ambient attack surface. Expiry makes loss of authority the normal outcome, not an exceptional cleanup operation.

A useful lease begins with a task identity and a narrowly stated capability set. A coding task might receive read access to one repository, write access to one branch, and permission to run a named test command. It should not inherit every tool exposed to the agent, every filesystem path visible to its host, or the full privilege of its human principal. This is per-task capability restriction: each task starts with a fresh minimum grant, and completion, failure, or cancellation returns that grant to nothing.

Time is part of scope, not metadata attached after authorization. I would set the lease duration from the expected work window and require a delegating supervisor to approve any extension. Different workers in the same workflow can therefore have different expiries. A short fraud check need not retain the longer access held by a claims coordinator. If either worker is hijacked, the compromise may persist, but its usable authority ends when the task lease does. That bounds exposure without depending on perfect detection or prompt obedience.

Delegation should narrow the lease at every hop. When an orchestrator hands work to a sub-agent, the child may receive equal or smaller scope and a duration no longer than the parent’s remaining lease; it must never acquire broader authority merely because it sits downstream from a powerful coordinator. Binding the grant to the principal, task ID, target resources, permitted effects, and expiry creates an authorization chain that can contract naturally as work is decomposed. A terminal task state should revoke its branch of that chain automatically.

The lease still needs enforcement at every action. A permission resolver can combine hard policy, operation risk, execution mode, contextual rules, and pre-tool hooks, with an explicit denial stopping the request. For stronger boundaries, the same grant should constrain the sandbox, filesystem namespace, network routes, credentials, and operating-system controls rather than exist only as prose in a prompt. Runtime policy may add task-specific restrictions, but an append-only authority hierarchy must prevent an agent-authored rule from weakening constraints established before the agent began.

This design changes approvals from repetitive consent into scoped issuance. A human can approve one bounded lease for a coherent task instead of answering a generic prompt before every harmless read or granting a durable role to avoid interruption. Unexpected actions still fail closed, and the denial should tell the agent which boundary it crossed so it can re-plan safely rather than hammer an opaque error. Renewal then becomes a visible control event: what changed, why the prior scope was insufficient, who extended it, and for how long.

One boundary to this claim is that fixed expiry alone is too rigid for long-running tasks whose duration cannot be predicted accurately. Those jobs need renewable leases, but renewal should be explicit, scope-preserving or scope-narrowing, and recorded against the same delegation chain; it should not silently convert temporary authority into a permanent role. A renewable lease preserves operational continuity without erasing the moment when the system must reconsider whether the original justification still holds.

I would audit permissions as a sequence of lease events: issued, used, narrowed, denied, renewed, and expired. That record answers who authorized an action, which agent exercised it, on whose behalf, under what task context, and with what remaining authority. More importantly, the architecture fails toward zero privilege. Prompt injection, poisoned tools, stale sessions, and forgotten credentials cannot be made harmless, but their reach can be limited in scope and time. Roles make access sticky; leases make continued authority earn its justification again.