Start here
Core concepts
The pieces behind a decision, and the responsibilities that stay with your integration.
Projects and identity
A project holds policy, agent keys, logs, and confirmations. The backend creates one project per owner. Team roles, project switching, and per-tool key scopes are not implemented.
The owner identity manages the project. A project API key lets an agent check actions and poll reviews. These are separate authentication paths.
Proposed actions
An action has a name, such as navigate or submit, and optional data, destination, and task context. Submit it before executing the operation.
Action names are application-defined strings. Calling an action delete does not delete anything. Your adapter must faithfully describe the operation it will perform.
The three decisions
| Decision | Meaning | Your integration should |
|---|---|---|
| approved | No configured rule blocked or paused the proposal. | Execute the exact checked action, subject to your other controls. |
| denied | A destination rule blocked the proposal. | Stop without executing. |
| requires_human | A data or action rule requires review. | Pause until the owner approves this confirmation. |
Checks, confirmations, and evidence
check_id identifies the original policy evaluation. confirmation_id identifies its review. They are different IDs.
Resolution changes the confirmation status, not the original audit verdict. A requires_human log can therefore have an approved confirmation. A check proves a decision was recorded; it does not prove an external action executed or succeeded.
The execution boundary
The API evaluates proposals it receives. It does not intercept commands, isolate processes, filter live traffic, or stop access through another tool. Your integration must route relevant actions through the gate and block execution when required.
Disposable environments, task-scoped credentials, transactional output promotion, and execution replay are planned. See availability.