What G8KEPR does not do

On a fresh install from the quick start, about thirty distinct controls refuse a request: body-size limits, an identity check on every route, four layers of rate limiting, a WAF with nine built-in block rules, CSRF protection, and the AI gateway and MCP checks marked ENFORCING on the homepage. The MCP tool-call path is default-deny.

Much of the rest is advisory by design, and some controls that can block ship switched off. Threat-detection blocking is off in the shipped configuration, and the gateway guardrail policies log rather than block. You decide, control by control, what enforces in your deployment.

On a 2,580-sample held-out set it was never trained on, the detector catches 78.8% of attacks (recall 0.788), is right 85.7% of the time when it flags something (precision 0.857), and flags 3.12% of benign traffic. About one attack in five gets past the detector on its own. The enforcing controls listed above do not rely on it.

The inline detection pipeline measured 27.65 ms at the median (p50) on the production node.

Output-side scanning covers non-streamed responses. Streamed completions skip most of it.

Grounding verification runs only when a request supplies the sources the answer is supposed to rest on. Without sources there is nothing to check the answer against, so it does not run.

Every pillar publishes its findings to one internal threat event bus, and a correlator scores findings that occur together. Today it joins findings that share a correlation ID, which in practice means findings raised on the same request.

Joining one principal’s activity across separate requests, the multi-stage campaign described on the homepage, is being built now. This page will say so when it ships.

G8KEPR is self-hosted in your own VPC. You operate the PostgreSQL database, Redis, backups and upgrades, and the backend image carries a CPU build of PyTorch for the ML detector, so it needs real memory.

Plan for the same operational work as any other stateful service you run.