How ORBIT governs covered agent actions

ORBIT is a deterministic authority layer for agent actions routed through an installed adapter, hook, wrapper, or reviewed integration. It evaluates concrete facts — the exact action, actor, active rules, protected floors, and any required human authority. The AI may explain or recommend; it cannot authorize its own privileged action.

An action can have one of three coverage postures, and the interface must not collapse them:

• Covered · enforcing — the installed path can pause the supported action before its side effect and wait for ORBIT’s execution-safe result.
• Covered · observe-only — ORBIT records what the adapter reports, but does not claim it prevented or caused the downstream action.
• Uncovered — no adapter signal means ORBIT makes no governance, execution, or all-clear claim for that path.

Signed-in operators can inspect the current adapter-declared register in Coverage.

On a covered enforcing path, policy evaluates the exact action and produces a product state:

• Allowed — policy and required proof gates permit ORBIT to release execution authority for that exact action. The runtime still reports separately whether execution was attempted, completed, failed, or remains unknown.
• Held — the action is paused while ORBIT obtains the required human decision or stronger authority. It is neither denied nor executed.
• Blocked — ORBIT issues no execution permission for that exact covered request. The record names whether policy, human denial, expiry, or another gate blocked it.

Protected floors and deny rules dominate. A standing grant or convenience setting cannot relax them.

A Held action creates one durable escalation. In Needs You, the human may Approve once for that exact action or Deny. Controls become inert at the server deadline, concurrent decisions converge on the first accepted result, and execution authority remains false until the required authorization receipt is committed. Browser push can notify; the channel is never authority.

See Approvals for the decision-state details.

When current policy permits it, a separate standing-authority path can grant a tightly scoped, time-bounded, revocable window. The server offers the eligible durations and scope for the exact escalation; the interface does not promise a fixed ladder. Every consumption rechecks current floors, scope, expiry, revocation, caps, and target drift, then records its own action-bound receipt.

Repeated evidence can support a future safeguard recommendation. A recommendation is not active policy and is not another approval choice. ORBIT does not currently expose a general safeguard editor. Learning never silently changes authority.

The authorization receipt is committed before execution permission for a Held action. A later execution report or evidence receipt may say whether the runtime attempted or completed the action; authorization alone never makes that claim.

Current public .orbitproof verification checks the uploaded package’s internal signature and Merkle inclusion proof. It does not establish a trusted ORBIT instance or key era, and it does not prove downstream execution. See Verifying receipts.

Outage behavior is adapter- and mode-specific. An enforcing path, an observe-only path, and an uncovered path cannot share one blanket recovery promise. Use the installed adapter’s documented break-glass, export, and uninstall procedures; ORBIT must continue to label what remained enforced, what was merely observed, and what became unknown.

See Break-glass and recovery.