Agentic authorization: a practical architecture for delegated actions
A concrete model for approving authority once, enforcing it later, and proving what happened without letting the agent or authorization service execute the action.
Product, platform, security, and payments teams
Key takeaways
- Treat the prompt as input, not as the authorization artifact.
- Separate approval, deterministic evaluation, single-use state, and external execution.
- Design the non-allow and recovery paths before connecting an irreversible action.
A five-part delegated-action flow
The clean architecture separates intent capture, approval, evaluation, execution, and evidence. Each step has a different owner and a different failure mode.
- The platform converts authenticated user intent into a typed, bounded mandate.
- A trusted approval surface shows the exact mandate and collects passkey approval.
- Later, the platform submits one concrete proposed action for evaluation.
- The authorization runtime returns ALLOW, DENY, or INDETERMINATE and may reserve one execution.
- The platform executes in its own systems, then commits or cancels the reserved authorization.
A decision is not enough; the runtime needs state
A stateless policy check can say that two simultaneous requests are both eligible. If the mandate is single-use, both cannot be allowed to execute. The authorization layer therefore needs an atomic reservation and an explicit lifecycle, not merely a boolean policy response.
ALLOW should mean that the submitted action matched every known constraint and that the runtime secured the right to one bounded execution. DENY should identify a known mismatch. INDETERMINATE should be a safe non-allow result when a constraint is unknown, unsupported, or cannot be evaluated reliably.
Keep authorization separate from execution
The platform should remain responsible for booking, purchasing, issuing credentials, moving money, fulfillment, and settlement. The authorization service receives only the fields needed to compare a proposed action with the mandate. This reduces its security surface and avoids coupling authority to one processor or execution rail.
That boundary also makes integration easier to reason about. The platform calls the authorization layer after it has a concrete live action and before it crosses an irreversible boundary. Existing checkout, fraud, booking, and payment systems stay in place.
What a production design must prove
A credible design is demonstrated by failure behavior, not by the happy path alone. Teams should test the state machine under retries, races, expired mandates, revocation, unsupported fields, and downstream failures.
- The approved policy is immutable and bound to the approving subject and platform.
- Every decision is deterministic for the same normalized inputs and policy version.
- Concurrent eligible proposals cannot consume one mandate twice.
- Retries are idempotent and return the same authorization identity.
- Evidence joins approval, proposal, decision, lifecycle events, and external references.
- Execution never proceeds on DENY, INDETERMINATE, expiry, or an invalid reservation.