Application security has spent many years treating vulnerability detection as the difficult part. Security teams built scanners, hired penetration testers, and accumulated mountains of findings in the hope that identifying risk would somehow reduce it. The assumption was that if you could only see the bug, you could fix it. Arcjet CEO David Mytton argues that assumption is now breaking down. AI coding agents are changing the economics of detection, and they are doing so faster than most organizations have adjusted their remediation strategies.

AI coding agents can review entire codebases in minutes. They can generate findings, suggest patches, and summarize large areas of code that would previously have taken a human engineer days to analyze. Every improvement in detection lowers the cost of finding another vulnerability. But, crucially, it does not improve remediation. Experienced engineers continue to have limited availability, and that changes how AppSec generates value.

Vulnerability findings are therefore becoming cheap. The bottleneck is no longer the scan. The bottleneck is the human judgment required to decide what matters, what to fix, how to fix it, and whether the fix actually works in production.

Key facts

• AI coding agents can scan entire codebases and produce vulnerability findings in minutes, dramatically lowering detection costs.
• Arcjet CEO David Mytton says detection is becoming the starting point of AppSec, not the endpoint.
• AI can suggest patches, but it cannot select the correct fix; remediation requires an engineering judgment about risk.
• Verification requires correlating the original finding, the application workflow, code changes, tests, deployment, and runtime evidence.
• Measuring success by the number of AI-generated findings will create longer remediation queues; the real goal is proving the exploit path no longer exists.

Detection is the starting point

"AI coding agents will flood teams with plausible findings," says Mytton. "Some findings will be legitimate. Other findings will be duplicates, technically correct but not exploitable, or only relevant within a workflow that the scanner cannot see. Detection is becoming the starting point of AppSec rather than the endpoint. Finding the vulnerability, however, is only the beginning."

That distinction matters because many security workflows still treat a scan result as the final deliverable. A scanner identifies a potentially dangerous function call, assigns a severity, and files a ticket. The ticket is then triaged, prioritized, and eventually scheduled for a developer. But if the finding is not understood in the context of the application, the fix may be meaningless, or worse, harmful.

A vulnerability is not just a line of code

A vulnerability rarely exists as a single line of code. It is usually the expression of a behavior that emerges from the interaction of multiple components. User input, authorization checks, data access, service calls, business logic, and the action that follows a request all contribute to whether a vulnerability is real and exploitable. The vulnerable line of code is frequently only where the risk becomes visible.

Mytton explains: "A vulnerable line of code is frequently only where the risk becomes visible. The actual problem may be the sequence of steps preceding or following the vulnerable line of code: user input, authorisation, data access, service calls, business logic, and the action that follows."

This is why a scanner cannot tell you whether a finding is truly exploitable. It can see the pattern, but it cannot see the workflow. It cannot see that the input is sanitized earlier, or that the authorization control is effective, or that the operation is part of a transaction that can be rolled back. Those are application-level behaviors that require human investigation.

Remediation requires understanding

AI can identify where an application failed, but remediation requires understanding why that sequence created the risk. Teams that do not perform that analysis frequently fix the symptom while leaving the underlying behavior intact. That is why creating a patch and selecting the correct fix are two separate issues.

A patch can be syntactically correct. It can satisfy a static analysis rule. It can even pass a scanner's re-check. But it can still be the wrong fix. A patch can shift the location of the bug rather than eliminate it. It can conceal the symptom while the root cause remains. It can disrupt a legitimate workflow, or remove behavior that customers rely upon.

Mytton argues that "AI can suggest multiple possible fixes for the same finding. A patch that meets the criteria of a scanner can still be the incorrect fix. A patch can shift the location of the bug, conceal the symptom, disrupt the workflow, or eliminate behavior that customers rely upon. Remediation is an engineering judgment regarding risk, not an exercise in generating code."

This is the point where many organizations struggle. They have adopted AI coding assistants that can produce patches at impressive speed. But they have not invested in the review process that separates a real fix from an artifact. The most difficult decision for AppSec teams continues to be determining which change will truly decrease risk instead of merely altering code.

Patch without match is a mismatch

AI can create patches, but it cannot select the correct fix. The selection requires understanding the application's purpose, the user's needs, and the risk tolerance of the organization. It requires knowing whether a slow down is acceptable, whether an error message should be generic or specific, and whether a failed operation should be retried or abandoned. Those are product and engineering decisions, not pattern-matching tasks.

A scanner may recommend escaping an output value. The developer may escape it at a different point in the pipeline, leaving the vulnerable path unmodified. Or the developer may add a check that rejects all input matching a common attack pattern, but an attacker can find an alternate encoding. The patch "works" in the scanner's view, but it does not change the risk in the real application.

This is why the phrase "patch without match is a mismatch" captures the AppSec dilemma. A generated patch is not a confirmation of security. It is a candidate for review. It must be judged against the exploit path, the business logic, and the specific conditions under which the vulnerability can be triggered.

Verification requires correlation

Choosing the correct fix, however, does not demonstrate that the work is complete. A fix is not confirmed because a ticket was closed. A fix is confirmed when the exploit path no longer exists, the intended workflow functions normally, and the deployed application behaves differently in the manner anticipated by the team.

That means organizations need to connect the original finding, the application workflow, the code modification, the test results, the deployment, and runtime evidence. Without that chain of events, AppSec continues to trust documentation. A developer can write a comment saying the issue is fixed. A verification step must show that the exact path an attacker would use no longer works.

Verification also extends beyond a single finding. AI-generated findings will require correlation among findings. Ten low-severity issues may describe the same exploit path. One "fixed" issue may re-emerge through a different avenue. An input path that was denied may still be accessible through an API, a background job, or an internal tool.

"The next AppSec capability is not simply deduplication," says Mytton. "It is identifying which findings, fixes, and workflows are related. That broader perspective ultimately alters how AppSec teams measure success. AppSec is shifting from find and file to fix and verify."

The new measure of success

AI will continue to lower the cost of detection. Each new coding agent improves at analyzing code and producing findings. But experienced human engineering time remains limited. Organizations that focus on generating more findings will simply create larger backlogs. Organizations that focus on remediation quality and verification will reduce actual exposure.

"Organisations that evaluate success based upon the quantity of AI-generated findings will establish longer remediation queues," Mytton warns. "Organisations that consistently confirm fixes will reduce exposure because they realise that the exploit path no longer exists."

The actual AppSec workflow is straightforward: detect the issue, comprehend the path, select the fix, deploy securely, and verify that the behavior changed in production. AI can detect bugs. It still cannot prove you fixed them.

Q&A: Bringing security into code

In a recent media briefing, Mytton answered additional questions about how developers should think about security in an AI agent era.

Q: Why should every software engineer treat bot protection as a core development concern, not a security team afterthought?

A: Bots don't attack "security" in the abstract. They attack product features: signup forms, checkout flows, login pages, password resets and now expensive AI actions. A bot is not just bad traffic. It is a product workflow being automated against you. A security team can set policy and provide guardrails, but they rarely have the route-level context needed to make the best decision. Is the user particularly important? Does the action send a message, spend credits, reserve inventory, or trigger an LLM call? Those are engineering and product questions as much as security questions.

Q: How does enforcing security policy directly in code change the way developers think about application risk?

A: Instead of thinking "we have bot protection somewhere," developers can look at the code and see the actual policy: who is allowed, what signals matter, what limit applies and what happens when the request is denied. That changes the development workflow. Security becomes part of the implementation, not a box checked later. The same pull request that adds a route can include the rules that protect it. Reviewers can ask normal engineering questions: is this strict enough, is it too strict, does it fail safely, does it explain the decision and does it match the business logic? When security lives in code, it becomes part of engineering judgment rather than an external approval step.

Q: AI agents grow more capable of mimicking real users, what should developers be building defensively right now?

A: AI agents make automation more capable, but they do not remove the need for intent, identity and business logic. Developers should assume that automation will increasingly look like a real browser operated by a real user. It may load pages, run JavaScript, store cookies, click buttons, fill forms and follow multi-step flows. The old question was "is this a bot?" The question now is "is this action acceptable in this context?"

Q: Why is application context – identity, route, business logic – something that network-level security tools fundamentally cannot see?

A: You cannot properly protect a signup, checkout, or AI action if all you know is the IP address and headers. The network can see the request. The application can see the intent. It knows whether the user is authenticated, whether the account is new, whether the action is expensive, whether the email address matters and whether the same behavior is normal for one API, but suspicious for another.

Q: What does it mean in practice for bot protection to ship in the same pull request as the feature itself?

A: It means the protection is not a separate project. If a developer adds a signup form, the PR also includes the rate limit, bot rule, email validation and denial behavior. If they add an AI endpoint, the PR includes the controls for who can call it, how often and what happens when automation shows up. That makes security review much more practical. Instead of asking "is this protected somewhere?", the reviewer can inspect the feature and the protection together. Bot protection should ship with the feature, not arrive later as an incident response.

Source: Computerweekly News