We turned on automatic enforcement in production six months ago. Here's what real-world attacks actually look like, how often a legitimate user got caught, and why enforcement has to live next to the data.
When we shipped auto-ban in late 2025, the question wasn't whether it would stop attacks. The question was whether it would stop only attacks. Automatic enforcement that occasionally locks out a paying customer is a support problem disguised as a security feature. Six months and roughly 50,000 blocked requests later, we have an answer.
Every team that considers automatic blocking runs into the same objection, and it's a fair one: what if it's wrong? Clocks drift, networks drop, apps get upgraded in the middle of a request. Real users produce messy traffic. Tune enforcement too tight and you punish them; tune it too loose and it catches nothing.
Most products answer that fear by retreating to alerts. The rule fires, someone gets an email, and the attacker keeps going. We wanted to show that the trade-off isn't real — that enforcement can be strict with attackers and invisible to everyone else.
The data is surprisingly clean. The overwhelming majority of devices never trigger a single security failure in their entire active life. Most of the rest have a handful of harmless hiccups that never come anywhere near enforcement. The devices that do get stopped behave in a way no legitimate client does.
We've seen four recurring patterns. None of them are clever. All of them are stopped fast — and each one maps to an outcome our customers can rely on.
Before launch, engineering and security disagreed about how forgiving enforcement should be. Engineering wanted room for messy real-world clients. Security pointed out that every extra failure tolerated is more probing an attacker gets for free. Instead of settling it by argument, we settled it with our own production traffic — and the answer turned out to satisfy both sides.
That's the part that doesn't transfer from a blog post. The policies we run are backed by what actually attacked our customers, and they keep being re-checked as attackers adapt. Which is also why the specifics aren't something we publish.
The partner integrations that tripped enforcement taught us as much as the attacks did. Because every blocked request is recorded against a specific device, client and reason, diagnosing each one took minutes rather than a back-and-forth over days. A false positive resolved in minutes costs a little goodwill. One that takes days costs a partner.
We could only get here because the platform that decides who to trust is the same platform that sees every failure. There's no black box upstream saying a request looked bad without saying why.
Teams that buy threat detection as a separate product give up that leverage. They get rules someone else tuned against someone else's traffic, and the result is predictable: too aggressive and legitimate users get blocked, too permissive and nothing new gets caught. Enforcement has to live where the trust decisions live.
The honest version of 'secure by architecture' is this: good defaults don't come from reading about them. They come from running enforcement against real attacks and real customers, and holding it to the standard of stopping one without bothering the other. Six months in, that's the standard Enravo Core meets. If automatic enforcement has felt too risky for your product, talk to us about what it looks like when it isn't.
Recent articles on platform, security, and engineering.
A platform is a claim until something real runs on it. Rakton is the first product family built on Enravo Core — and building it changed Core more than we expected.
Read moreAssembling a stack from best-in-class services is the sensible default. Here is the specific reason we did the unreasonable thing instead — and what it cost.
Read moreA tablet on a shop counter is shared, public, and occasionally offline. Designing for it forced us to rethink what device trust means when the device is not personal.
Read more