Security Badges

Contributing · Security

---

SolonGate Agent Security is SolonGate's open source, local first security gateway for AI coding agents. It checks tool calls against your policies before they run, with secret detection, rate limits and a local audit trail.

This repository is the Agent Security gateway. The rest of the portfolio is at solongate.com.

Everything stays on the machine. The policy is a file, the audit trail is a file, and the guard makes no network calls. No account, no telemetry.

Install and use

git clone https://github.com/solongate/agent-security.git
cd agent-security
./scripts/install.sh
solongate

Then open a new terminal. Hooks load when a session starts, so an already open one is not guarded yet.

What it looks like when it fires

A real Claude Code session: the agent reaches for a .env, the guard refuses it, and the agent says so rather than quietly working around it.

What it does

Layer	What it does
Policy rules	Allow or deny by path, command, filename or URL, scoped to READ, WRITE, EXECUTE or NETWORK.
DLP	70+ built in secret patterns plus your own, in four modes: off, detect, redact, block.
Egress	In block mode, refuses an upload whose file holds a secret, which pattern matching on the call alone cannot see.
Rate limits	A cap per minute, hour or day.
The prompt	A shim masks the outbound request body on Claude Code, which no tool call hook can reach.
Tamper protection	The guard's own state is unreachable from a tool call, and a policy in a repository cannot switch it off.
Protected paths	A path the OS itself refuses the agent, rather than a rule matched against the words in a tool call.
Sandbox	The agent's whole root is a new, minimal filesystem holding only the project; everything else is not refused, it is not there.

The CLI

solongate              the TUI: policies, audit, settings
solongate policy       list, create and edit the policy
solongate dlp          secret detection
solongate ratelimit    the rate limit

solongate policy protect <path>   lock a path, and say what the lock is worth
solongate policy protect list     what is actually holding each path, read from disk

solongate sandbox list            the boxes this machine has, and their ids
solongate sandbox 001 claude      start the agent inside box 001
solongate sandbox --explain 001   everything that is in that box

solongate run claude              start an agent with protected paths out of reach

solongate audit        browse the audit trail
solongate watch        live tail tool calls
solongate trace        what the guard saw in this directory
solongate doctor       health check
solongate repair       restore the guard, hooks and settings
solongate update       pull the newest version and reinstall
solongate range        how far an update is allowed to move
solongate range short  every commit on the branch
solongate range long   tagged releases only, reliable (the default)

Supported agents

Contributing

Go 1.26.

There is one implementation of the guard, in Go. The one JavaScript file left in the tree, packages/hooks/opencode-plugin.mjs, is a thin protocol shim with no policy logic of its own: it spawns the Go binary and translates OpenCode's plugin API to SolonGate's hook protocol, nothing more.

Two things check the decision path, and neither is a test suite. Ten end-to-end cases drive the real guard binary through protected paths, require-sandbox, agent scoping, and the .last-deny flag, asserting the exit code the guard must produce; twenty-five more drive it through every layer that refuses something. That means DLP in all four modes and on file content, the rate limit, tamper protection, the four policy constraint kinds, whitelist mode. Alongside them, Go's own unit tests cover the decisions a pure function can answer. What is left is what you ran it against by hand, and that is most of it. CONTRIBUTING.md is the rest.

Reporting a vulnerability: SECURITY.md, privately, never a public issue. CODE_OF_CONDUCT.md applies everywhere.

Licence

Apache License 2.0. See LICENSE.