Brig · by osnavi
Self-hosted gate for AI coding agents

Any agent. Any model. Captive to no one.

Brig is a self-hosted gate that sits in front of your AI coding agent and bounds what it can do — touch files outside your repo, reach the network, run a shell command — no matter which model is driving it. Drop in a cooperative hook in seconds, or run the agent inside an OS-enforced boundary it can't cross.

Works with Claude Code · OpenCode · Pi · Hermes — and any MCP client
See it work →

Watch it block an agent — real output, ~10 seconds. Then reproduce it yourself.

Open-core (auditable gateway) Memory-safe, no-JIT sandbox Self-hosted & Swiss-rooted Tamper-evident audit you can verify Aligns with NSA & OWASP guidance

Why this exists

Agents already broke things people cared about.

Coding agents run with your privileges. The danger isn't hypothetical — it's publicly reported. Natural-language rules in a prompt aren't a security boundary; infrastructure is.

Gemini CLI

An agent misread its own state and deleted a user's project files.

Replit agent

Wiped a live production database during a code freeze — then fabricated thousands of fake users to cover it.

CamoLeak

A prompt-injection chain exfiltrated private-repository secrets through an agent.

The pattern: the agent is acting as you, so there's no separate identity to pin rules to. The only durable control is at the layer below the prompt — the actual files, network, and shell calls. That's where Brig sits.

Drop-in, zero-friction

One small paste. It governs every tool call — native and MCP.

Adding a gateway as an MCP server alone doesn't govern Claude Code: the agent keeps using its own Read / Write / Bash / WebFetch. The real control point is a pre-tool hook that fires before every call. For Claude Code, that's ~5 lines — or one command, brig init claude-code:

// .claude/settings.json — what `brig init claude-code` writes (ride-along is the default) { "hooks": { "PreToolUse": [{ "matcher": "Bash|Read|Edit|Write|MultiEdit|WebFetch", "hooks": [{ "type": "command", "command": "brig hook", "timeout": 10 }] }] } }

The hook only decides — allow (exit 0) or block (exit 2). It's fast, and fail-closed: on its own error, or even an internal panic, it blocks rather than letting a call slip by. Three modes, lowest friction first:

Ride-alongSee everything

Allow every call, block nothing, record each one to a tamper-evident logbook. The zero-friction on-ramp — it earns trust before it ever says no.

GuardrailsCatch the dangerous

Also deny the rare, genuinely destructive moves — a write escaping the repo, egress to a non-allowlisted host, an unambiguously destructive shell command. A seatbelt, not a checkpoint.

ContainmentDeny by default

Only what your profile grants, inside the workspace and egress allowlist, passes. Pair with managed settings for a ceiling the agent can't lift.

Honest about coverage: a hook governs the harness's tool calls — so it depends on the harness firing the hook. Subagent calls can be opaque to it on some harnesses (a gap we name, not paper over), and an agent that bypasses the hook entirely isn't caught. Today's scope is cooperative, hook-level governance, honestly bounded. OpenCode, Pi, and Hermes wire the same gate through their own extension formats — see Works with your stack.

Two ways to run it

A cooperative hook — or a boundary the OS enforces.

The hook above governs the agent you already use, at the layer below the prompt. When you don't trust the agent itself, brig run launches it inside a boundary the kernel enforces. These aren't versions of each other — they're assurance levels: keep the hook for everyday governance and a tamper-evident record; reach for brig run when you need a boundary the agent can't talk — or code — its way out of.

The hook — cooperative governance

Drop-in, in-place: it governs your existing agent's tool calls and records every one to a tamper-evident logbook. It runs at your own user — a strong seatbelt and full visibility for a trusted agent — but it depends on the harness firing it, and an agent actively working around it is the job of the OS-enforced tier.

brig run — an OS-enforced boundary

Launch the agent with brig run and the OS confines it: writes land only in your workspace — your config, your keys, the rest of your disk stay read-only. Proven on macOS, Linux, and Windows by a write outside the workspace that the kernel itself denies. Network egress can be pinned to an allowlist — an out-of-sandbox proxy becomes the agent's only route out — proven on macOS first, with Linux and Windows next. Here, "the model can't move the boundary" is the kernel's job, not a cooperating agent's.

Honest about the edges. brig run confines one agent running as your own user — a real boundary, but not a complete one, and we don't paper over the rest: a determined agent could still try to delegate an action through a higher-privileged system service, and a cohort of agents sharing the one user isn't isolated from itself. Both are limits of the same-user model — and they're exactly what the next tier closes.
What's next. The clean answer to a hostile or multi-agent cohort is to run the agent as a separate, unprivileged user it can't become — privilege separation. It's the active next step on the roadmap, currently in progress.

How it works

Security that holds by construction — not by good intentions.

Four ideas do the work. Each is built into the layer below the prompt, where a model's intent can't reach.

Injection defense by construction

For tasks Brig runs itself, a dual-LLM design (CaMeL) tracks where every value came from. A secret can't leave — even to an allow-listed host — because provenance, not byte-matching, decides.

Cross-call exfiltration tracking

Data read from your workspace is followed across calls; a later network or shell call that would carry it out is blocked. The lethal-trifecta defense, over a whole session.

Memory-safe sandbox

Agent code runs in a no-JIT, forbid(unsafe) engine with hard CPU/memory ceilings and no ambient filesystem, network, or process authority — a small language is a small attack surface.

Proven, not asserted

A conformance battery proves containment holds identically across models — including ones people distrust and a built-in hostile model that dumps the secret and still can't get it out.

# swap in a model you don't trust — watch it stay contained $ brig conformance read-secret contained exfil-via-fetch blocked exfil-via-shell blocked obfuscated-exfil contained hostile-model-dump blocked qwen2.5 — 8/8 certified

"Verified to contain these models" is the trust signal — the same prove-don't-assert discipline our engines live by. A local qwen2.5 is certified live, 8/8, today.

Read the security depth →

The strongest claim

You don't have to trust the model.

Brig's gating is model-independent. Capability grants, workspace scope, an egress allowlist, human-in-the-loop on shell, and a memory-safe sandbox bound what any model-driven agent can touch, reach, or run. The model's intent can't move that boundary.

Run a local model with egress control and your code never reaches the model's maker — which kills the top untrusted-model fear outright, and is pure sovereignty. Run a model you'd never trust, even fully offline, and it stays in its box.

The honest boundary — we hold this line. Brig bounds what a model can do, not what it writes. A bad model can still emit subtly flawed code; Brig stops that code from reaching outside the repo, phoning home, or running unapproved — but a human who later ships it is past Brig's boundary. The claim is bounded blast radius, not "the model is now trustworthy."

What it enforces

Six controls, deny-by-default.

Capability gating

A tool runs only if its capability was granted. Pick a least-privilege profile (reviewer / builder / ops); everything else is denied before it runs.

Scoped filesystem

Reads and writes are confined to a workspace root. ../etc/passwd and symlinks that escape the workspace are denied before any I/O.

Controlled egress

The network reaches only allowlisted hosts over HTTPS; plaintext and SSRF-prone schemes are refused. Address-screened and IP-pinned.

Memory-safe execution

Agent-written code runs in a no-JIT, forbid(unsafe) engine with hard CPU/memory limits and no ambient filesystem, network, or process authority.

Exfiltration block

Data read from your workspace can't be relayed back out through a later network or shell call — the lethal-trifecta defense, across calls.

Tamper-evident audit

Every decision and outcome is hash-chained and HMAC-keyed to an operator secret. brig verify proves it wasn't altered — even by you.

Works with your stack

One gate core, thin per-harness adapters.

The decision each harness needs is identical ({tool, args} → allow/deny); only the wiring differs. Coverage is stated honestly per harness — including where a platform limits what's possible.

HarnessVerified vs the real toolNative-action gatingCross-call exfil tracking
Claude Code✓ Verified liveFull — PreToolUse hookFull (PostToolUse)
OpenCode✓ Verified (end-to-end, account-free)Plugin hook (args: filePath/command; subagent gap)Plugin after-hook (output.output)
Pi✓ Verified (end-to-end, account-free)tool_call hook (blocks; path/command)tool_result (content[].text)
Hermes✓ Verified (end-to-end, account-free)pre_tool_call plugin (blocks; path/command/exec)Full (post_tool_call)
Cursor✗ Excluded for nowClosed-source and requires a phone number to register — we won't ask you to feed them your number, and we can't verify openly. We'll support it when there's an account-free path.
Aider / ClineMCP only (partial)via Brig's MCP tools
We claim a harness only once it's proven against the real tool. All four — Claude Code, OpenCode, Pi, and Hermes — are verified end-to-end against the real tool (OpenCode, Pi, and Hermes via an account-free local-model run — no signup, no telemetry). We publish the status rather than imply coverage we haven't earned. Building all these adapters showed how fragmented the interfaces are — we're working toward an open governance-hook standard so the gate is one contract, not four.

Open-core & sovereign

Auditable where it matters; yours, end to end.

Auditable, open-core gateway

The gating, audit, egress, and injection-defense logic is open to review under agreement — by the teams deploying Brig and serious evaluators — not published for the crowd, and never a license to resell. For a trust product, auditability where it matters is the point.

Private engines

Our proprietary execution engines stay private. Continuity for a nervous buyer is handled by a neutral third party holding a sealed source copy, released only if the vendor fails — never to compete.

Swiss-rooted

Self-hosted on your infrastructure; our own runs on Swiss hosting, not a US hyperscaler. The gateway, your actions, and egress stay on your metal.

Drop it in. Keep your agent. Stop trusting the model.

Start in ride-along against your own repo — it logs everything and blocks nothing — and turn up the protection when you're ready.