The Problem with Traditional Pentesting
Three weeks ago, I was tasked with performing a security audit on a product I am responsible for building and maintaining. Given the increasing reports of bad actors using AI to weaponize attacks against existing applications, I knew a standard "check-the-box" approach wouldn't suffice.
In my experience, relying on external penetration testers has the following drawbacks:
- Cost: They are incredibly expensive.
- Velocity: The process can take several weeks.
- Depth vs. Compliance: Often, external audits feel like a "check-the-box" exercise. Even with legacy, poorly written code, these audits often fail to find critical logic flaws, instead flagging the same superficial vulnerabilities that a standard tool like OWASP ZAP would catch in minutes.
I wanted to avoid high costs and slow turnaround times. I wanted to: Use AI to defend against AI.
The "Guardrail" Problem
The experiment was not as simple as I expected. I quickly realized that the "safety" protocols built into modern LLMs actually make them difficult to use for security research.
I attempted to use standard coding agents like Claude and Codex, but they were too "polite"-they would identify general threats but failed to find deep, exploitable logic flaws. I then turned to specialized security tools like PentestGPT, only to hit a wall. Most frontier models have strict guardrails; if they sense you are performing cybersecurity testing, they trigger a refusal, often asking you to join a vetted list before they will assist with anything related to exploitation.
The Experiment
On the same day I saw that OpenAI launched the codex-security tool, I assumed that since the provider itself released a dedicated tool, it would work better.
I ran the scan directly against our codebase. After a few hours of whirring through the code and consuming my entire weekly token quota, the results came in.
The results were great! The AI identified several vulnerabilities that were not obvious through standard analysis. These weren't just "best practice" warnings, they were real, exploitable flaws that could have resulted in financial loss for the organization. Had we not run this scan, these flaws likely would have remained hidden until a malicious actor discovered them.
I spent the next several days in a "race to patch" to fix the vulnerabilities the AI surfaced.
The Great Trade-off: Security vs. Privacy
However, this success brings us to a profound, unresolved dilemma in the era of AI-driven development: The Privacy Paradox.
While I gained immense security assurance, I am still not entirely clear on the trade-off I made. By running a deep, exhaustive scan, did I effectively hand over the entire architectural blueprint of my source code to the AI provider?
In an era where AI agents are already integrated into our IDEs and daily workflows, some argue that the "secret sauce" is already out there. Another concern involves the risk of "asymmetric disclosure": If a model identifies a critical vulnerability in your code, is it programmed to tell you, or is it subtly designed to flag that same vulnerability for its provider?
Conclusion
I don't have a definitive answer to the privacy question, so I choose to operate under the assumption of "fair play" for now.
What I do know is that the ROI on AI-driven security scanning is undeniable. For any engineering leader concerned about the speed and cost of traditional audits, I suggest running an AI-driven scan on your code sooner rather than later. The ability to find complex, non-obvious vulnerabilities in a fraction of the time is a tool we can no longer afford to ignore.
Top comments (1)
LLMs can be useful in security audits when the findings become repeatable checks. The risk is stopping at clever one-off prompts. The value appears when each finding turns into a test, rule, or review habit.