I Shipped a Security Product I Cannot Fully Audit

A developer who writes commercial copy for a living has shipped Cencurity, an open-source security gateway that proxies traffic between AI coding agents and LLM providers to mask sensitive data and inspect generated code. The developer, who cannot fully audit the code because it was written with AI assistance, argues that the tool addresses four key exposures—prompt injection, unsafe tool calls, data leakage, and consequential actions—that traditional application security overlooks.

That is the uncomfortable part. It is also the argument. I write commercial copy for a living. I have been doing it since 2020, mostly in Korean, mostly for clients who will never know my name. I cannot write a for-loop from memory. In 2025 I built and shipped Cencurity https://github.com/cencurity/cencurity , a security gateway that proxies traffic between AI coding agents and LLM providers, masking sensitive data on the way out and inspecting generated code on the way back before it reaches the developer's editor. It runs on 127.0.0.1:38180 . It is Apache-2.0. It launched on Product Hunt and it installs from the VS Code Marketplace. Every line of it was written with AI assistance. I directed the architecture. I did not type the implementation, and I cannot fully audit the result. I want to sit inside that sentence rather than hurry past it, because most writing about AI-assisted building hurries past it, and the hurrying is what makes the genre worthless. Almost every argument about non-engineers building with AI is conducted over throwaway software. A habit tracker. A landing page. An internal dashboard six people use. In that context the debate resolves easily: the blast radius is small, so who cares. A security tool is the adversarial case. If Cencurity's masking rules have a bypass, the failure mode is not a broken button. It is a developer who believed their prompts were sanitized and was wrong — someone materially less safe than if they had installed nothing, because they made decisions on a false assumption. That asymmetry is real and I do not think you can wave it away. The honest version of "AI lets anyone build" has to include "including things they cannot verify," and then say what follows from that. Here is what I got wrong before I started: I assumed the scarce input was implementation, and that AI would supply it. The scarce input was the framing. The obvious thing to build in this space is a scanner for AI-generated code — that is where the alarming statistics are, and it is what most people mean by AI code security. What I kept noticing instead was that the code was one of four exposures, and not the worst one. Once an agent sits in your loop, you are also sending it repository contents, environment values, terminal output, occasionally a credential. And it acts on what comes back. The failure modes that follow are prompt injection, unsafe tool calls, data leakage on the outbound path, and consequential actions that leave no record. Traditional application security covers none of those four well. Scanning generated code covers one. Arriving at that framing was not an engineering achievement. It came from being an unusual user rather than a skilled builder — someone running these tools semi-autonomously and paying attention to the traffic instead of the output. What else transferred, unexpectedly: the ability to argue with a model. Six years of taking client feedback on copy turns out to be direct training for evaluating a proposed architecture, saying this is wrong and here is why , and holding a position across twenty exchanges without drifting. The Stanford study by Neil Perry and colleagues found that participants who distrusted their AI assistant and rewrote their prompts produced fewer vulnerabilities. Productive skepticism was the differentiator, and skepticism is not a programming skill. I cannot prove the redaction rules have no bypass. I can test the cases I thought of, and I can read the policy definitions, and neither of those is a proof. Someone with real offensive security experience would attack it in ways I have not imagined — that is the entire point of that discipline, and I do not have it. This matters more than it would for most tools, because the rules run on a live token stream rather than on a finished file, and streaming is where edge cases live. I cannot tell you what the gateway costs at p99 under load. I know it adds a local hop. I do not have the instrumentation instincts to measure that properly, so I have not published a number, and I would rather publish nothing than publish a figure I cannot defend. I tuned the policy engine's false positives against my own repositories. Sample size of one, one coding style. A DevOps repository full of legitimate subprocess and shell calls will fire alerts it should not. I know that structurally, not from a bug report — zero issues have been filed, and the open-source engine release drew 3 upvotes, which together say more about the size of the install base than about the quality of the tuning. Those are not modest disclaimers. They are the actual boundary, and two of the three are the kind of thing a buyer should weigh before installing anything I make. I released Cencurity under Apache-2.0, and I want to be precise about why, because "we believe in open source" is what people say when they have not thought about it. I open-sourced it because I cannot be the guarantor. A conventional security vendor's trust story runs through the team: credentialed engineers, audits, a track record. I have none of that and cannot manufacture it. The only trust model available to me is one where verification does not depend on trusting me at all — where anyone who doubts the tool can read it, and where my inability to audit my own work is compensated by everyone else's ability to audit it. For a builder in my position, open source is not generosity. It is the structural substitute for credentials I do not have. A closed-source Cencurity would have been an unreasonable thing to ask anyone to install. It also disciplines the product. Publishing the policy definitions means the enforcement logic is legible, and legible rules are the thing that separates a deterministic guardrail from a model you are hoping catches the same problem twice. The strongest case against people like me is not that our code is bad. It is that we degrade the signal. If shipping a security tool no longer implies security expertise, buyers lose a heuristic they relied on, and evaluating tools gets more expensive for everyone. My existence imposes a cost on people who had a working shortcut. I think that is basically correct, and I do not think it settles the question. The heuristic was already unreliable — funded teams of credentialed engineers ship vulnerable security products regularly. What is changing is that the shortcut's failure is becoming visible rather than remaining comfortable. The response that scales is verifiability: readable source, stated limitations, published failure modes. Not gatekeeping the input side. Which is why the useful question to ask about a tool like mine is never "could the author have written this by hand." It is: can you check? For Cencurity, the answer is yes. That is the whole of what I am offering.