Available in AOS Core 0.2.0-rc14. Install the verified package from Downloads.
Contract approval enables a capability. Action approval permits one exact request to a capability.
Operations marked as requiring approval need both. A different identity with the reviewer role
must review the operation, inputs, context and constraints before the requester executes it.
The reviewer role alone cannot execute actions.
Console
- Under Capabilities, choose Invoke, select the operation and enter its input JSON. For an operation requiring approval, submitting creates a pending review without executing it.
- A different reviewer signs in through Session, opens Action Reviews, checks the exact request, chooses Approve or Reject, and supplies a reason.
- The original requester signs in, opens Action Reviews, and chooses Execute approved action.
- Inspect the receipt. Retrieve receipt uses the same request key; it does not authorize another execution. For an unknown outcome, inspect runtime/provider evidence instead of creating a new request.
CLI
Configure AOS_URL, AOS_TENANT_ID and AOS_TOKEN_FILE for your existing requester identity.
Use a capability whose contract is already approved. Replace CAPABILITY_ID and REVIEW_ID below
with the returned identifiers. Create action.json in a private directory:
{"operation":"restart","input":{"service":"staging-service"}}
aos product action request CAPABILITY_ID --file action.json
aos product action show REVIEW_ID
In the reviewer’s terminal, using their own AOS_TOKEN_FILE:
aos product action show REVIEW_ID
aos product action decide REVIEW_ID --decision approve --reason "Reviewed the service and restart scope"
Back in the requester’s terminal:
aos product action execute REVIEW_ID
aos product action list
The execute command reads the approved request from AOS, preserving all its fields, and uses a stable key derived from the review ID. UI and CLI execution use the same key. A request with changed inputs, context, constraints, correlation ID, capability manifest or activation policy is blocked. Current tenant policy, identity, capability access, revocation and budgets are evaluated at invocation.
An approval expires one hour after the request was created. Consumption is atomic and one-shot, including across competing request keys. Consumption is not reset on a crash, policy denial or an unknown result. Inspect the evidence before intentionally requesting a different action. The gateway retains replay guards beyond response expiry; see recovery and retention.
The LangGraph integration creates a pending review and includes its ID in the interrupt. AOS approval and the application’s consent to resume are separate checks. The graph does not approve its own actions.
Deployment and data handling
Back up the database and apply aos db upgrade before starting this release. Migration
20261110_0031 adds gateway_action_reviews; it does not alter existing action records. Disable
gateway writes during an upgrade or rollback. Rolling back to rc11 removes this enforcement, so it is
not a safe way to continue processing operations that require approval.
Review records contain the exact supplied action inputs/context for requester and tenant reviewer access. Do not include secrets or unrelated private context. Protect the database, backups and checkpoint files with your retention/access policy. Audit events record review IDs and digests rather than copying action payloads. Local evaluation uses two temporary identities and a harmless HTTP counter. It does not qualify an external identity provider or a production deployment.