Approval model
Approval decisions are enforced on the CLI device running the agent. The App, account service, or relay may carry a request and the user's response, but cannot replace final policy evaluation by the target CLI.
Permission ceiling and session approval
A collaboration workspace has two limits: the Agent access limit defines what an Agent may do at most, while Session approval decides whether the current session must ask for confirmation. Session approval can only make the limit stricter; it cannot widen the Agent's access.
Five modes
| CLI ID | App label | Behavior |
|---|---|---|
manual | Ask every time | Every approval request waits for the user |
guarded | Guarded | Routine work continues automatically; high-risk or uncertain work asks |
ai_review | AI Review | An independent reviewer handles routine requests; high-risk or uncertain work asks |
unrestricted | Full | The OriginRouter approval layer adds as little blocking as possible, while Agent and system limits still apply |
custom | Rules | Evaluates the selected versioned policy on the execution device |
Decision inputs
Policy evaluation may use operation type, command, normalized path, network target, tool identity, workspace boundary, session settings, and the user's choice. The presentation layer must distinguish factual evidence from inferred summaries.
Fail closed
Unknown tools, insufficient evidence, unsafe path resolution, ambiguous shell expansion, or operations outside policy expressiveness should fall back to human review or denial instead of being silently allowed.
App and CLI roles
- The App manages templates, presents requests, and collects user action; it does not replace policy evaluation on the target CLI.
- The CLI loads current policy, evaluates the request, executes or denies the operation, and records local audit.
- The service handles authentication, directory, and delivery; it does not own local workspace decisions.