Frequently asked questions

ORBIT is runtime governance and audit infrastructure for AI agents. It watches what an agent actually does at the moment of action and applies your policy before the action runs.

Guardian for Agents is the first ORBIT module shipping. It targets developers using coding agents such as Claude Code and OpenClaw, where the agent has shell access, file write, and outbound network. Other modules (Stripe Guardian, MCP Governance, Compliance Plane) are coming on the same substrate.

The free tier ships now. You get receipts on every governed action, the default policy, the audit log, and the verify-a-receipt path. Browser approval alerts are unlimited and free.

Guard (paid) unlocks the paid-tier rules in your policy. Free shows you greyed-out paid rules with shadow-log match counts so you can see what Guard would have caught before deciding whether to upgrade.

orbit-hook runs inside the agent process and intercepts tool calls before they execute. For each governed tool call, it sees:

• The tool name (Bash, Write, Read, Edit, WebFetch, etc.)
• The structured payload the agent passed to that tool (the command string, the file path, the URL, etc.)
• Metadata about the agent session (origin, working directory, configured policy)

ORBIT does notsee the LLM prompt, the LLM's reasoning, or content from earlier in the conversation. It sees the tool call the agent is about to make, which is enough to decide whether to allow, block, or ask you.

The default policy is deliberately permissive on routine development and protective on the moves that can do irreversible damage. Out of the box:

• Ask first (approval alert): sudo, AWS CLI, anything that looks like a destructive file delete, Agent Policy / ORBIT config writes, API-key edits.
• Allow without asking: normal Read / Edit / Write within the working directory, common Bash commands (git, npm, ls, grep, cat), local builds and tests.
• Block outright: very few rules, only the narrow cases where the agent could disable governance itself with high confidence on the target.

You can see and edit every rule in Rules.

The action is blocked. ORBIT fails closed: if approval does not arrive within the configured timeout (default 120 seconds), the governed hook path returns a denied result instead of approval. ORBIT does not offer an “allow on timeout” mode for this path, because silence should not become consent.

The agent sees a clean block, not a hang. The CLI returns immediately to the agent with “blocked: approval timeout” so the model can proceed to other work.

Short answer: ORBIT sees the tool call arguments your agent makes. So if your agent runs echo $SECRET_TOKEN, ORBIT sees the literal string echo $SECRET_TOKEN, not the expanded value. If your agent runs cat /etc/passwd, ORBIT sees that command but not the file contents (Read tool calls return content to the agent, not to ORBIT).

Receipts record the tool call and the verdict, not the result. The agent's output is never sent to ORBIT's servers. See /privacy for the formal version.

Governed actions generate signed cryptographic receipts when they reach ORBIT's decision service. Receipts are private to your ORBIT account. They are owner-only. The web verifier at /verify only accepts a .orbitproof file you upload; it does not expose receipts by URL.

To share a receipt for audit or compliance evidence, download the .orbitproof file from your dashboard and send it through whatever secure channel you already use. The recipient verifies it with the offline CLI or the public verifier. Neither requires ORBIT account access. The public key is pinned and rotated periodically (current key visible on the verify page).

For details on the three receipt tiers and what each proves, see Verifying receipts.

No, and that is the point. The whole gate exists because a single bypass is the failure mode. If you genuinely need a different verdict on a specific command, change the rule in your policy: add an Always allow rule narrowly scoped to that command, or set the rule to Ask me first and approve from the alert at the moment.

The agent should not disable ORBIT through the governed path. Modifications to your Agent Policy, ORBIT config, audit logging, and API keys should be routed through the same approval path when those surfaces are wired to ORBIT. If the hook is not installed or a tool path is outside ORBIT's adapters, ORBIT cannot honestly claim control over that path.

For a configured governed call, orbit-hook fails closed. If it cannot reach the ORBIT gateway to evaluate the action, the hook path returns a denied result instead of a local allow. That does not mean ORBIT controls uninstrumented tools on the same machine; it means the governed adapter path does not silently bypass the gateway.

In practice the gateway is designed to be highly available, but the choice to fail closed is deliberate for governed paths: an outage should pause agent work instead of creating a silent allow bypass. Status at /status.

Remove the orbit-hook binary and the hook configuration from your agent setup. For Claude Code, that is the hooks section in ~/.claude/settings.json. Once the hook is gone, ORBIT no longer sees the agent's tool calls.

Your account, your receipts, and your policy remain on the ORBIT side until you delete the account from /org. After account deletion, receipts you already downloaded as .orbitprooffiles remain verifiable against the published public key indefinitely. They do not need ORBIT's infrastructure to verify.

Claude Code's built-in permission prompts ask you in the same terminal session before certain tool calls. They are convenient but have three limits ORBIT addresses:

• They live in the same session as the agent. ORBIT runs out-of-band and surfaces the approval in your ORBIT browser session, so an agent running unattended overnight is still gated.
• They do not produce a verifiable audit trail. ORBIT writes a signed cryptographic receipt for every governed action, including the denials.
• They are per-tool and per-session. ORBIT's policy is per-account and can include rules Claude Code does not have (custom regex on Bash commands, file path scoping, time-of-day gates, etc.).

You can run both at the same time. Claude Code prompts are still useful as a local fast-path; ORBIT is the durable governance and audit layer.

ORBIT governs agents that run on hardware you control, by wiring a pre-execution hook into the agent's tool-call path. It works with the Claude Code CLI, OpenClaw, Hermes, Codex, and other runtimes whose tool execution you host and can install a hook into.

It does not work with Claude Desktop(or other apps that run tools inside their own sandbox). Those apps execute tool calls in an environment they control, so there is no local execution boundary for ORBIT to sit in front of — and there is nothing to govern, since the work is not running on your machine. If Claude Desktop tells you a command runs in a sandbox, that is expected: point ORBIT at an agent on your own host instead.

Rule of thumb: if the agent runs where youcan install software, ORBIT can govern it. If it runs in someone else's sandbox, it can't — and doesn't need to.

Troubleshooting covers the common symptom-to-fix paths. For everything else, email support@orbitauthority.com and include the receipt ID or action ID where relevant (do not attach the .orbitproof file by email; we will request it through a secure path if needed). Status updates at /status.