What Intercis does not cover

Being in-path is a setting, not a law

Your agent reaches us because its base URL says so: pointing ANTHROPIC_BASE_URL at our endpoint is what puts us in the path, and a compromised process can point it back and call the provider directly. Pair Intercis with an egress rule that blocks direct calls to api.anthropic.com and api.openai.com from the network your agents run on. With that rule we can claim tamper resistance. Without it we are a control a compromised process can walk around.

Codex, on an OpenAI API key or signed in with ChatGPT, can be governed on either configured route. Direct calls to chatgpt.com or api.openai.com stay outside Intercis; block both.

What we are doing about it: By design. Being in the path resists tampering only alongside an egress rule on your own network, and that rule is yours to set.

Only the provider API wire is visible

We judge the tool calls that cross the Anthropic and OpenAI API wire. A tool the provider runs on its own servers has already run by the time the response reaches us: hosted MCP calls, web search, file search, code interpreter and image generation. On the OpenAI side those are the item types in _HOSTED_ITEM_TYPES in apps/proxy/openai_routes.py, which our extractor keeps out of the calls it judges. Each one writes an audit row with the verdict observe, naming the tool, and that is all: no rule or classifier reads it and nothing stops it. If your agents rely on hosted MCP servers, you can see what they did there, and we cannot stop any of it.

What we are doing about it: Nothing is scheduled. A hosted tool call is observed, not governed: it writes one observe row and is never judged or blocked, and no governance of hosted tool calls is planned.

Streaming is buffered before anything is judged

To judge a tool call we have to see all of it, so a streamed response is buffered in full, reassembled and judged before any of it reaches your agent. That adds latency equal to the length of the stream before your agent sees its first token, and on an interactive coding agent a person is waiting through it. We publish no latency number.

What we are doing about it: By design. The wait is the price of judging a call before it is delivered rather than after.

We are a new place your prompts pass through

Putting us in the path adds a trust boundary, and your prompts and tool inputs cross it in plaintext. Relayed traffic goes upstream on your own provider key, which we do not store, but the classifier call runs on an Intercis credential and carries the tool name and the full tool input to Anthropic or OpenAI under our account rather than your agreement with them. We run the service hosted; there is no self-hosted build you can buy today.

What we are doing about it: Undecided. How a self-hosted build would be licensed has not been decided, and nothing is scheduled.

The provider routes are ours to maintain

We speak three routes today: Anthropic's POST /v1/messages, and OpenAI's POST /v1/responses and POST /v1/chat/completions. A new provider, or a new shape at one we already speak, is engineering work on our side, and until it is done that traffic is not governed. Per-provider route maintenance is ours.

What we are doing about it: By design. It is the standing cost of sitting outside your agent process, and it is ours for as long as the product exists.

If we are unreachable, your agents stop

We are in the path, so a call that cannot reach us does not reach the provider either. Nothing queues and nothing routes around us. The proxy is one hosted service behind a health check on /health, and it restarts on failure. There is no second region, no replica and no failover in anything we ship, and we publish no uptime number and no SLA, because nothing in our code measures one. With the egress rule from the first cost in place you cannot point the base URL back at the provider and keep working: that is the trade you make when you close the bypass.

What we are doing about it: By design. We sit in the path so that a denied action cannot reach your agent, and a control in the path that let traffic through while it was down would be a way around itself.

The classifier fails open

When no deny rule matches, an intent classifier reads the call. When the classifier cannot answer, the call is allowed on the default setting and stopped on fail closed. The deny rules still enforce underneath it, the row records that the classifier was unavailable and why, and the proxy pages us once more than 5% of a rolling window of the last 200 classifier calls came back unavailable.

What we are doing about it: Built: a per-tenant setting to fail closed, so a call the classifier cannot answer is stopped and recorded as denied. The default stays fail open, no tenant has switched, and switching is a request to us until the dashboard carries the toggle.

The audit log can have holes

A database outage stops the log, not the blocking. Deny rows wait on the proxy's own disk and go in when the database is back; an allow or observe row that fails to insert is gone, and a row that was never written leaves no break in the chain, because the next row links to the last one written. A pilot runs in observe, so in month one every row is in that set.

The hook we ship to managed machines blocks a matching action on the machine itself and keeps no record of the calls it allows, so those calls do not appear in the dashboard.

What we are doing about it: No change is scheduled. Blocking never waits on the audit write, and that is why a write can fail.

The audit chain has no anchor outside our database

Every audit row carries a SHA-256 hash over its own fields plus the previous row's hash, and nothing outside our database records any of those hashes. So the chain catches one shape of change: an edit, or a row deleted from the middle, that did not also recompute every hash after it, because the next row's link stops matching. Somebody holding our database credentials who recomputes the chain, drops the newest rows, or appends rows hashed correctly is not caught, and the verifier we publish prints ok on what is left. The dashboard export carries eight columns and neither hash is one of them, so you cannot keep your own copy of a hash of ours to check a later one against. The chain is evidence against an editor who does not hold our database credentials. It is not evidence against us.

What we are doing about it: Planned, not built: signed, hash-chained receipts and a verify route that answers, so a hash can be checked outside our database. There is no date.