Request lifecycle
An action request represents an intended operation: install a plugin, change a source, create an issue, send an external action, or call a plugin action. The policy engine evaluates the request before it can execute.
| Status | Meaning |
|---|---|
| draft | A supported pre-approval state. Approval and rejection functions can transition it, but most main creation paths create pending_approval or approved directly. |
| pending_approval | A reviewer must approve or reject the request. |
| approved | The request can be queued for execution. |
| rejected | A reviewer rejected it. |
| expired | The request is no longer actionable. |
| executed | Execution completed successfully. |
| failed | Execution failed. |
| cancelled | The request was withdrawn. |
Policy modes
| Mode | Result |
|---|---|
| observe_only | Deny execution and keep the request observable. |
| draft_only | Require human approval before execution. |
| approval_required | Require approval, normally by the configured approver role. |
| auto_approve | Allow execution only when risk is at or below the policy threshold. |
| never | Deny the action. |
Policies are sorted by ascending priority, so lower numbers win. Default policies cover user administration, source configuration, code actions, channel management, data-source management, plugin management, and a broad external-action fallback.
Plugin actions
Plugin action manifests can declare default_mode. auto creates auto-approve policy rows for that plugin action and scope, ask falls through to approval behavior, and deny keeps the action off the agent tool surface.
- Use action kinds that are specific enough for policy review.
- Set risk levels conservatively for external writes or user administration.
- Keep plugin credentials in worker-side secrets and sandbox injection, and keep browser state free of them.
- Review action_execution rows for executor, operation, payload, result, status, error, and external references.