I Shipped a Security Product I Cannot Fully Audit

As someone who has written commercial copy since 2020, predominantly in Korean for clients who will never know my identity, I recently developed and released Cencurity, a security gateway designed to safeguard traffic between AI coding agents and large language model (LLM) providers. This tool, which operates on localhost port 38180, is released under the Apache-2.0 license and can be installed via the Visual Studio Code Marketplace.

Every aspect of Cencurity's programming was aided by AI assistance, prompting me to reflect on the implications of such technology.

While the discourse around AI-assisted software development often revolves around trivial applications, the stakes are far higher when dealing with security tools. A flaw in Cencurity's masking mechanisms could allow a developer to believe their prompts have been adequately sanitized, when in fact, they have not. This potential for harm is not a trivial concern, and it is imperative that we acknowledge its existence.

Before I embarked on this project, I mistakenly believed that AI would provide the necessary implementation, while the real challenge lay in defining the framework. Instead of attempting to build a scanner for AI-generated code, I found myself focusing on the framing and the broader implications of this technology. One critical insight was that the code itself is merely one of four potential vulnerabilities, and not necessarily the most significant one.

When an AI agent is integrated into the development loop, it gains access to the developer's repository contents, environment variables, terminal output, and occasionally, credentials. This access opens the door to various attack vectors, including prompt injection, unsafe tool calls, data leakage, and consequential actions that leave no trace.

Developing Cencurity through an AI-assisted lens has also altered my ability to critically evaluate proposed architectures. Drawing upon six years of copywriting experience, I have honed my skills in providing constructive feedback, challenging proposed solutions, and maintaining a position through multiple exchanges, all without losing focus. This unique perspective has been invaluable in assessing the security of Cencurity and identifying potential areas of improvement.

However, there are aspects of the development process that cannot be fully articulated. For instance, I am unable to provide a precise cost analysis of running Cencurity under peak load, as I lack the necessary instrumentation to accurately measure this metric. Similarly, I cannot guarantee that the tool's redaction rules are entirely secure, as attempting to prove the absence of bypasses would require offensive security expertise that I currently do not possess.

The decision to release Cencurity under an open-source license stemmed from my inability to serve as the guarantor of its security. In the absence of a conventional track record or team of credentialed engineers, I opted for an open-source model where anyone can review the code, identify vulnerabilities, and propose improvements.

While this approach may not appeal to all potential buyers, it is the most equitable way to distribute trust in a tool that cannot be independently audited by a single individual. By making the policy definitions transparent and accessible to the community, I aim to compensate for my own lack of auditing capabilities and empower users to make informed decisions about integrating Cencurity into their development workflows.