Loading...
SolonGate is a dedicated security gateway for AI tool calls. It sits between AI agents (such as Claude Code, Codex CLI, Antigravity CLI, and OpenClaw) and the tools and MCP servers they connect to, including filesystem, shell, API, and database servers. Every tool call is checked against your policy before it ever reaches the real server. This page explains, in technical detail, what happens to a tool call from the moment an agent issues it to the moment it is allowed, blocked, or logged.
A tool call is a structured request an AI agent makes to execute an action, such as reading a file, querying a database, or sending an email, through a tool or MCP server. MCP, the Model Context Protocol, is an open protocol that lets AI agents call external tools and data sources. An AI tool-call security gateway intercepts those calls and verifies each one against security policy before execution. Because SolonGate operates at the tool-call layer rather than inside the model, it can inspect the exact action an agent is about to take, regardless of which model or client produced it.
There is nothing to host. You install the CLI, set your API key, and run it. It turns on a guard that intercepts every tool call from every AI session on the machine and evaluates it against your active policy. SolonGate Cloud does not currently have a self-serve way to issue that key from your account; see the Cloud setup guide for how to get one.
$ sudo npm i -g @solongate/proxy@latest$ npm i -g @solongate/proxy@latest$ export SOLONGATE_API_KEY=sg_live_...$ solongateThe architecture is zero-trust: no request is trusted by default, and every action is verified against policy before execution. When an agent issues a tool call, the guard runs three things in order. If the policy check rejects the call, it never reaches the tool, and the block is logged.
| Stage | What it does | Threats stopped |
|---|---|---|
| Tamper protection | Keeps SolonGate's own hooks, settings, and keys read-only. | An agent trying to disable or rewrite the guard. |
| Policy check | Matches the tool call against your active policy, compiled to an OPA-WASM bundle and evaluated locally. | Unauthorized tools, disallowed files, commands, or URLs. |
| Audit log | Records every decision with its rule, reason, and latency. | Blind spots and missing forensics. |
To understand how this layered model differs from a traditional network gateway, you can compare SolonGate to API gateways.
You author policies in the dashboard. A policy is a set of ALLOW and DENY rules that match on tools, file paths, commands, and URLs, with optional permission constraints (read, write, execute, network). It runs in one of two modes: a denylist, where everything is allowed except what you block, or a whitelist, where nothing is allowed except what you permit. Rules compile to an OPA-WASM bundle that the guard evaluates locally on every call, so a decision adds no network round-trip. Enforcement is fail-closed in whitelist mode: if the bundle cannot be evaluated, the call is denied rather than waved through. When a legitimate action is blocked, you can grant a narrow exception from the audit log instead of rewriting the whole policy.
The global guard is the default, but enforcement does not have to be machine-wide. You can bind protection to exactly the surface you care about:
solongate turns on a guard that covers every AI session on the machine.solongate init inside a project and SolonGate wraps that repo’s configured MCP servers, so enforcement applies to just that codebase.npx @solongate/proxy -- node my-server.js.Every tool call, allowed or blocked, is recorded with its decision, the rule that matched, the reason, and the latency, producing a tamper-evident trail you can review in the dashboard. The audit log is also where you grant exceptions: open a blocked entry, whitelist exactly that action, and the policy recompiles so it is permitted on the next try.
The same policy model runs fully self-hosted. With the Local edition you bring up the entire stack on your own machines with Docker and zero outbound connectivity, so prompts, tool arguments, and audit logs never leave your network. This deployment adds an optional local AI Judge, a Qwen model served on vLLM, that reviews ambiguous decisions without any external call. See the docs for the full setup.
Ready to see it applied to your own setup? Book a demo and we will walk through a deployment tailored to your environment.