Give Agent Tool Permissions an Expiration Date

An AI agent should not keep a permission after the task that justified it has ended.

Short answer: An agent tool permission lease is a temporary, task-bound grant. It names the agent, owner, task, tool, operation, resource, allowed arguments, expiry, closure condition, renewal rule, revocation path, and audit destination. The model can request a lease. A wrapper, gateway, policy engine, or reference monitor must enforce it.

Most agent permission reviews answer one question: what can this agent do?

That is incomplete.

The review also needs to ask when the permission expires, what closes it early, who can renew it, and what happens when the agent tries to reuse stale authority.

Think of the permission as a lease.

A coding agent may need write access to one directory while it updates a feature. A browser agent may need access to one domain while it completes a registration task. A research agent may need a private source for one approved query.

None of those grants should silently become standing access.

Static permission does not match dynamic work

AgentSentry starts from this mismatch. Its abstract says AI agents that rely on over-privileged static permissions are exposed to instruction injection. The proposed control is task-centric access control: generate minimal temporary policies for the user's current task, mediate actions at runtime, and revoke the policy when the task completes.

The case study is narrow. The control pattern is useful.

Permission belongs to the task, not to the agent forever.

That matters because a normal run can move through different trust states. The agent may be allowed to read a verification email for account setup. That does not mean it should be allowed to forward email, read unrelated mail, or keep email access for every later step.

The model should not control its own lease

Prompt rules are not an enforcement boundary. A model can misunderstand them. Untrusted tool output can redirect the model. A later planning step can treat old authority as if it still applies.

Progent puts deterministic policy between the agent and its tools. Its abstract says privilege is represented as symbolic rules over tool names and arguments. Every tool call is checked against policy through a deterministic procedure. Proposed policy changes are classified as narrowing or expansion. Narrowing can apply automatically. Expansion requires explicit approval.

That is the right shape for permission leases.

The agent can ask for more authority. It should not quietly grant, widen, refresh, or renew that authority for itself.

This is also where a lease complements a tool permission manifest. A manifest says what the agent could be allowed to do. A lease says which temporary slice of that authority is active right now.

Expiry is not enough

A timestamp limits how long a permission exists. It does not prove that the permission remains necessary for that whole period.

The Lingering Authority preprint focuses on this gap in coding agents. It defines lingering authority as a temporary resource or effect capability that remains exposed after the episode that justified it has closed.

Its PORTICO prototype uses request, grant, invoke, and closure stages. Temporary capability handles are tied to an epoch. When the subgoal closes, the handles disappear from the planner's next interface and stale replay gets rejected before a side effect.

The evaluation is small, so treat it as early evidence. The useful idea is not the exact number. It is that task state can revoke permission before the clock runs out.

A good lease needs both:

• An absolute expiry
• A closure condition tied to the work

Whichever happens first should end the authority.

Write the lease record

Authenticated Delegation and Authorized AI Agents proposes delegation records that connect a human user, an agent identity, a goal, scope limits, validity conditions, revocation endpoints, and audit metadata.

That is a strong starting point for a practical tool permission lease.

For each temporary grant, record:

1. The agent identity and human owner
2. The task ID and subgoal that justify access
3. The tool, operation, resource, and allowed arguments
4. The issue time and absolute expiry
5. The event that closes access early
6. Who may renew the lease
7. Which changes count as permission expansion
8. The credential audience
9. The revocation path
10. Where grants, denials, renewals, expiry, and stale reuse attempts are logged

Then enforce that record in a tool wrapper, policy engine, gateway, or reference monitor outside the model.

The agent may ask for a renewal. The request should name the unfinished subgoal, the evidence that work remains, the exact authority needed, and the requested duration. A human or deterministic policy decides whether to issue a new lease.

No silent refresh.

Borrow the security primitives that already work

Agent permission leases are a new application of older security ideas.

OWASP's AI Agent Security Cheat Sheet recommends least privilege, per-tool permission scoping, explicit tool authorization for sensitive operations, human review for high-impact actions, audit trails, and adversarial testing.

NIST SP 800-207 says zero trust assumes no implicit trust and performs authentication and authorization before a session to a protected resource is established. OAuth Security Best Current Practice covers OAuth in more dynamic setups and gives updated security recommendations for modern deployments. MCP security guidance warns against broad scopes and recommends progressive least-privilege scope models.

AWS IAM recommends temporary credentials for roles and federated principals. Those credentials expire after a defined period and cannot be reused after expiry.

These systems do not solve agent authorization by themselves. They give builders proven parts:

• Short-lived credentials
• Narrow scope
• Restricted audience
• External enforcement
• Controlled renewal
• Revocation
• Audit logs

The agent layer should use those parts instead of replacing them with natural-language promises.

Test stale authority directly

A permission lease should create test cases, not just documentation.

Add stale-reuse rows to your negative authorization tests:

• The agent tries to use a lease after expiry
• The agent tries to reuse a handle after the subgoal closes
• The agent requests a wider action without approval
• The agent presents a credential to the wrong audience
• The agent retries after revocation
• The agent sees a prompt injection that asks it to renew its own access

Each case should fail before the side effect.

If the tool call still runs, the lease is decorative.

Fail closed and preserve the work

When a lease expires, the agent should not improvise.

Stop the affected action. Preserve the current artifact and evidence. Record which permission ended. Request a new task-bound grant if the work still needs it.

This is the difference between interruption and failure. The workflow can pause without leaving broad authority active.

A permission manifest tells you what an agent may do.

A permission lease tells you why that authority exists, when it ends, and who must approve its return.

Long-running agents need both.

Next free step: Test your agent. Add one stale-permission denial for an expired lease, one denial for a closed subgoal, and one denial for attempted self-renewal.