What is AI Agent Governance?

AI agent governance is deciding, before a tool call runs, whether the agent is allowed to make it, and keeping a record of the decision.

Chatbot safety filters text. This filters actions. It sits between the agent and the model API, and it reads the tool call before the agent runs it.

Why AI agent governance matters right now

This is not the chatbot threat model. The agent is yours, the credentials are yours, and the goal you gave it is the problem. Somebody asked for something vague and the agent widened its own scope trying to deliver it.

In March, a Claude agent began deleting production files. The account is ours and there is no public report to check it against. Not because it was hacked. Not because of a prompt injection. Because it had filesystem access, it was given a goal to "clean up stale artefacts," and it reasoned its way into a series of increasingly broad deletion commands. The SIEM caught it six minutes later, after real damage had occurred.

Nothing in that environment stopped the agent before the first file went. That incident is why this product exists. The category had other reasons.

Four things have to be true, and we have three of them

If any one is missing you have monitoring, not governance. The four are defined on the glossary entry for agent governance; this section is what each one costs to build and which one we did not build.

Interception before execution

Each tool call the agent attempts passes a control point before it executes, rather than being reported to a dashboard after it has.

That means sitting between the agent process and the LLM API it uses. When the model generates a tool call, the proxy reads it, runs the rules over it, and decides to forward or block before the agent's code runs the command.

Without this, you're relying entirely on post-facto monitoring. The action has already executed, damage may have already occurred, and the best you can do is detect it and roll back.

A policy engine

A governance system needs a way to describe what actions are permitted in what contexts that a security team can manage without becoming framework experts. Good policy can deny a destructive shell command while allowing a read, allow a query against the production replica but deny writes to the primary, and scope filesystem access to named directories.

Ours does some of that and not the rest. The rules are regexes in a Python file we maintain: 111 of them at commit 87ccd47, counted by the command in the tool-misuse post, and the count moves with every merge. Nothing in the repository versions a policy. What a customer controls is an exclusion, scoped to an agent or to a literal substring, carrying a reason of at least twenty characters and an expiry that cannot be left open.

An audit trail the agent cannot reach

Every decision, allow or deny, is written to an append-only log, on a best-effort basis, at the moment it is made. The row carries the agent identity, the action attempted, the policy that matched, and the verdict.

Best-effort is the honest word. The write never blocks the decision: enforcement happens in line, and a deny row that fails to insert is spooled to local disk and replayed when the database comes back. Nothing is dropped silently and nothing is guaranteed synchronously.

The log is for two readers. Forensics, because you have a record of what the agent attempted and in what order. And compliance: if a regulator asks what the agent did, this is the record you would show.

The log has to be out of the agent's reach. If the agent process is compromised, it should not be able to edit the trail it does not control.

Human escalation, which we do not have

Some actions are neither clearly allowed nor clearly denied. A complete system routes those to a person, either holding the call for approval or putting it in front of a reviewer.

Intercis has the first three. It does not have the fourth: the audit table keeps pending as a verdict and no reviewer loop is wired to it. By the rule at the top of this section that makes Intercis an enforcement and audit layer, not a complete governance framework, and the pilot is sold as the former. What you get instead is observe mode, which records the same verdicts without blocking, so you can read a week of your own traffic before you turn enforcement on.

In-process vs out-of-process enforcement: why architecture matters

There are two technical approaches to building AI agent governance: in-process and out-of-process.

In-process enforcement (SDK approach)

The team building the governance tool provides an SDK, a library that the agent developer imports and adds a few lines of code to call. The SDK runs in the same process as the agent, intercepts tool calls, and enforces policy from inside the agent's trust boundary.

Advantage: simple to integrate, works with any framework, doesn't require network configuration.

Disadvantage: the agent process controls the SDK it's being governed by. If the agent is compromised or misbehaving, it can disable, bypass, or never call the SDK. For an enterprise security team, this is governance by suggestion, not governance by control.

Out-of-process enforcement (proxy approach)

The agent is configured to point its LLM API client at a proxy endpoint instead of directly at the Anthropic or OpenAI API. The proxy sits in the middle, reads every response from the LLM, inspects each tool call block, and decides whether to forward or block before returning the response to the agent.

You change one line of configuration: the base URL the agent's client points at. The proxy runs outside the agent process, in front of the provider's HTTPS endpoint. It is an application proxy, not a network-layer control, and routing to it is a configuration setting.

Advantage: the agent process cannot switch off an enforcement point that runs outside it. It can still repoint its own base URL, which is why this wants network egress control beside it. It works across any framework, any language and any agent codebase, because the proxy only reads the model response format. Running it inside your own VPC is an Enterprise-tier intention and has not shipped; what you can run today is hosted by us.

Disadvantage: requires network configuration.

Out-of-process removes the in-process bypass: the code being governed is not the code doing the governing. Routing to it is still a configuration setting. An in-process guard is fine for an internal safety check and weak as a production security control, because the process it runs in can turn it off.

Who asks for this

We have no survey and no customer list, so there is no honest section here about buyer types. The question the product was built around: if the agent does something it should not, what stops it before it runs, and what can you show afterwards. The checklist below is how to ask it of anyone selling you a governance tool.

How to evaluate AI agent governance tools

Six questions to put to a vendor. Ours are answered underneath each one, including the two we lose.

How much has to change in the agent? Does it want you to change agent code, import an SDK or restructure your tool definitions? Each of those is a redeploy every time a rule changes.

Ours: the base URL the client points at. That is one line of configuration, and the agent does not know it is being governed.
Is the audit log outside the agent's reach? If the log lives in the agent's database or the agent's cloud account, the agent can edit it. A log the agent process cannot write to is the baseline.

Ours: rows go to a table the agent holds no credential for, append-only for every client role and hash-chained per tenant. The write is best-effort: a deny row that fails to insert is spooled to disk and replayed, and the block itself never waits on it.
Does it enforce before execution? Does the system take the tool call out before it runs, or does it alert after? Pre-execution is governance. Post-execution is monitoring.

Ours: the model's tool_use block is replaced with a synthetic assistant message before the agent runtime sees it. The response, before and after.
Is it framework-agnostic? Does it read a wire format, or does it require a particular agent framework? A tool tied to one framework is a tool you replace when you change frameworks.

Ours: the Anthropic and OpenAI wire formats, across four routes. An agent that speaks neither is outside it, and a tool a hosted MCP server runs for the model has already run by the time the response reaches us, so we observe it and do not govern it: one observe row, never judged or blocked. This is one of the two we lose.
Can it run inside your own network? Some buyers need agent traffic to stay inside their own infrastructure.

Ours: not today. Self-hosting is an Enterprise-tier intention, and the 90-day pilot is hosted by us.
Can your security team read the policies? Policy-as-code should read like policy, not like code.

Ours: the rules are regexes in a Python file we maintain, and they do not read like policy. What you write is an exclusion, scoped to an agent or to a literal substring, with a reason and an expiry that cannot be left open. This is the other one we lose.

Intercis loses two of the six: the fourth and the sixth.

What Intercis does

Intercis is an out-of-process proxy that sits between your agents and the LLM APIs they use. When an agent calls Claude or OpenAI, the request goes through Intercis. We read the response, inspect each tool call block, run the rules over it, and decide to forward or block before the agent executes anything.

Every decision, allow or deny, is written to an append-only log, hash-chained per tenant, on the best-effort basis described above. That makes an edit detectable, not impossible: anyone holding database-owner rights can rewrite rows and recompute the hashes, or drop the newest rows, and nothing outside the database anchors the chain to catch it. On a deny it removes the tool call from the response and writes the row. The audit table keeps a fourth verdict, pending, for a call that would need human review, and no reviewer loop is wired to it today.

You point your agent at our endpoint instead of the provider endpoint. That is one line of configuration, and it gets you:

Interception before execution: each tool call that crosses the wire is judged before it runs.
Rules and exclusions: the rules are ours, regexes we write and maintain. What you control is an exclusion, scoped to an agent or to a literal substring, with a reason and an expiry that cannot be left open.
An audit trail the agent cannot reach: each governed action is logged, timestamped and hash-chained, on a best-effort basis.
No escalation: the audit table keeps pending as a verdict for a call that would need review, and no reviewer loop is wired to it today.

Nobody is running Intercis in production yet. The 90-day pilot is the first deployment, and the price is on the pilot page. Pointing an agent at the proxy is one line of configuration and your agent code does not change. Latency does: a streamed response is buffered in full before it is judged, and we publish no figure for it.

Starting with governance

If your agents hold infrastructure access, credentials or customer data, this is an operational question now rather than a roadmap one.

Three questions:

What would happen if this agent made a mistake with the tools it has access to?
How would you prove to a regulator, an auditor, or your board that you have controls in place to prevent that?
If the agent did something it shouldn't have, what audit trail would you show?

If you cannot answer all three, the control you are missing runs before the tool call, not after it. Intercis answers the first two. The third, the part where a person rules on an ambiguous call, is the one it does not do.