From Do-Everything Platform to Correlation Engine

For most of its life, G8KEPR was trying to be a do-everything AI security platform. API protection, MCP protection, an AI gateway, checks on what the model says back. Every box on the checklist, ideally with a green tick next to it.

In September 2026 I decided that version couldn't compete, and narrowed it.

The problem with "everything"

Each of those areas is a real category, and each one already has products whose whole job is that one thing. A WAF vendor spends all day on WAF rules. A gateway product spends all day on routing and policy. When you're one person building evenings and weekends, "we do all four" doesn't read as a strength next to companies that do one. It reads as "we do all four a bit less well."

So the question stopped being what else can it do? and became what can it do that the specialists structurally can't?

What's actually different

The answer was sitting in the architecture the whole time. G8KEPR already had four checkpoints on the same request plane:

Pillar	What it checks
API Security	A WAF with nine built-in block rules, four layers of rate limiting, CSRF and an identity check on every route
MCP Security	Tool poisoning, using a SHA-256 fingerprint of the full tool definition, re-checked on every call
AI Gateway	Routing across 14 LLM providers, with a prompt-injection guard, a cost budget, and PII and secret filtering in the request path
Verification Engine	Whether the model's answer is grounded in the evidence it was actually given

A product that only sits at one of those points sees one slice of what happened. Because G8KEPR sits at all four, it can do something the one-slice tools can't: notice when signals co-occur across checkpoints and score them together.

That's the cross-pillar correlation engine, and it's now the center of the product.

Why does that matter? A single weak signal at one checkpoint is easy to shrug off. It might be noise. But an attack against an AI app rarely stays in one layer. It can start as a request, touch a tool, pass through a model and come back out as an answer. Something odd at the gateway and something odd at the MCP layer and an ungrounded answer at the end, on the same request, tells a much clearer story than any one of those alone. Seeing that story requires being present at every step.

Note

The detection underneath is deterministic regex plus classical ML, with no LLM acting as the judge. Correlation doesn't change that. It changes how the individual signals get weighed against each other.

Narrower in where it runs, too

The narrowing wasn't only about features. G8KEPR is now self-hosted and VPC-only. It deploys with Helm or Terraform, runs in-path inside the customer's own VPC, works alongside the API gateway they already have, and is designed so that zero bytes leave that VPC.

That fits the correlation story. A security layer that sees your API traffic, your tool definitions, your prompts and your model's answers is seeing a lot. Keeping all of that inside your own network is a simpler promise than asking you to trust where it goes.

Why I didn't cut the rest

The obvious move when you narrow a product is to delete everything outside the new focus. I didn't.

Here's the reasoning. The correlation engine depends on the four pillars. It can't correlate signals that nobody is collecting. The WAF rules, the MCP fingerprinting, the gateway checks and the verification engine aren't a separate product I was abandoning. They're the sensors the engine reads from.

Could I have trimmed them down to the bare minimum the engine needs? Probably, in places. But when I weighed it, keeping most of the existing work was simpler, and cost about the same as cutting it. Pulling code out of a large system isn't free. Every removal has to be done carefully, its tests updated or retired, and the result checked to make sure nothing the engine relied on went with it. That's real work, and at the end of it I'd have had a smaller product that did less.

So the change was mostly one of emphasis:

• Before: four products under one roof, each competing on its own.
• After: one correlation engine, fed by four checkpoints that happen to be useful on their own too.

What changed in practice

The code didn't shrink much. What changed is the story the product tells and the thing it's built around. How I decide what to work on next, and the scorecard I use to keep myself honest, get their own post.

The narrowing also raised a follow-up question: if the correlation engine is the valuable part, should the code be public? I answered that one twice, a day apart.