One-use AI agent grant policy

The control gap

A short expiry still permits replay during its lifetime unless the execution boundary consumes the grant atomically.

The one-use property is enforced in storage, not by a convention in the agent prompt. Grant tokens are opaque and hashed. Consumption updates the matching active record atomically, requiring unused state, valid expiry, and exact adapter, tool, and resource. Two concurrent attempts cannot both acquire the same grant.

A provider timeout or rejection still consumes the grant and closes the evidence chain with failure. Retrying the business action requires a fresh decision or a deliberately designed idempotent retry policy; it must not replay the original temporary authority. This protects against duplicate side effects and keeps every attempt attributable.

Bind the grant to a canonical request digest after validation. Fields that affect authority—tenant, environment, adapter, action, resource, amount, recipient, and task—must be part of that digest. Cosmetic metadata may remain outside it, but changing any security-relevant argument requires authorization again.

Return the opaque grant only to the trusted execution component. Avoid browser storage, agent conversation history, traces, and analytics. Store a salted hash server-side, reveal the token once, apply a short absolute expiry, and make revocation an atomic state transition that races safely with consumption.

Test concurrency at the database boundary rather than with sequential API calls. Submit the same grant from multiple workers and confirm exactly one obtains execution authority. Then simulate provider timeout, process crash, and duplicate webhook delivery; none should reopen the consumed capability or fabricate a second successful action.

What good looks like

A narrow policy that can be tested in shadow mode, reviewed with owners, and promoted to enforcement with measurable impact.

• Match the concrete action "github.create_issue" rather than every operation exposed by the tool.
• Scope the target to one approved tool call consumed by the provider adapter and the production environment.
• Require a request-bound approval that expires and cannot be reused.
• Record denied attempts as well as approved executions.

A production workflow

1. Copy the template and replace example identities and resource selectors.
2. Run it in shadow mode against representative requests.
3. Review false positives, missing resource attributes, and approver routing.
4. Enable enforcement for one agent and expand only after reviewing the decision log.

A policy you can test

One-use AI agent grant policy is a concrete starting point, not a claim that one generic rule fits every environment. Replace example identities and selectors, validate the request shape, and begin in shadow mode.

name: one-use-agent-grant
match:
  identity_verified: true
  tool: github.create_issue
  resource: repo:acme/platform
decision: require_approval
approval:
  reviewers: ["repository-owners"]
  expires_in: 10m

Endram keeps the policy version with every decision. A later change creates new evidence instead of rewriting why an earlier request was permitted.

Evidence to require

• Every attempted github.create_issue, including denied requests.
• The exact one approved tool call consumed by the provider adapter selector evaluated by policy.
• The requesting agent, delegated user, reviewer, and timestamps.
• Policy version, matched rule, decision reason, and execution result.

Buyer checklist

• Does the selector cover only the intended production resources?
• Who owns the approval queue outside business hours?
• What is the acceptable approval expiry?
• Which emergency identity may bypass the rule, and how is that use audited?