SolonGate Logo
  • Pricing
  • Docs
Book a Demo

Loading...

How SolonGate Works

SolonGate is a dedicated security gateway for AI tool calls. It sits between AI agents (such as Claude Code, Gemini 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.

What is an AI tool-call security gateway?

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.

Turn it on with one command

There is nothing to host and no key to copy. You run a single login command. It opens your browser to authorize the device against your dashboard, then turns on a guard that intercepts every tool call from every AI session on the machine and evaluates it against your active policy.

solongate login

To stop enforcing later, run solongate logout, which removes the guard and restores your previous settings.

What happens on every tool call

The 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.

StageWhat it doesThreats stopped
Tamper protectionKeeps SolonGate's own hooks, settings, and keys read-only.An agent trying to disable or rewrite the guard.
Policy checkMatches the tool call against your active policy, compiled to an OPA-WASM bundle and evaluated locally.Unauthorized tools, disallowed files, commands, or URLs.
Audit logRecords 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.

How the Policy Engine enforces rules

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.

Scope it to a machine, a repo, or a single server

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:

  • Whole machine. solongate login turns on a guard that covers every AI session on the machine.
  • A single repository. Run solongate init inside a project and SolonGate wraps that repo’s configured MCP servers, so enforcement applies to just that codebase.
  • One server. Wrap an individual MCP server with the proxy and point the agent at it: npx @solongate/proxy -- node my-server.js.

The audit log

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.

Air-gapped and on-premise

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 Local / air-gapped guide for the full setup.

Frequently asked questions

Ready to see it applied to your own setup? Book a demo and we will walk through a deployment tailored to your environment.

SolonGate Security Gateway for AI Tools

Security gateway for AI tool calls

Product

  • Pricing
  • How It Works
  • Comparison
  • News
  • About
  • Book a Demo

Legal

  • Privacy Policy
  • Terms of Service
  • Cookie Policy
  • Subprocessors

© 2026 SolonGate. All rights reserved.