The template
One row per action class. Replace the placeholders in the last four columns.
Keep exactly one accountable party per row. If two names are accountable, nobody is.
How each cell is enforced
Two limits matter when you fill in the table:
- The Consulted cell is a record, not a bypass.
authorize()andevaluate()keep returning deny or escalate after a human approves, so your code runs the approved action itself. - The Informed cell is passive. theAuth writes the rows. Alerting a person is your job, for example from the
onViolationhook or a scheduledaudit.query. Audit writes for policy decisions, delegation and approval events are best effort and counted on failure, so watchgetAuditWriteFailures.
Policy skeleton
theAuth permissions are typed objects, not a YAML or JSON policy language. This skeleton matches the table above. Each entry is the same permission shape used by the policy templates.ownerId:
context.risk.amount, not a general numeric constraint on a permission. For sub-agents, delegate with theauth.delegate(): constraints carry over and can only tighten. See the spending limit (08) and owner scope (09) entries in Policy templates.
A RACI “Consulted” or “Informed” party that is a team, not a person, is represented by whoever your
onApprovalNeeded handler or alert routes to. theAuth stores a single ownerId per agent.