A user tells an agent, “Yes, do that.”
The agent may still need to ask a harder question:
“Do you still mean this exact action, on this exact target, under these current conditions, now?”
That is not pedantry. It is the difference between permission as a vague memory and authority as a bounded decision.
A long-running agent system may pause for an approval, wait for a dependency, discover new information, transfer work, or resume after a process restart. In each case, a confirmation that was sensible at the beginning may no longer cover the action at the end.
Permission says an action class may be possible. An authority lease says which action is justified, for whom, under what conditions, and for how long.
This is a proposed architecture model, not an OAuth extension or a substitute for service-level authorization. It is a way for agent systems to connect a human or policy decision to one bounded execution path.
Why an approval can grow stale
Approvals age in several ways.
- What changes: Target — Example: The task moves from a draft workspace to a production-facing system — Why the original approval may no longer apply: The consequence and audience changed
- What changes: Scope — Example: A plan expands from changing one item to changing a collection — Why the original approval may no longer apply: The approved effect is larger
- What changes: Time — Example: Work resumes after a delay — Why the original approval may no longer apply: The user, policy, or external state may have changed
- What changes: Preconditions — Example: New evidence invalidates an assumption behind the proposed action — Why the original approval may no longer apply: The action may no longer achieve the stated goal
- What changes: Delegation — Example: A different agent or process continues the work — Why the original approval may no longer apply: The actor and execution boundary changed
- What changes: Outcome risk — Example: A read-only step reveals a need for a consequential write — Why the original approval may no longer apply: The next action is not covered by the earlier confirmation
A persistent tool credential cannot resolve this by itself. Credentials answer a system-level question: can this caller authenticate to a resource? An agent still needs to answer a workflow-level question: is this particular effect authorized by the governing user, policy, and task state?
RFC 9700 makes a related security point in a different domain: privileges should be limited to what is needed, and shorter-lived, reduced-scope access can reduce the impact of misuse. The authority-lease model borrows the principle, not the mechanism. It is about making a user or policy decision narrow, expiring, and reviewable.
The five-part authority lease
A lease should be compact enough to inspect and precise enough to invalidate.
- Part: Subject — Question it answers: Who or what is allowed to act? — Example content: Approved agent role, service identity class, or handoff boundary
- Part: Effect scope — Question it answers: Which result is allowed? — Example content: Named target, action category, maximum affected set, excluded targets
- Part: Validity window — Question it answers: When is the decision usable? — Example content: Approval state, expiry condition, and event that makes it stale
- Part: Revocation and renewal — Question it answers: What changes end the authority, and who can renew it? — Example content: Task mutation, user cancellation, policy change, or required re-approval
- Part: Evidence — Question it answers: Why is this effect attributable to valid authority? — Example content: Approval reference, policy version, plan reference, and final verification link
The lease is not a durable right to do anything similar later. It is a record that says, “Under these stated conditions, this bounded effect is permitted.”
This design deliberately separates the term scope into several questions. A broad label such as “edit a document” is too weak on its own. A meaningful scope asks:
- Which document or class of documents?
- What kind of change is allowed?
- What is explicitly excluded?
- Is the action reversible?
- Does it require another confirmation if the agent discovers a new consequence?
- Does the lease cover one effect, a batch, or only preparation for a human decision?
The narrower the answer, the easier it is to keep the system truthful.
A lease lifecycle for agent work
The lifecycle can be simple.
1. Propose
The agent states the intended effect in user-reviewable language. It should name the target class, expected outcome, relevant caveats, and the boundary that will trigger another decision.
A proposal is not authority. It is the information a human or policy needs to grant authority.
2. Issue
A person or governing policy grants the lease against the stated proposal. The system records the relevant policy and decision reference instead of copying private prompts or account data into every log.
The approval should be proportionate. Low-risk, reversible actions may be covered by a narrow policy. Sensitive or consequential actions may require direct user confirmation.
3. Bind
Before execution, the agent binds the lease to current preconditions: the target still matches, the scope has not expanded, the actor is allowed, and no invalidating event is known.
This is the moment a system prevents a delayed action from impersonating an immediate one.
4. Execute
The agent performs only the allowed effect. It should not treat a successful tool call as proof that the action was properly authorized or fully settled. The tool system and the workflow have separate responsibilities.
The MCP tools guidance supports this division of labor: clients should ask for confirmation on sensitive operations, validate results, use timeouts, and retain audit records. Tool metadata is useful, but the authority decision belongs to the governing policy and current task state.
5. Settle, renew, or revoke
Once an effect is verified, the lease is settled. If the task must continue beyond its original conditions, the system issues a new or explicitly renewed lease. If the user cancels, policy changes, or a material precondition fails, the old lease is revoked or becomes unusable.
Do not silently extend an expired authority just because the agent is still working.
Authority is not a budget
Agent systems may use distinct limits for reasoning, tools, elapsed time, and human attention. An authority lease addresses a different question.
- Question: What is bounded? — Budget policy: Resource consumption — Authority lease: Legitimate effect
- Question: Main trigger — Budget policy: A resource threshold — Authority lease: A change in scope, time, actor, or precondition
- Question: Typical response — Budget policy: Adapt, request more effort, stop, or hand off — Authority lease: Reconfirm, renew, narrow, or revoke
- Question: Can a user grant more? — Budget policy: Yes, as a resource decision — Authority lease: Only for a named effect under defined conditions
- Question: Does more of it imply more privilege? — Budget policy: No — Authority lease: No
Conflating the two is a common failure. A team gives an agent a larger token or timeout budget, then assumes it may also do more. More time may help the agent find evidence; it does not give it a broader right to act.
Five anti-patterns
Treating a capability as a perpetual approval
A tool may be available to an agent, yet its use can still need a fresh decision. Availability is not consent.
Reusing an approval after a material plan change
If the goal, target, or effect changed, the agent should not use an old confirmation as a blank check. Re-propose the new effect in the language that a person can assess.
Giving delegation no boundary
A handoff can preserve work, but it should not silently extend authority to a new role, environment, or time window. The successor should bind or renew the lease before acting.
Hiding renewal in an automatic retry
A retry may be technically legitimate and still require re-evaluation if the external state is uncertain or the time window has passed. Treat the result of the prior attempt as evidence, not as automatic authorization for the next one.
Recording raw approvals everywhere
Approval evidence needs retention discipline. Store a stable reference, concise reviewed summary, policy version, and outcome—rather than duplicating private messages, credentials, or sensitive targets into every trace.
How to evaluate authority-lease quality
Measure whether the lease makes consequential action more legible:
- Scope precision: Can an independent reviewer tell what effect was allowed and excluded?
- Stale-approval prevention: How often did a material task change trigger a reconfirmation rather than reuse?
- Renewal clarity: Can the system distinguish an original approval from a later extension?
- Revocation latency: When a user or policy stops a task, how quickly do pending effects become unusable?
- Audit sufficiency: Can a reviewer connect a meaningful effect to a policy or approval reference without reading private content?
- False-block rate: Are harmless, reversible workflows over-escalated because their policy is too coarse?
The last measure matters. A lease system should make legitimate work smoother, not turn every low-risk operation into bureaucratic friction.
A practical adoption path
- Pick one effectful agent workflow, not the whole platform.
- Define its action vocabulary and distinguish preparation from external effect.
- Write the subject, effect scope, validity window, revocation rules, and evidence fields.
- Decide which material changes invalidate an existing lease.
- Require the executor to bind the lease immediately before the effect.
- Make renewal explicit and user-reviewable.
- Audit several completed, cancelled, and delayed runs to see whether the record explains authority truthfully.
Start with the effect that would be hardest to explain after the fact. That is where a bounded authority record is most valuable.
What we are learning building Virillio Code
Virillio Code remains in development. Its work on sessions, tools, permissions, and execution boundaries reinforces a transferable lesson: one platform capability does not answer every question about user intent. Trustworthy agents keep capability, consent, and the current execution attempt separate enough that an old decision cannot quietly become a new authority.
Sources and further reading
- RFC 9700: Best Current Practice for OAuth 2.0 Security — Minimum privilege and resource or action restriction reduce potential impact in the OAuth security domain; used as a high-level authority-boundary principle, not implementation guidance.
- RFC 9700: Refresh Token Protection — Short-lived and reduced-scope access tokens reduce the impact of leaked access in the OAuth security domain; used as a high-level analogy, not implementation guidance.
- Tools — Model Context Protocol — Clients should confirm sensitive operations, validate results, set timeouts, and log tool usage, while annotations remain untrusted unless from trusted servers.
Editorial disclosure
This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.