Skip to main content
Copy this table into your own docs, fill in names, then enforce each cell. A RACI table on its own is a document the agent never reads. The sections below show which theAuth API makes each cell true. For the background, see AI agent identity and accountability.

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() and evaluate() 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 onViolation hook or a scheduled audit.query. Audit writes for policy decisions, delegation and approval events are best effort and counted on failure, so watch getAuditWriteFailures.

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.
Create the agent with these permissions and the accountable human as ownerId:
For the spend row, a risk tier escalates payments above an amount instead of a resource string chosen in app code:
The threshold is a risk-tier rule keyed on 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.
Last modified on October 16, 2026