How ORBIT governs your agents

ORBIT is a deterministic authority layer that sits at your AI agent’s tool boundary. Before a governed action runs, ORBIT decides from concrete facts — what the action is, who’s asking, your policy, your approval — not from the AI’s opinion. The AI can advise; it can never authorize its own privileged actions.

Your agent tries a tool action. ORBIT’s local hook intercepts it before it runs and classifies it against your policy. One of three outcomes:

• Allow — routine for this agent → runs immediately; a receipt is recorded.
• Step-up — sensitive → ORBIT pauses execution and asks you in your ORBIT browser session. Approve once or deny. It runs only on your approval.
• Deny — a protected floor (e.g. rm -rf /, secrets, protected-branch force-push) → blocked, fail-closed. It never runs.

Deny always wins. No standing approval, convenience setting, or AI suggestion can override a protected floor.

A step-up is one durable request in your signed-in ORBIT web session; web push alerts you there when enabled. Every request carries its own visible deadline, and an unanswered request expires and is denied — safe by default. An approval without a durable receipt is not execution authority. See Approvals.

For a burst of similar work you can grant a bounded standing approval — 10 minutes, 30 minutes, or 1 hour — so matching actions proceed without re-prompting until it expires. Longer windows are locked behind stronger verification. Protected floors still require step-up or stay denied.

ORBIT watches what your agents actually do and turns repeated approvals into suggested policy changes in plain language (“treat this repo like your other normal repos”). Nothing changes silently: you review the suggestion and approve it yourself, and the change is versioned and recorded with a receipt. The AI drafts; you approve; the policy service applies; the runtime proves.

Each receipt shows the exact action, the decision, who decided, and whether execution proof exists — with the raw details a tap away. Receipts are signed and independently verifiable, and ORBIT never claims enforcement a connector can’t actually perform. See Verifying receipts.

Recovery never depends on ORBIT being reachable. A local break-glass CLI can disable or uninstall ORBIT even if the service is down, and read-only / recovery-safe actions fail open so you’re never bricked by an outage. Governance is strong; it is not a trap.

Different runtimes have different enforcement depth. ORBIT labels each connector truthfully — Ask/Block-capable, Receipt-only, or Not-visible-here — and shows known gaps rather than hiding them. In beta you’ll see these labels; they’re the truth, not a limitation we’re papering over.

Known gap in beta: on OpenClaw runtimes, when an agent hands work to an embedded child agent, the child’s actions don’t pass through ORBIT’s pre-action check yet — they run under the runtime’s own controls only. This is a runtime limitation, not a setting you can change. The durable fix is the host-level Guardian, which watches the machine rather than the agent.