AWS teams using or evaluating Verified Permissions who now need to govern agent actions.
Whether to model agent tool calls in Cedar, put a runtime layer in front of them, or run both.
The control gap
Verified Permissions gives a managed policy decision point with a real policy language and a clean entity model. It fits application authorization well: can this principal perform this action on this resource. Agent tool calls stretch that shape in three places. The interesting attributes live in the call arguments rather than in the entity store, some calls need a human rather than a boolean, and the record that matters is what executed, not what was evaluated.
What good looks like
Cedar keeps the durable entity and permission model, and a runtime layer handles argument-level conditions, request-bound approval, and the execution receipt.
- Model stable relationships in the entity store: ownership, group membership, tenancy. Those change slowly and belong there.
- Evaluate volatile call arguments at runtime, where the values exist, rather than replicating them into an entity store on every request.
- Support a third outcome besides permit and forbid. An agent action often needs a person, and a boolean cannot express that.
- Keep the decision joined to the execution result, so an approval and the action it authorised are one record.
A production workflow
- Express who may act on what in Cedar, and keep that model authoritative.
- At the tool boundary, evaluate the concrete call: the action, the target, and the arguments.
- Escalate the calls whose impact exceeds a threshold to a named reviewer with an expiry.
- Attach the upstream outcome to the decision, so evidence covers what happened rather than what was permitted.
Evidence to require
- Which policy store and policy version answered each authorization request.
- The argument values that made a call high-impact, retained with the decision.
- Approval requests, reviewers, expiries, and whether the approved call executed.
- Actions permitted by the entity model but stopped at runtime, and why.
Buyer checklist
- Do the attributes your rules need live in an entity store, or in the request?
- How would you express require approval in a system whose outcomes are permit and forbid?
- Where is the record that the approved action actually ran, and did it succeed?
- How much of the entity store would have to be refreshed per request to make argument rules work?
Practical answers
Common implementation questions
Should we write agent policy in Cedar?
Write the durable part in Cedar. Ownership, tenancy, and role relationships belong in a policy store with a real language. The per-call conditions that depend on an amount, a target record, or an environment are better evaluated where those values already are.
Is this an argument against Verified Permissions?
No. It is an argument against expecting one layer to do two jobs. The entity and policy model is the strongest part of that product, and a runtime layer works better on top of it than instead of it.
What about running Cedar ourselves instead?
Same trade-off, different operational cost. Self-hosting removes the managed dependency and adds availability and upgrade work. Neither choice changes where argument-level conditions and approvals need to live.