AI changes how software is built, not who is responsible for securing it

More code means more vulnerabilities, even with better tools

There is a tempting assumption behind every advance in automated security: that better detection will eventually close the gap. But the math does not work that way. As AI accelerates development, the sheer volume of code being produced grows faster than any improvement in detection can offset.

This means the security challenge is not shrinking; it is compounding. And it is compounding in an environment where most teams are starting to think about security after production, not before. Things get back to building first and assessing risk later, which means vulnerabilities reach production before anyone has evaluated them. When you combine that habit with the unprecedented speed at which code now moves from an agent's output to a live deployment, testing in production becomes essential.

There is also a dangerous assumption forming around AI-assisted remediation. Because AI agents can now detect a vulnerability and propose a fix in the same workflow, some will conclude that the loop is closed: the agent writes the code, finds the bugs, and fixes them. The code must be secure. But it will not be. An agent remediating its own output does not guarantee a secure result but a faster cycle that still requires validation.

AI changes how software is built, not who is responsible for securing it

At Fluid Attacks, we frame the current shift this way: "AI builds. Humans command. We secure." The emphasis on "command" is deliberate. AI agents are transforming every stage of software development, from writing code to testing it to proposing fixes, but the responsibility for security does not transfer to the agent. Humans remain in control. They define what gets built, they set the risk tolerance, and they are accountable when something goes wrong.

If the agent can code, scan, and remediate, why involve humans at all? The answer is that security is a judgment call that depends on context an agent does not fully possess: the business logic of the application, the threat model of the organization, the regulatory requirements of the industry, risk tolerance. These are human decisions.

Plus there is the case of false negatives. We know that false positives, for their part, will lose some of their sting in a world where development speed makes remediation cheaper and faster, even when it comes to false alarms. But a false negative, a real vulnerability that goes undetected, is always relevant. It represents unmanaged risk and an open vector for attack. This is why layered testing, combining AI reasoning, deterministic source code analysis, dynamic testing, and human review, is not a luxury: It is the only approach that minimizes the blind spots any single method inevitably has.

Our pentesters have already tried AI tools to amplify their work, and we summarize the synergy this way: Humans think strategically; agents execute massively. The agent scales execution. running parallel tests, analyzing entire repositories, generating vulnerability candidates. The human provides strategic thinking, the creativity to find paths no model anticipates, and the judgment to confirm whether a vulnerability is exploitable in the context of the real, running system.

A changing landscape demands a broader view

While it is tempting to focus on what Claude Code Security does and does not do, the more important conversation is about the broader changes reshaping software development and, therefore, application security.

The developer's role is evolving from writing code to instructing agents, defining requirements, and validating outputs. We believe the tools are shifting too: IDEs may well give way to command-line interfaces with agents, and eventually to environments where LLMs function as a brain with access to the developer's desktop. Developer machines themselves may become the sandboxes where applications are tested. These are not distant scenarios but the direction in which the early adopters are already heading.

At the same time, application architectures are becoming more distributed. APIs proliferate. MCP servers emerge as new components in how systems interconnect. LLMs and AI models become actors in the software supply chain, with a more critical role in both development and production. New user interfaces, such as chat and voice, introduce new categories of weaknesses that did not exist a few years ago.

All of this creates attack surfaces that are more dynamic and harder to manage. And a tool that reads source code, no matter how intelligently, addresses only one layer of this picture. Code with perfect syntax can still be vulnerable. An application whose source code passes every static analysis check can still be exploitable if its runtime environment is misconfigured, if its infrastructure has gaps, or if the interactions between its components introduce flaws that only manifest when the system is actually running.

Testing the system as a whole

This is what we believe the conversation needs to center around, and it is the principle that guides our work at Fluid Attacks: security requires testing the coherent system as a whole, across the code layer, the runtime environment, and the infrastructure.

Static analysis, even AI-powered static analysis, examines code without executing it. Many of the vulnerabilities that end up in incident reports are not problems that can be found by reading source code more carefully. They are behaviors that emerge when an application runs in its actual environment, requests pass through the API stack, authentication middleware chains together, and components interact across services. These vulnerabilities require actually running the application and testing it under conditions that resemble how an attacker would probe it.

Claude Code Security does not do this. Nor does any static analysis tool, traditional or AI-powered. This is not a flaw in Claude Code Security's design, but simply reflects the scope of what it set out to accomplish. The question for security teams is whether their programs cover the layers that code scanning, however sophisticated, cannot reach.

The same logic applies to vulnerability exploitation. Confirming that a finding is genuinely exploitable in a specific environment requires more than reading code and reasoning about it; it requires testing the live system. This is the domain of penetration testing, where human expertise remains critical. At Fluid Attacks, we combine automated tools, including our AI SAST, with expert manual pentesting as each has advantages and limitations that the other compensates for. Automated AI analysis covers breadth, scanning entire codebases at speed and generating context of the attack surface that pentesters use to lead testing. And the pentester brings depth: the ability to test whether a flaw is genuinely exploitable in the deployed environment and probe the system's behavior in ways that no automated tool can.

Third-party risk is expanding beyond packages

The conversation about supply-chain security has historically centered on open-source dependencies: scanning packages for known CVEs, generating SBOMs, checking licenses. That remains important, but the supply chain of a modern application now includes components that traditional SCA was never designed to evaluate.

When an application relies on an LLM for decision-making, that model is a third-party dependency. When it connects to external services through MCP servers, those servers are part of the attack surface. When AI agents use skills and plugins to extend their capabilities, each skill is a component that can introduce risk. Testing third-party components is no longer just SCA over packages; it must extend to models, skills, and MCPs. The tooling and methodology for this kind of testing is still emerging, and it represents one of the most important frontiers in application security.

What enterprise AppSec programs actually manage

Enterprise software does not live in a single repository maintained by a single team. It is a sprawling ecosystem: hundreds of applications, distributed teams across geographies and time zones, a mix of legacy systems and modern microservices, shadow IT that security teams may not even know exists, and services whose criticality ranges from internal tooling to systems that affect the daily lives of millions of people. A vulnerability in a payment processing service is not the same as a vulnerability in an internal wiki, and the security program must understand that difference.

This complexity is what makes a code scanner, however intelligent, insufficient as the backbone of an enterprise security program. The challenge is not just detecting vulnerabilities; it is ensuring that testing actually happens, consistently and comprehensively, across an ecosystem that is constantly changing.

Consider the control points that an enterprise must govern. Code is written in the developer's environment, reviewed in a pull request, integrated in a CI pipeline, and deployed to production. Each of these stages is an opportunity to test, and each is also an opportunity for a vulnerability to slip through if testing does not run. Are scans running at the CLI during development? Are they enforced at the PR before code is merged? Is the CI pipeline configured to block builds that fail security thresholds? Is the application being tested after deployment, in the runtime environment where real attacks happen? An enterprise security program must guarantee that tests execute at multiple control points, because relying on any single one leaves gaps.

And in this context, a false negative is potentially catastrophic. These are systems that process financial transactions, manage healthcare data, control critical infrastructure, and mediate access to services that people depend on every day. A vulnerability that goes undetected, a real risk that nobody knows exists, is an open vector for attack against systems whose compromise has consequences far beyond the organization itself. This is why enterprises need assurance not just that good tools exist, but that those tools are running, that their results are traceable, and that nothing falls through the cracks.

The system of record endures

The tools developers use to write code are changing rapidly; some of them, like traditional IDEs, may not survive the shift to agent-driven development at all. Systems of creation are transient by nature; they evolve, they get replaced, they follow the tooling preferences of the moment.

An ASPM platform, by contrast, is set to become the authoritative source of truth about the security posture of an organization's software portfolio. It is where every finding from every testing method converges into a single, governed, traceable dataset. It is where remediation workflows live, where policy enforcement happens, where compliance evidence is generated, and where development and security teams come together around shared, complete information.

While the systems of creation keep changing, the system of record endures. And the organizations that manage risk effectively will be those that anchor their security programs not to whichever scanning tool is newest, but to a platform that persists, integrates, and governs across every layer of the application.

Our platform is built on this conviction. It is the single source of truth where results from all testing methods converge, where the organizational workflows around those results (assignment, remediation, verification, policy enforcement, compliance reporting) are part of the same system, and where the right people across teams have the information they need to make security decisions together.

Moving forward together

We welcome Claude Code Security as a sign that the industry is converging on a truth we have held for a long time: AI reasoning belongs in application security, and it meaningfully improves what static code analysis can accomplish. The technology will mature, its scope will expand, and the tools built on it will become part of how every organization thinks about securing its code.

But we also believe that the future of application security is not about any single scanning capability, however powerful. It is about testing systems integrally, across code, environment, and infrastructure; about bringing development and security teams together around shared, complete information; and about anchoring security programs to a system of record that endures while the tools around it evolve.

AI changes how software is built, not who is responsible for securing it. That is the principle we build on at Fluid Attacks, and Claude Code Security's arrival reinforces our conviction that it is the right one.