Problem definition, an architecture I got wrong the first time, and an honest read of a modest launch.
The problem I was actually trying to solve
When I started building agent tooling, the assumption I began with — and the one most writing on this subject still begins with — was that the risk in AI-assisted development is the code the model writes.
That is one of four problems, and not the hardest one.
Once an agent is in your loop, traffic runs in both directions. You are sending it repository contents, environment values, terminal output pasted in during debugging, occasionally a config file with a live credential in it. And it acts on what comes back: writing files, running commands, invoking tools. Traditional application security was not built for any of that. It covers neither prompt injection, nor unsafe tool calls, nor data leakage on the outbound path, nor actions taken with no record that they happened.
That last one is the quiet problem. An agent can do something consequential and leave nothing behind that tells you it did.
So the product question was narrower than "is AI-generated code safe." It was: can you put a checkpoint between the agent and the model, and enforce policy on both directions of that traffic?
The constraint that decided the architecture
I am not a software engineer. I am a commercial writer who has been building with AI assistance since 2024. That constraint eliminated entire categories of solution before I evaluated a single one.
A native plugin per IDE meant four codebases, four release cycles, four extension APIs. Not viable for one person.
A hosted service meant holding other people's prompts and API keys on infrastructure I would then have to secure — an absurd position for a security product.
What was left was a local gateway. It is the least glamorous option and, for a solo builder, the only defensible one. Every agent I cared about already lets you override the provider base URL, and that configuration surface is stable.
IDE / Agent → Cencurity Gateway (127.0.0.1:38180) → LLM Provider
Requests pass outbound through a policy engine that detects and masks sensitive data. Responses pass inbound through a scanner that inspects generated code before the editor renders it. API keys stay in the IDE — the gateway forwards credentials and never stores them, which closes the first objection in any security review and rules out anything requiring persistent provider-side state.
Reversal one: from audit everything to log almost nothing
The version I launched recorded all traffic as audit logs.
That is the obvious design if you are thinking about compliance, and it is the wrong one if you are thinking about whether anyone will keep the tool installed. Full logging gives you much better policy tuning and a real audit trail. It also means a security tool is now recording every prompt a developer writes — which is a morale problem, and worse, a new exfiltration target. A security product that creates a fresh breach surface has negative value.
Current builds log policy violations and security events only. Normal traffic passes through unrecorded.
I gave up the better telemetry, which is a real cost and the one I am least happy about. I still think it is right. The quiet version is the one that survives.
Reversal two: from Docker to one command
The launch build ran as a self-hosted Docker deployment. Self-hosting was the whole pitch — nothing leaves your machine, you control the deployment.
Getting it running meant: pull and run a Docker image manually, log in with a bootstrap key, then enter the LLM base URL by hand.
I knew the setup barrier was high when I shipped it. I told myself the audience was security-minded developers who would not be put off by a container. Then people told me the same thing directly, and the argument I had been making to myself stopped working.
Developers evaluating a tool do not stand up infrastructure before they have seen it do anything. They install it, watch it work once, and decide.
Version 2 removed all three barriers:
- The Docker setup and bootstrap login flow are gone.
- Manual LLM configuration is gone. You open the VS Code command palette, select your provider, and the proxy configures itself.
- The dashboard opens inside VS Code. No separate browser, no external connection.
No terminal. No config files.
The security model did not change at all. Everything still runs locally, nothing is sent to a third party. What changed was the distance between installing and seeing it work, and that turned out to be the thing that mattered.
In March 2026 I released the engine itself as open source under the name Cencurity Engine — the same inline enforcement, unbundled from the extension. It works on the stream: blocking dangerous constructs like eval and subprocess, redacting secrets such as API keys and credentials, while the model is still producing tokens.
Reading the launch honestly
The first Product Hunt launch landed at 83 upvotes and #19 for the day. The Cencurity Engine open-source release seven months later got 3. On GitHub the repository has 12 stars, 2 forks, and 54 commits on main. Zero issues have been filed.
Those are modest numbers and the second one is worse than the first, which is the opposite of the shape a case study is supposed to have. I am stating them plainly because case studies that round every figure up are the reason nobody believes case studies.
The honest read of that drop: fixing the install path did not fix distribution. Those are two different problems and solving the first one told me nothing about the second. A better product with no audience is still a product with no audience.
What the first launch did produce was signal, and it was concentrated in one question asked two different ways: how is this different from having an LLM check your code, or from a code review tool?
Answering that twice forced the positioning I should have started with. A model reviewing output is a probabilistic check on a probabilistic system — you are asking the thing that produced the vulnerability to notice it, with no guarantee it notices the same one twice. Cencurity operates at the infrastructure layer with policy-based enforcement and structured extraction. Same rule, same verdict, every time, and the rule is readable. Determinism is the product. I had been leading with what it inspects. Everyone who understood it immediately had been led there by the fact that its answers do not vary.
That reframing came out of a comment thread, not out of a month of my own drafting.
What I would do differently
Two things, and the honest version of the second one is uncomfortable.
First, I would have shipped the install path before the policy engine. I knew the Docker barrier was high at launch and shipped anyway, and the fix — an extension and one command — was not technically hard. Knowing about a problem and treating it as a problem are different things, and the gap between them cost me a launch's worth of attention.
Second: zero issues filed is not a sign that the policy engine is well tuned. It is a sign that not enough people have run it against code that is not mine. I tuned false positives against my own repositories, which is a sample size of one with one coding style. A DevOps repository full of legitimate subprocess and shell calls will fire alerts it should not, and I know that structurally rather than from a bug report. Getting real installs against unfamiliar codebases is the next thing that has to happen, and no amount of further building substitutes for it.
Top comments (1)
Security tools need room for reversals. The product should make it cheap to correct a claim, show what changed, and preserve trust after the correction. Pretending every finding is final is how scanners lose credibility.