G8KEPR
What G8KEPR Is, in Plain English
Part 1 of the thread Building G8KEPR
- What it is
- AI security platform
- My role
- Founder and sole developer
- Built with
- Self-hosted
- Helm
- Terraform
- G8KEPR is a runtime security layer for AI apps: it sits in the path of every request and checks it on the way through.
- It watches four places at once: your APIs, your MCP tools, your calls to LLM providers, and the model's answers.
- It runs inside your own VPC, self-hosted with Helm or Terraform, and sends nothing out.
- This post is the overview. The rest of the series goes pillar by pillar.
People ask what I'm building, and I've gotten the answer down to one sentence. Then they ask a second question, and the sentence falls apart. So this post is the longer version, written for someone smart who doesn't live in security all day.
G8KEPR is my security startup. It's a Delaware C-Corp I set up through Stripe Atlas, and I'm the only one building it, on evenings and weekends. The product lives at g8kepr.com.
The problem
A few years ago a typical web app had one obvious front door: its API. You put a firewall in front of it, rate-limited it, checked who was calling, and that covered most of the ground.
AI apps have more doors. A single request from a user might:
- Hit your own API
- Get handed to a large language model (an LLM), often from one of several providers
- Let that model call tools through MCP, the Model Context Protocol, which is the standard plumbing for letting a model use outside services
- Come back as an answer the model wrote, which your app then trusts and shows to someone
Each of those hops is a new way in. A prompt can carry instructions the user was never supposed to be able to give. A tool can describe itself one way on Monday and another way on Thursday. A model can answer confidently with something it made up. The old tools weren't built to look at most of this, and the new tools usually only look at one piece of it.
What G8KEPR does
The short version from the site: "A runtime security layer for AI apps — API, MCP, gateway, and model-output checks on one request plane, running inside your own VPC."
Unpacked a bit. Runtime means it works on live traffic, not on your code before you ship it. In-path means requests actually flow through it, so it can stop something rather than just write it down afterward. And one request plane means all four kinds of checks see the same request, which matters more than it sounds.
The four pillars
| Pillar | What it guards | What it checks |
|---|---|---|
| API Security | Your app's endpoints | A WAF with nine built-in block rules, four layers of rate limiting, CSRF, and an identity check on every route |
| MCP Security | The tools your model can call | A SHA-256 fingerprint of each tool's full definition, re-checked on every call, to catch tool poisoning |
| AI Gateway | Your calls to model providers | Routes 14 LLM providers, with a prompt-injection guard, a cost budget, and PII and secret filtering in the request path |
| Verification Engine | The model's answer | Checks the answer against the evidence the model was actually given, and flags ungrounded or fabricated output |
(A WAF is a web application firewall: a filter that looks at web requests and blocks the ones that look like attacks.) Each pillar gets its own walkthrough in Four Checkpoints on One Request.
The part that's actually different
Here's the honest bit. G8KEPR started out as a broad AI security platform trying to do everything. In September 2026 I looked hard at that version and concluded it couldn't compete. Lots of companies do a slice of this well.
So I narrowed it to the thing I think is genuinely different: a cross-pillar correlation engine. It scores signals that show up together across all four checkpoints. One slightly odd prompt might be nothing. A slightly odd prompt, plus a tool whose definition just changed, plus an answer that isn't backed by any evidence, all on the same request? That's a story, and you can only see it if one system is watching all four places at once.
I kept most of what I'd already built instead of cutting hard. Keeping it was simpler and cost about the same, and the pillars are exactly what feed the correlation engine.
How it decides
Detection is "deterministic regex plus classical ML, no LLM-as-judge." In other words, it doesn't ask another AI model whether a request looks bad. The median detection time is 4.6 ms. I wrote up why I went that way, including the numbers and what they miss, in No LLM-as-Judge.
Where it runs
In your own VPC (virtual private cloud, the walled-off slice of a cloud provider that belongs to you). You deploy it yourself with Helm or Terraform, it sits in the request path, and it works alongside whatever API gateway you already have. No app rewrite. By design, 0 bytes leave your VPC, and there's no per-token bill. More on that in Why It Runs in Your VPC.
Note
Founder pricing starts at $399 a month, with a 30-day free trial (extendable to 90) and no credit card. I'm also looking for a few design partners, so if you work in security and this sounds like your problem, g8kepr.com is the place to start.
It's still being built. I'd rather say that plainly than dress it up.
- Four Checkpoints on One Request: The G8KEPR PillarsG8KEPR
- MCP Tool Poisoning, and Why G8KEPR Fingerprints Every ToolG8KEPR
- No LLM-as-Judge: Why G8KEPR Uses Regex and Classical MLG8KEPR
- Why It Runs in Your VPC (and Nothing Leaves)G8KEPR
- Building a Security Startup by MyselfG8KEPR
- From Do-Everything Platform to Correlation EngineG8KEPR
- Open Source for About a DayG8KEPR
- A Scorecard Instead of a Vanity MetricG8KEPR
- How I Build with Three Claude Code Agents at OnceG8KEPR