Why Security Tools Shouldn't Phone Home

Most software phones home. Usage stats, crash reports, license checks, "anonymous" telemetry that's anonymous right up until someone joins it to something else. For a note-taking app, I mostly shrug. For a security tool, I think it's the wrong default, and G8KEPR is built the other way.

I've already written about why it runs in your VPC. That post was about the deployment. This one is about the trust argument underneath it, because I think it applies to more than my product.

What a security tool gets to see

Think about the position you put a security layer in. To protect an AI application, it has to look at the prompts people send, the documents handed to the model, the tools an agent calls and what comes back, and the answers the model gives. Sometimes that includes personal data. Sometimes it includes a secret that had no business being in a prompt, which is exactly the kind of thing you want caught.

So the security tool ends up with the clearest view of your most sensitive traffic of anything in your stack. That's the job. It's also the problem.

If that tool then ships what it sees to someone else's cloud, you've done something a little strange. You've protected your data by making a copy of it somewhere you don't control. Every vendor promises that copy is handled carefully, and most of them mean it. But "handled carefully" is still a promise, and a security team's whole profession is not taking promises at face value.

Trust you don't have to extend

Here's how I frame it for myself. There are two ways to earn trust with a security product:

1. Ask the customer to believe your cloud, your staff and your processes are sound.
2. Design things so they don't have to.

The second is harder to build and much easier to explain. G8KEPR's sensors run inside the customer's own infrastructure. They report to a collector that also lives there, over mutual TLS. Nothing leaves the VPC.

If mutual TLS is new to you: ordinary TLS, the thing behind the padlock in your browser, proves the server is who it says it is. Mutual TLS makes both sides prove it. The sensor checks the collector's certificate and the collector checks the sensor's. A random process on the network can't just start talking to the collector and pretend to be one of the sensors. It's a well-worn pattern for services that should only talk to each other.

That's as much of the plumbing as I'm going to describe, and on purpose. The point isn't the diagram. The point is that the conversation stays inside your walls.

The air-gapped case

Some teams take "nothing leaves" further than a VPC. Their environments have no route to the internet at all. That's common in places where the data is sensitive enough that the network is the first line of defense.

Those teams usually get a rough deal from security vendors. Detection logic goes stale if it can't be updated, and most products assume they can reach out and fetch the latest rules whenever they like. Take away the connection and you're left choosing between a stale product and poking a hole in the air gap.

G8KEPR handles that with signed detection updates delivered offline. The update travels however that team moves approved files across the gap, and the signature lets them verify it really came from G8KEPR and wasn't altered along the way. They stay current without the product ever needing to reach out.

I like that this is the same principle as everything else, just stretched further. The product doesn't assume it gets to talk to me. It's built so it doesn't need to.

What this costs me

Honestly, it costs me visibility. A vendor that collects telemetry learns a lot for free: which features get used, where things break, what traffic looks like in the wild. I don't get that by default, and I've chosen not to.

That means I learn from direct conversations, from design partners, and from my own testing, rather than from a firehose of other people's data. It's slower. I think it's the right trade for this kind of product, and it's one I'd rather state plainly than bury in a privacy policy.

The broader point

If you're evaluating any security tool, AI-related or not, it's worth asking a boring question early: what does this send out, and to whom? Not what the marketing says. What actually crosses the network boundary, and can it be turned off?

For G8KEPR the answer is meant to be short. Nothing leaves. If that's the kind of answer you're after, g8kepr.com has more.