Your agent is about
to drop the database.

Invarix.Gate reads every tool call before it runs and stops the ones that cannot be undone. Deterministic rules, no second model in the loop, and a first run that changes nothing so you can see what it would have caught before you let it catch anything.

$dotnet add package Invarix.Gate --prerelease
How it works Pricing
10
incident-derived rules
0 ms
of model time per verdict
Observe
is the default, and blocks nothing
In process
no proxy, no egress
What it catches

Rules drawn from
incidents that happened.

Of 344 verified enterprise AI incidents, 188 involved an agent causing production harm with no attacker anywhere in the chain. Nothing was breached. Something was simply allowed to run. Below are the six shapes that keep recurring. Four more ship with them: mass sends, tools outside an agent's declared allowlist, spend ceilings, and a rule that stops an agent editing Gate's own policy, which is the one with no public incident behind it yet. The everyday commands that resemble all of these are tested just as hard, because a rule that fires on ordinary work is a rule somebody switches off.

01

Destructive SQL

DROP, TRUNCATE, and DELETE or UPDATE with no WHERE clause. A lexer strips string literals and comments first, so a DROP quoted inside a value cannot trip it and a scoped delete never does. Replit's agent wiped SaaStr's production database during a code freeze in July 2025.

02

Shell and file destruction

rm -rf outside the workspace, del /s, Remove-Item -Recurse -Force, mass deletes. Compound commands split on every separator, so a destructive tail after a harmless head still fires. The compromised Amazon Q extension shipped a wiper prompt that only a syntax error stopped.

03

Git history destruction

Force pushes, branch deletes, and filter-branch on the branches you protect. A force push to the agent's own feature branch is a routine rebase and stays quiet, because a rule that blocks that gets uninstalled the same afternoon.

04

Cloud teardown

delete-stack, terminate-instances, terraform destroy, namespace deletes, across the AWS, Azure, and GCP spellings including the s3api forms. kubectl delete pod never fires: it is self-healing, and it is the canonical false positive.

05

Credential egress

Access keys, tokens, private keys, JWTs, and connection strings heading out of the building. Scoped to outbound tools only, so writing a key to a local file is not the same event as posting it. The one rule that blocks outright rather than asking.

06

Runaway loops and ceilings

Exact repetition, retry-with-jitter, and A-B-A-B ping-pong between agents, plus call and token ceilings per run and per agent. Two LangChain agents looped for eleven days and burned $47,000 in November 2025. Breaching a ceiling ends the run, because denying one call just makes the loop retry it.

Program.cs
using Invarix.Gate;
using Invarix.Gate.Extensions.AI;

// Observe mode is the default. Nothing is blocked, everything is reported.
var gate = GateEngine.Create(GateOptions.FromYaml("gate-policy.yaml"));

// Any Microsoft.Extensions.AI pipeline. MCP tools are covered here too,
// because an MCP client tool is an ordinary AIFunction.
var client = inner.AsBuilder()
    .UseInvarixGate(gate, agentId: "checkout-bot")
    .Build();
How it works

It reports first.
You decide when it acts.

A safety tool you cannot try in production is a safety tool nobody installs. Observe mode is the default and it blocks nothing, so the first thing Gate gives you is an honest account of what your agent has been doing.

first run, observe mode
── Invarix.Gate ── observe mode ── run 018f3c… ── agent release-agent ──
  15 tool calls evaluated · 0 blocked (observe mode never blocks)
  In enforce mode, this run would have seen:

  IRREVERSIBLE (would require approval)             3 calls
    destructive-sql   db_execute      DELETE without WHERE in statement 1
    git-history       run_command     force push rewrites protected 'main'
    scope-allowlist   publish_release not in the allowlist for this agent

  HIGH-CONFIDENCE (would block)                     1 call
    secret-egress     http_post       AWS access key id in outbound body

  CUMULATIVE (would warn / terminate)
    runaway-loops     poll_job_status called 6 times, identical arguments
    limits.calls      15 / 300 tool calls (5%)

  COVERAGE (within the wrapped pipeline)
    7 tools registered · 7 routed through Gate · 0 calls executed outside

  Flip to enforce: set `mode: enforce` in gate-policy.yaml
Five things a call can be
  • allowRun it. Almost everything, almost always.
  • warnRun it, and put it in the report.
  • approveHold it until a human answers.
  • denyRefuse it, and tell the model why so it can adapt.
  • terminateRefuse it and end the run.

The most severe verdict across every matching rule wins, and there is no way to write a broad allow that quietly swallows a narrow deny. Terminate is not something a policy can assign: it is what the engine does when a loop or a ceiling breaks, because refusing one call in a loop just makes the loop try again.

  1. 1

    Install and wire one line

    One package and one builder call on the chat client or the agent. Nothing else in your host changes, and no traffic leaves the process.

  2. 2

    Run your agent as usual

    Observe mode evaluates every tool call and intervenes in nothing at all, including runaway loops. There is no mode where installing this breaks a working agent.

  3. 3

    Read what it would have stopped

    The report groups findings the way the decision is actually made: irreversible, high confidence, and cumulative. It also names what it could not see, and suggests the exact policy lines to paste.

  4. 4

    Flip one line

    mode: enforce. The same rules that reported now refuse: denied with an explanation the model can read, paused for a human, or the run ended when a ceiling breaks.

Pricing

What it costs.

Observing is free and stays free. Enforcing is one payment for the company, not a subscription that has to be defended at every renewal.

Community

Free forever
$0
free under Elastic License 2.0

Observe mode and the whole detector pack. It evaluates every tool call, reports what enforce would have stopped, and blocks nothing. Useful on its own: most teams have never seen a list of what their agent actually touches.

  • All ten detectors, at their tuned defaults
  • The run report, on the console or as markdown
  • The verdict log, one JSON object per decision
  • Coverage reporting, including what Gate could not see
  • Policy in readable YAML or fluent C#
  • Adapters for Microsoft.Extensions.AI and Agent Framework
  • MCP client tools covered through the same interception

Pair it with Invarix.Guard

Free
Community tier, Elastic License 2.0

Gate is an action firewall: it decides what an agent may do. Guard is a content firewall: it screens what goes into the model and comes back out. Different questions, same process, no overlap.

  • Prompt injection, PII, and toxicity scanning in process
  • 19 harm categories, scored by a multilingual embedding model
  • Runs on the request; Gate runs on the tool call
  • Hot reloadable custom blocklist (Professional)
See Invarix.Guard
FAQ

Questions worth
asking first.

Will this break my agent?
Not in observe mode, which is the default and which blocks nothing at all, including runaway loops. That guarantee is absolute and deliberate: a safety tool you cannot switch on in production without a change-management conversation is one that never gets switched on. You install it, run your agent exactly as before, and read a report about what would have happened. Enforcement is a separate decision you make later, on one line, once you have seen the report and tuned anything that looked wrong.
Isn't this just a prompt telling the model to be careful?
No, and that distinction is the whole product. Prompt-level prohibitions do not bind: the Replit agent deleted a production database during an explicit code freeze it had been told about in writing. Gate sits below the model, at the point where a tool call is about to execute, and it is deterministic: pattern matching, argument parsing, and counters, with no second model in the decision path. The same call with the same policy always gets the same verdict, which is a property you can test and which no LLM-based reviewer can offer.
How much latency does it add?
Microseconds, not model calls. Verdicts are pure CPU work over strings and a small amount of run state, with no network, no inference, and nothing to warm up. The comparison worth making is not against your existing latency budget but against the alternative designs: a reviewing model costs a round trip and its own failure modes, and a network proxy cannot see inside your process at all. Figures will be published from a benchmark run on a stated machine rather than estimated here.
What about false positives?
They are the reason a pack like this gets uninstalled, so they are tested harder than the catches. Roughly 80 of the 190-odd scenarios in the test corpus exist purely to prove ordinary work stays quiet: a DELETE with a WHERE clause, rm -rf node_modules inside your workspace, kubectl delete pod, a force push to your own feature branch, pagination that looks like a loop. A regression in any of them fails the build. Scoping does most of the work: the SQL detector never sees a code-review tool's arguments, so SQL quoted in a diff cannot trip it.
What can it not see?
Tool calls that do not route through it, and it says so rather than implying otherwise. Gate protects the calls in the pipeline you wrapped, and it detects, but cannot prevent, calls that executed outside it. Every report carries a coverage block for exactly that reason, including when the number is zero. Deterministic matching also has honest limits: a command hidden behind shell variable expansion, an encoded payload, a symlink out of the workspace. Those are written down in COVERAGE.md, and several are pinned as test cases so that if a change starts catching one, the documentation has to be updated deliberately rather than the product quietly claiming more than it did.
Why .NET, when everything else in this space is Python?
Because that is exactly the gap. The agent frameworks .NET teams are adopting are first-party and new, the guardrail tooling around them is Python-first and cloud-first, and the enterprises with the most to lose from an unsupervised agent are disproportionately on .NET: banks, insurers, logistics, healthcare, government. A network proxy cannot see inside an air-gapped process in one of those buildings. This runs in the process, makes no outbound calls, and needs nothing but the runtime.
Microsoft ships an agent governance toolkit. Why not use that?
You might, and the honest comparison is narrower than a feature table. That toolkit is a public preview that went from 1.0 to 5.0 in under four months and declares that its contract may break; Gate freezes its policy schema and its pack behaviour, so a new detector ships switched off in a minor release rather than changing what your build does overnight. The parts with no first-party equivalent are the argument-level rules for the documented incident classes, spend ceilings denominated in currency and enforced before the call, and a report that names its own blind spots. If you want a platform, take theirs. If you want one package that refuses dangerous calls and tells you the truth about what it missed, that is this.