What it is
An AI agent proxy is a network layer that sits between an agent process and the LLM APIs it calls. Instead of the agent connecting directly to Claude, OpenAI, or other LLM endpoints, it connects to the proxy. The proxy forwards requests to the LLM, reads every tool call in the response, inspects it against policy rules, and decides whether to return it to the agent or block it.
The proxy is out-of-process enforcement: it lives outside the agent's trust boundary, so the agent cannot rewrite a verdict Intercis has returned or tamper with the log it writes. Routing to the proxy is a configuration setting, so preventing a compromised process from calling the provider directly — around the proxy — requires network egress control alongside Intercis. This is fundamentally different from in-process SDK approaches, where the governance library runs inside the agent's process and the agent could theoretically ignore or circumvent it.
Why it matters
Proxy architecture offers tamper resistance. A compromised agent cannot rewrite or delete a verdict the proxy has already returned or logged. It can, however, be repointed at the provider directly, because routing is a configuration setting — so making the proxy genuinely unbypassable requires pairing it with network egress control that forces provider traffic through it. Out-of-process enforcement removes the in-process bypass; closing the network path is a deployment step, not an automatic property.
Proxies are also framework-agnostic. They don't care which framework or language your agent is written in — they work at the LLM API wire, not inside your agent. Intercis today implements the Anthropic and OpenAI wire formats, so a single deployment governs any agent calling Claude or an OpenAI-compatible endpoint (including open models served that way), across frameworks and languages.
How it works
The agent is configured to send API requests to the proxy endpoint instead of the LLM provider's endpoint. The proxy receives the request, forwards it to the actual LLM API, and waits for the response. When the response arrives (containing tool calls), the proxy parses it, evaluates each tool call against the deny list and policy rules, and decides whether each call should be forwarded to the agent.
If a tool call is allowed, it's returned as-is. If denied, the proxy replaces it with a structured error so the blocked call never reaches the agent runtime, and the agent continues normally. There is no live human-in-the-loop pause today — a pending verdict state exists in the schema, but no reviewer approve/deny loop is wired up.
How Intercis implements it
Intercis is deployed as an out-of-process proxy that your agents point at instead of the Anthropic or OpenAI API. No code changes to the agent, no SDK imports, no framework-specific integration. The agent's LLM client configuration changes from api.anthropic.com to your Intercis endpoint, and governance is active.
We maintain an append-only, hash-chained audit trail of interception events. We evaluate tool calls against 110 regex deny-list patterns, backed by an LLM classifier, and apply per-agent tool scopes. Policy decisions are logged on a best-effort basis — a database write never blocks the agent, and deny records fall back to a local spool if the write fails — and records are queryable from the dashboard and exportable to CSV from the event view.
Related terms
- Tool Call Interception — The process of inspecting tool calls at the proxy.
- AI Agent Governance — The broader discipline the proxy enables.