Agent Short-Lived Capability Leases: Binding Least Privilege to Task, Resource, and Deadline
An agent should not hold a master credential covering an entire session. This article designs short-lived capability leases issued by a policy broker, binding tools, resources, call counts, executor keys, and a revocation epoch.
Key Points
- Topic Focus: AI Agent、MCP、DevOps
- Suitable for: indie hackers, full-stack engineers, AI application developers
- Core value: quickly understand background, practical paths, common pitfalls, and engineering advice
Many agent platforms have already decoupled the model from long-lived API keys, but they still inject a single bearer token into a run that can access an entire project and lasts for hours. The task only needs to read three tickets and create one draft, yet this token could export every customer or call any write tool; the moment it leaks into a prompt, a log, or a malicious tool, the attack window persists until a manual rotation.
MCP Server Authentication Boundaries addresses keeping user, service, and tool identities from being mixed, while AI Platform Secrets Rotation covers the lifecycle of long-lived credentials. This article focuses on a narrower layer: before each high-value tool call, a trusted policy broker exchanges identity for a short-lived capability lease that authorizes only the tools, resources, and call counts this task requires.
Identity proves "who"; a lease proves "what it can do right now"
The worker requests a lease using its workload identity, and the broker takes the user, tenant, and run from the server-side session rather than trusting any identity submitted by the model. The policy engine combines tool risk, ACLs, approvals, and budget to produce constraints.
The lease binds issuer, subject, the actor representing the user, audience, tenant, run, tool, resource constraints, call count, lifetime, a unique capability jti, policy version, and revocation epoch. Write operations usually need only tens of seconds and must not cover an entire chat session.
{
"iss": "capability-broker",
"sub": "agent-worker-17",
"act": { "sub": "user-42" },
"aud": "ticket-service",
"run_id": "run-9f2",
"tenant_id": "tenant-a",
"tool": "ticket.create_draft",
"resource": { "project_id": "p-7", "version": 41, "acl_epoch": 12, "max_items": 1 },
"max_uses": 1,
"exp": 1784362260,
"jti": "cap-01J...",
"cnf": { "jkt": "base64url-jwk-thumbprint" },
"policy_version": "agent-cap-v12",
"revocation_epoch": 38
}
OAuth Token Exchange can serve as the protocol foundation, but the result still requires business constraints. Do not forward the upstream token or only grant a broad write; resource filters should include project, version, ACL epoch, fields, and quantity limits.
Bind the token to the executor, not a bare bearer
A short TTL does not stop abuse inside the window. The worker generates a temporary asymmetric key for the run, and the lease binds the public key thumbprint via cnf.jkt. Each request additionally signs a DPoP proof JWT: the header must use typ=dpop+jwt, an asymmetric algorithm allowlist, and a public jwk; the payload contains htm, the htu normalized by the same server-side rule with query/fragment stripped, iat, a hash of the access lease ath, a server nonce, and a proof jti that differs from the capability jti and is unique per request.
The tool side rejects none, symmetric algorithms, and private-key JWKs; it verifies that the JWK thumbprint equals cnf.jkt and that method/URI/ath/nonce all match. iat is accepted only within a small window, and (jkt, proof_jti) is written atomically into the replay cache within that window; a duplicate proof is rejected. HTTP retries generate a new proof but reuse the same execution id to query the original result, and must not produce a second logical side effect. The temporary private key never enters the model and is destroyed when the run ends.
Coding Agent Sandbox Permissions isolate files, commands, and network, while capability leases constrain server-side business actions; both must exist together.
Each tool service independently enforces constraints
After the gateway verifies the signature, downstream still validates audience, issuer, time, tenant, tool, constraints, and revocation epoch, and must not trust client headers. The local executor locks the capability, target, and authorization version within the same transaction, re-checks ACL, tenant, resource_version, and acl_epoch; only on a match does it update the business state, consume the use count, and create the execution/outbox. On a mismatch it commits a terminal STALE and the old capability can no longer be used.
External side effects must use If-Match/ETag, version preconditions, reservations, or equivalent conditional operations on the target system, and pass the execution id as the idempotency key. A 412, reservation invalidation, or ACL denial all terminate that execution and render the capability non-reusable; an unknown result enters reconciliation and must not create a second logical execution on the original lease. Human approval is only an issuance condition; the Agent Human Approval Gate cannot replace this atomic boundary.
The agent must not refresh on its own; a new exchange must re-check session, policy, resource, and budget. When a run is cancelled, permissions are revoked, or a policy hole is discovered, raise revocation_epoch to immediately reject all old-epoch leases.
Acceptance with theft and boundary tests
A negative matrix covers switching audience/tenant/tool, expanding resources, expiry, a second consumption of the capability jti, a duplicate proof jti, wrong ath/nonce/htu, a private key from another run, and resource version or ACL changes. Each item is rejected by the server and leaves an unforgeable audit trail.
Stress test broker unavailability and consumption storage timeouts. High-risk write operations should fail closed; a small amount of low-risk read-only traffic may use already-issued, still-valid leases, but must not cache an indefinite master token. Monitor issuance rate, rejection reasons, average TTL, overly broad resource constraints, duplicate consumption, and near-expiry retries; trigger a circuit breaker when a run applies for new leases at high frequency.
Rollback must not restore a master credential
When a new policy falsely rejects, roll back to the previous signed constraint template and validator version rather than disabling audience, proof, or resource checks. First pause new lease issuance, preserving already-validated read-only traffic; if you suspect the signing key or policy is compromised, raise the revocation epoch, rotate the broker key, and disable the relevant write tools. After recovery, validate with the full negative matrix and gradually reopen tenants.
If the capability service is fully unavailable, the product should offer a read-only or draft mode and tell the user clearly, rather than re-injecting long-lived service credentials into the agent. True least privilege is not hiding one big token more carefully; it is giving every capability a short lifetime, a narrow resource, a designated executor, and a verifiable consumption record. That way a single leak affects at most one constrained action, not the entire session and project.
Further reading
Related
Related Content
Article
From Copilot to Codex: AI Coding Tools Enter the Agent Era
Technical trends, engineering practices, and indie-developer perspectives around AI, AI Agents, and Vibe Coding.
Article
Why Does MCP Matter? Understanding the AI Tool Protocol
Technical trends, engineering practices, and an independent developer perspective on MCP and AI Agents.
Article
Core Architecture of AI Agents: Planning, Memory, Tools, and Execution
Technical trends, engineering practices, and independent developer perspectives around AI Agents and large language models.
Article
How Should RAG and Agents Work Together?
An independent developer's perspective on technical trends and engineering practices involving RAG and AI agents.