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. SMS approvals are capped (currently 10 per month on free) because Twilio costs real money per message.

Guard (paid) lifts the SMS cap and 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 (SMS approval): 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 on /dashboard/agent-policy.

The action is blocked. ORBIT fails closed: if approval does not arrive within the configured timeout (default 120 seconds), the agent does not get to proceed. There is no “allow on timeout” setting and there never will be one, because that would defeat the gate.

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.

Every governed action generates a signed cryptographic receipt. 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 via SMS at the moment.

The agent itself cannot disable ORBIT. Modifications to your Agent Policy, ORBIT config, audit logging, and API keys are gated through the same approval path. If the agent could turn off the gate, the gate would not be a gate.

orbit-hook fails closed. If it cannot reach the ORBIT gateway to evaluate the action, the action is blocked, not allowed through. The agent sees the same block verdict it would see for any other denied action.

In practice the gateway is highly available, but the choice to fail closed 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. 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 can prompt you on your phone via SMS, 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.

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.