How ORBIT works

ORBIT sits between the agent's intent and the agent's irreversible action. Not in front of the LLM (the LLM does whatever it does). Not after the action (the damage is already done). At the exact point where the agent says “run this Bash command”, “write to this file”, “POST to this URL”, and before the runtime actually does it.

That position is what makes the receipt meaningful. Logs after the fact can be rewritten by whatever rewrote the system. ORBIT signs the decision before the action happens; the receipt binds the authorization to the operation it permitted.

An Agent Policy is your governance policy in machine-readable form. It says what the agent is allowed to do, what gets blocked, and what needs human approval at the moment of action. Agent Policy data lives on ORBIT's side, is signed by ORBIT's key, and is referenced by hash in every receipt. The agent cannot tamper with the active policy at runtime: every governed call hashes the policy that was active and binds it to the receipt, so a swapped or edited policy is detectable after the fact.

The design invariant for policy modifications is that they are themselves governed actions and go through the same approval gate as any other change. That self-protection is the target model. The current Agent Policy editor surface is a preview build: rule mutations update local state only, and the SMS approval step is simulated. The signed-policy and hash-in-receipt half of this model is live today; the approval-gated mutation half lands with the live escalation API.

Policy rules read like sentences: When agent tries to: Run a Bash command. Matching: any sudo command. Decision: Ask me via SMS. The UI presents the rules as plain English; the underlying engine record (called a charter internally) is a structured tuple of tool, pattern, verdict, fallback, description, and timeout. Users edit Agent Policy; the charter is the implementation artifact the receipt hashes.

orbit-hookis a small native binary that runs inside the agent process via the agent's hook system. It intercepts tool calls before they execute. It does not proxy the LLM. It does not see the LLM's output, the user's prompt, or earlier conversation context. It sees one thing: the structured payload the agent passed to the tool runtime.

For each governed call, orbit-hook issues a Decision Record request to the ORBIT gateway with the tool name, the payload, and session metadata. The gateway evaluates against the active Agent Policy, returns a verdict (Allow / Ask me first / Block), and only after the verdict comes back does the tool actually execute.

For routine operations (normal Read/Write/Edit, common Bash commands, git/npm work) the evaluation completes in ~30-150ms. The latency is real and intentional: the round-trip is what produces the signed receipt. There is no local-allow fallback: the gateway is the only authority that can permit a governed action, so when the gateway is unreachable the call is blocked (see Fail-closed below). orbit-hook can record local telemetry while disconnected, but it does not have signing authority and cannot let an action through on its own.

For sensitive matches, the gateway returns “Ask me first” and the agent pauses while ORBIT sends an SMS to the verified approver. The agent does not see the SMS; it sees a wait. When approval arrives, the gateway returns the final verdict and the agent proceeds. Approval delivery is out-of-band on purpose so an agent running overnight with no one at the keyboard is still gated.

Every governed decision produces a cryptographic receipt. The receipt binds together:

• The hashed Agent Policy that was active at decision time (so the policy is auditable)
• The canonical action that was evaluated (tool name + payload hash)
• The verdict (Allow / Block / approval-with-SMS-trace)
• The principal (which ORBIT account, which agent session)
• A digital signature from ORBIT's signing key (current algorithm: ECDSA P-256, FIPS 140-2; the algorithm identifier travels in the receipt so verifiers know which primitive to use)
• The timestamp and the signing-key identifier (so rotation is traceable)

The receipt does NOT contain raw execution artifacts (file contents, command output, HTTP response body). It can carry reported or verified outcome fields (the receipt-tier model distinguishes authorization-only, authorization + reported outcome, and authorization + verified outcome), but never the raw payload the action produced. The action's consequences live wherever the action wrote them; ORBIT's job is to make the decision itself tamper-evident.

Receipts are independently verifiable. The ORBIT public key is served at /api/public-key. The web verifier at /verify is live today and uploads the parsed receipt to ORBIT for a server-side signature check. The offline orbit-verify CLI is on the roadmap and not yet published; see /docs/verify for the planned install and pinned-key flow. Fetching the key from /api/public-key does contact ORBIT. Once a verifier has a pinned or archived copy of the public key, anyone with a .orbitprooffile will be able to confirm the signature offline without contacting ORBIT's infrastructure (via the CLI, once shipped).

That property is important for audit and dispute resolution: a receipt presented as evidence months later remains verifiable without depending on ORBIT being available. Customers can archive .orbitproof files in their own systems and reverify them through /verify today, or through the offline CLI once it ships.

Receipts are owner-only at the access layer. The web verifier accepts a file upload and returns the verdict; it does NOT expose receipts by URL. Sharing happens by exchanging the file through whatever secure channel the parties already use.

If orbit-hook cannot reach the gateway, governed actions are blocked, not allowed through. There is no fail-open setting and there will not be one in v1. The choice is deliberate: an ORBIT outage that left agents free to run unrestricted would be worse than an outage that paused agent work until ORBIT was back.

Same principle on approval timeouts: if you do not reply to an SMS within the configured window (default 120 seconds), the action is blocked, not allowed. The agent sees a clean block verdict and the model can proceed to other work; nothing hangs.

Guardian for Agents is the first ORBIT module shipping. Future modules (Stripe Guardian, MCP Governance, Compliance Plane) share the same primitives: Agent Policy, runtime evaluation, signed receipts, the same verifier path. Adding a module means adding a new adapter that normalizes the surface's tool calls into ORBIT's canonical action shape, plus the policy content for that surface. The trust model and the receipt format are stable across modules.

The patent portfolio covers the architectural primitives (signed-policy boundary, receipt-as-evidence, fail-closed runtime governance) across modules, not just any one implementation.