Capability lease
Reviewed 2026-07-09 · v1.0
a working definition
A capability lease is an AI agent's access grant that is scoped to a single task and expires automatically when that task ends, rather than a standing credential that keeps working until someone remembers to revoke it.
what it looks like in practice
A folder-summarizing tool can be connected two ways: ‘read all files in your drive, standing indefinitely’ or ‘read this one folder, access ends when the summary is done.’ Both let the tool complete an identical task today. Only the second is a capability lease — if the tool is ever hijacked or misused, the first exposes an entire drive indefinitely, and the second exposes one folder for the length of one job.
the machinery parallel
Energized equipment left live. A standing credential is a machine left energized with the key still in it — able to act at any time until someone deliberately de-energizes it. A capability lease is the same access issued the way a permit issues energy: for the job, for its duration, then withdrawn. Building leases by default, rather than remembering to revoke standing keys later, is least-privilege design applied before the grant is ever made instead of clean-up applied after.
how temja trains it
Temja's operator course runs a hands-on consent-screen simulator: learners pick the narrowest sufficient scope for a real-looking access request and see the blast radius of the over-broad choice replayed back to them. Temja's builder curriculum takes the same discipline upstream, designing the tool bindings and credential scopes a system ships with so every task inherits a lease by default rather than a standing key.
questions
Isn't a capability lease just a short-lived token?
A short-lived token is the usual implementation, but the concept is broader: the lease should be scoped to the task's actual resource — this folder, not the whole drive — as well as to time. Narrow duration alone still leaves a wide-open credential for however long it lasts.
Who decides how narrow a lease should be?
The same rule of thumb applies to a single operator's task and to a system a builder is shipping: grant the narrowest scope that still lets the specific task complete, then ask whether the grant needs to outlive the task at all. When the answer is unclear, the safer default is the narrower one.