AI agents should hold permissions that expire

What goes wrong with standing access

An agent deployed in an office today usually logs in with a service account. That account can read folders, edit records and send email across several systems, for as long as the account exists. Three things make this risky.

Agents can be talked into misusing their access. Security researchers call it the confused deputy: a program holding authority is tricked into using it on someone else's behalf.¹ For a language-model agent, the trick can be a sentence hidden in an email or web page it reads. Writing "never touch unrelated files" into the agent's instructions doesn't prevent this, because the same model that can be misled is the one deciding whether an action is allowed.²

Agents hand work to other agents. A booking assistant calls a clinic's scheduling agent, which calls a calendar service. The easy design passes the first agent's full credentials down the chain. One test of a four-party healthcare workflow rejected 14 of 15 attacks. It also found that authority was not narrowed at each hop, and that any party holding the shared key could rewrite the authority being claimed.³

People forget. Access granted for one job stays open after the job ends. Under standing permissions, every forgotten grant is a risk that stays open indefinitely.

There is also a longer-term reason. A system pursuing almost any goal does better with more access and resources, so a capable system will tend to accumulate them.⁴ Expiry means accumulated access drains away by default.

What we propose

1. Narrow. A permission names the task, the data and the actions: read the 2026 tax folder, nothing else. A credential the agent never holds can't be misused, however the agent is manipulated.⁵
2. Short-lived. It expires on its own. Distributed systems have used time-limited leases this way since the 1980s,⁶ and current zero-trust guidance assumes short-lived credentials.⁷
3. Narrower at each hand-off. An agent that calls a helper passes on a subset of its permission, never its own key. Recent designs let the scope, budget and lifetime of a delegated permission shrink but never grow.^2,8
4. Revocable one at a time. Taking back one permission should stop exactly the agents that depended on it and leave the rest of the job running. Current agent frameworks get this wrong in both directions: they cut off too much when agents share a helper, and too little when work crosses organisations.⁹

All four have to be enforced outside the model, by a separate component that checks every tool call. Instructions to the model are not enforcement.

What it looks like in practice

You ask an assistant to prepare your tax return. It gets a 14-day pass to your 2026 tax folder, read-only. On day 15 the pass lapses, and in October the assistant can't read your new bank statements because it never could.

A community clinic gives a scheduling agent a 30-day permission to send appointment reminders and draft supply orders. At the end of the month the manager sees a receipt from the enforcement layer rather than from the agent. It lists the reminders sent and orders drafted, and confirms that no clinical notes were opened. She renews it or lets it lapse.

If a permission runs out mid-task, the agent stops starting new actions, saves its work and leaves a note. Renewal picks up where it stopped.

What a buyer can require now

• Agents get a separate credential per task, not a shared service account.
• Every credential has an expiry date, and the default is days, not years.
• Permissions are checked by a component outside the model, and every grant and use is logged there.
• A sub-agent can never receive more access than the agent that called it.
• Any single grant can be revoked without stopping unrelated work.

The obvious objection

If permissions keep expiring, people will be asked to renew them constantly, and they will click "yes" without reading. That's a real failure mode, and it is why renewal should come at task boundaries, a few times a month, with a short receipt, rather than as a stream of pop-ups. See why your inbox is not a security guard for what happens when approvals are designed badly.

What's unsolved

• Who renews, on what evidence. If a system is better at persuasion than the person reviewing it, it could time requests for when reviewers are rushed, or summarise its own work flatteringly. Receipts written by the enforcement layer help. They don't settle it.
• How long a lease should be for different kinds of work. We are testing durations in simulation before recommending numbers.
• Agents that approve each other. Renewal by another agent can turn into collusion.
• Standards. Researchers are converging on the pieces (task-scoped tokens, delegation that only narrows, targeted revocation) but not yet on a complete architecture.¹⁰

Sources

1. Norm Hardy, "The Confused Deputy (or why capabilities might have been invented)," ACM SIGOPS Operating Systems Review 22, no. 4 (1988): 36–38, doi:10.1145/54289.871709.

2. Aravinda Kashyap Kabbinamakki Suresh and Peng Gao, "AgentCap: Capability-Based Runtime Authorization for Secure LLM Agent Execution" (2026), arXiv:2611.00729.

3. Gabriele Donno, Kashif Mehmood and Katina Kralevska, "Authorization Propagation in Agent2Agent Systems: An Experimental Security Evaluation of Multi-Hop Delegation" (2026), arXiv:2611.07050.

4. Alexander Matt Turner, Logan Smith, Rohin Shah, Andrew Critch and Prasad Tadepalli, "Optimal Policies Tend to Seek Power" (2019), arXiv:1912.01683.

5. Halil Burak Noyan, "Dynamic Capability Scoping for Enterprise AI Agents: A Synthetic Dataset and Three-Source Permission Architecture" (2026), arXiv:2607.22445.

6. Cary G. Gray and David R. Cheriton, "Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency," SOSP '89 (1989): 202–210, doi:10.1145/74850.74870.

7. Scott Rose, Oliver Borchert, Stu Mitchell and Sean Connelly, Zero Trust Architecture, NIST SP 800-207 (2020), doi:10.6028/NIST.SP.800-207.

8. Phat T. Tran-Truong, Ha Vo, Nhut Tran et al., "DelegateGuard: Purpose-Bound Capabilities for Delegated LLM Agent Workflows" (2026), arXiv:2610.16005.

9. Lifei Liu, Haoran Yu and Xiaochong Jiang, "VERA: Authority-Preserving Edge Revocation for Federated AI-Agent Workflows" (2026), arXiv:2608.30091.

10. Krti Tallam, "Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure" (2026), arXiv:2605.05440.