Autonomous Preventive Security for AI-Speed Software Development

Amartya Jha
CEO, CodeAnt AI
Executive Summary
AI changed software development in two directions at once. Engineering teams now ship more code than their reviewers can read, and adversaries now run AI agents that scan, exploit, and move through systems at machine speed.
The data reflects both shifts. Vulnerabilities increased 10x from 2025 to 2026, and 86.7% of exploited CVEs in 2026 were exploited on or before the day they were disclosed.
Defense still runs at human speed. Most companies buy separate tools for code, cloud, network, and attack surface, then add a pentest once a year. None of those tools shares a model of how the company can actually be breached.
This paper describes a different operating model. CodeAnt AI builds one living threat model of a company from the inside and the outside. It continuously attacks that model, proves which paths reach critical data, fixes them at the root cause, and learns from every attempt.
The paper covers:
How the threat landscape changed in 2026, with the underlying data
Why siloed security tools and point-in-time pentests miss breach chains
How a living threat model correlates internal and external signals into one graph
The five-stage loop that attacks, proves, fixes, and learns continuously
A proven breach path from a real assessment
How verified exploit intelligence compounds across customers without sharing private data
The metrics and adoption sequence for running preventive security inside the SDLC
1. The Security Landscape Changed in 2026
For most of the last decade, security programs assumed human attackers working at human pace. That assumption stopped holding in 2026.
AI Multiplied the Code, and the Attack Surface With It
AI coding agents let a single developer produce several times more code than before. Reviewer bandwidth stayed flat, so the gap between code written and code carefully reviewed widens every quarter.
Every new service, dependency, container image, and cloud resource adds to what an adversary can reach. The attack surface now grows with every merge.
Adversaries Now Operate at Machine Speed
Attackers use AI agents to scan, test, exploit, and move laterally. They don't need to understand a company the way a human operator once did.
They also don't work one target at a time. An agent can run thousands of attacks across thousands of companies simultaneously.
Attacks are happening at machine speed. Defense is still running at human speed.
Vulnerability Volume Went Parabolic

Chart: "Cyber Risk Goes Parabolic." Number of CVEs by severity (Critical, High), 2022 to 2026. Source: a16z.
According to the analysis of CVE data, vulnerabilities increased 10x from 2025 to 2026. The shape of the curve matters as much as the multiple.
From 2022 through 2025, high-severity CVEs stayed mostly between 100 and 500 per period, peaking near 530 in 2024. In 2026 the series crosses 2,200.
Critical-severity CVEs rarely exceeded 100 per period before 2026. In 2026 they climbed past 600.
The Disclosure-to-Exploit Window Collapsed
The second chart is the more dangerous one. It tracks the share of exploited CVEs where exploitation happened before or on the day of public disclosure.
Year | Zero-day rate (% of exploited CVEs) |
|---|---|
2018 | 18.7% |
2019 | 22.4% |
2020 | 22.8% |
2021 | 31.1% |
2022 | 33.8% |
2023 | 42.2% |
2024 | 47.9% |
2025 | 53.6% |
2026 | 86.7% |

Chart: "Zero-Days-To-Exploit, Almost 90% Of The Time." Zero-day rate by year, 2018 to 2026. Source: a16z.
The rate crossed 50% in 2025 and jumped 33 points in a single year. A remediation process that starts at disclosure now starts after exploitation in nearly nine out of ten cases.
The Defender's Asymmetry
An adversary doesn't need to understand the 10,000 cloud, network, code, and infrastructure configurations inside a company. They need one path in:
One exposed service
One leaked credential
One misconfigured database
One vulnerable dependency
One endpoint nobody protected
Once inside, they identify running services, locate databases, map access paths, extract data, and leave.
The defender's job runs the other way. Protect every endpoint, secure every deployment, monitor every cloud configuration, track every identity and permission, detect every leaked secret, and respond to every infrastructure change.
All of it has to happen continuously. A company has to win every day. An attacker has to win once.
2. Why Today's Security Stack Can't Keep Up
The problem is rarely a shortage of tools. Most security teams already own plenty of them.
Security Is Bought in Pieces, and Breaches Happen in Chains
A typical company spreads coverage across at least five vendors. Each one owns a slice:
Code security
Cloud security
Network security
Attack surface management
Secrets detection
Threat detection and SIEM
Compliance
An annual penetration test
These tools don't learn from one another. Each produces findings against its own slice, rated by its own severity model.
The result is fragmented visibility. A company can run every one of these tools and still not know the single path an adversary would use to reach its customer data.

Slide: "Security is bought in pieces. Breaches happen in chains." Each vendor sees its own slice.
Shift-Left Controls Rate Findings in Isolation
Shift-left controls remain necessary. Linting in the IDE, secret detection in pre-commit hooks, AI code review on pull requests, and scanning in the build pipeline all stop defects early, where they're cheapest to fix.
Each of those controls answers one question well. Is this change safe on its own?
What they can't answer is whether a weakness in one layer becomes a route through the next. That question decides whether a finding leads to a breach.
Consider a missing authorization check on an API write. A code scanner rates it on its own merits. Put it next to an exposed staging host and a secret shipped in a JavaScript bundle, and it becomes a path to write access on the identity system.
Severity lives in the chain. A finding without reachability is an educated guess.
Point-in-Time Pentesting Leaves the Rest of the Year Uncovered
Service-led pentesting and PTaaS still account for roughly 75% of the market. The work is scoped, manual, and delivered as a report after the engagement closes.
A company that changes on every commit can't be assessed once a year. The report describes a system that stopped existing a few hundred deploys ago.
Traditional pentests also leave no complete record of what was tested. The customer gets conclusions without the trail behind them.
How Current Testing Approaches Compare
Every approach on the market tests some piece of the breach path. They differ in where testing starts, how deep it goes, and how often it runs.
Approach | Where testing starts | Internal depth | Cadence | What it proves |
|---|---|---|---|---|
Pentest services and PTaaS | Scoped targets | Limited to engagement scope | One-time, manual | Scoped attack paths |
AI pentesting for applications | Apps and APIs | None | Autonomous, on demand | Application exploits |
AppSec platforms with AI pentesting | Apps, APIs, and code | Cloud posture only | Continuous | Application exploits |
Enterprise network testing | Internal network | Network and identity | Continuous | Network and identity paths |
Living threat model (CodeAnt AI) | External attack surface, apps, and APIs | Code, shipped binaries, cloud, and identity | Continuous | Verified code-to-data path |
Each approach tests a piece. A living threat model is built to prove the entire breach path, continuously.
3. See the Company From the Inside and the Outside
Most tools see one side or the other. The paths that matter run between them.
CodeAnt AI combines both views into one continuously evolving threat model. We see your company from the inside and the outside.
CodeAnt External Maps What an Attacker Can Reach
CodeAnt External looks at the company the way an adversary would, from the internet inward. It maps:
Domains and subdomains
IP addresses and open ports
Reachable services, live endpoints, and APIs
Misconfigured databases, weak hosts, and exposed infrastructure
Third-party and vendor risk
Leaked employee credentials across the dark web, the public internet, and Telegram channels
Live attack and external threat intelligence
The goal is to identify every path an external adversary could use, before one of them is used.
CodeAnt Internal Maps How the Company Is Built
CodeAnt Internal understands what runs inside the company and how it fits together. It maps:
Code, pull requests, and commit history
Third-party code dependencies and shipped binaries
Secrets and credentials
Cloud and infrastructure-as-code configurations
VMs and containers
Runtime behavior, identity, and access configuration
Internal context turns an external exposure into a specific root cause. It also shows which internal weaknesses an outsider can actually touch.

Slide: "We see the company from the inside and the outside." CodeAnt External and CodeAnt Internal feeding one living threat model.
One Graph Instead of Separate Inventories
Siloed tools keep separate inventories of repositories, packages, containers, and cloud resources. CodeAnt AI connects them as one graph, so a weakness in one node becomes a route through the next.
A vulnerable npm package, scanned alone, is one line in an SCA report. In the graph, it's a dependency pulled into a backend service, shipped in a container, running on EKS behind a load balancer that exposes a public subdomain.
That connection changes the question a security team asks. "How severe is this?" becomes "Can this be reached?"

4. How the Living Threat Model Works
The threat model runs on paired signals. Each internal signal has an external counterpart that determines whether it matters.
Paired Internal and External Signals
The model ingests five internal and five external signal classes and correlates them before scoring anything.
CodeAnt Internal | CodeAnt External |
|---|---|
Code, PRs, and commit history | Domains, IPs, and subdomains |
Dependencies and binaries | Open ports and services |
Secrets and credentials | Live endpoints and APIs |
Cloud and IaC configurations | Network and traffic context |
Runtime, identity, and access | External threat intelligence |
A secret in a repository matters more when a live endpoint uses it. An open port matters more when the service behind it runs a vulnerable binary.
Four Jobs the Model Performs
Every input feeds four continuous functions:
Correlates internal and external context: joins what the company ships with what attackers can see.
Continuously rebuilds with every change: updates on commits, infrastructure changes, identity changes, and exposure changes.
Builds end-to-end exploit paths: chains individual weaknesses into complete routes from entry point to impact.
Measures reachability to crown-jewel data: tests whether a path reaches customer data, production systems, or secrets.
Every finding the model produces answers one question. Can this reach critical data?

5. The Continuous Attack-and-Defend Loop
CodeAnt continuously attacks, continuously defends, and builds a self-learning threat model. The loop is closed on purpose, and it processes roughly 15 billion security events every month.
The Five Stages
Each stage produces an output that the next stage consumes.
Stage | What happens | Output |
|---|---|---|
01 Model | The graph is built from internal and external signals and rebuilt on every change | Current threat model |
02 Attack | Agents attempt attack paths against the reachable surface | Successful attempts, failed attempts, and controls encountered |
03 Prove | Paths validated end to end are marked proven, and unvalidated paths stay labeled as considered | Verified attack-path record |
04 Fix and reset | The root cause is remediated and the same path is re-tested | Closed path with a recurrence guard |
05 Learn | The verified pattern is abstracted and fed back into the model | Stronger model for this customer and for similar customers |

Slide: "Every attack makes CodeAnt smarter." Model, attack, prove, fix and reset, learn loop. ~15B security events processed monthly.
What an Attack Produces
Every attack run records three things:
Successful attempts: the steps that worked.
Failed attempts: the steps that didn't, and where they stopped.
Controls encountered: the defenses that blocked or slowed the attack.
Failed attempts carry as much signal as successful ones. They show which controls actually hold under a real attack, which a configuration audit alone can't confirm.
The Verified Attack-Path Record
A successful attack becomes a structured record with three parts:
Conditions: when does this become exploitable?
Sequence: how does it reach a critical asset?
Proven remediation: what change permanently closes it?
The record is what separates a proven path from a theoretical one. It carries enough detail for an engineer to reproduce the path, and enough precision to verify the fix.
Customer Protection
The record drives remediation in three steps:
Fixed at root cause: the change targets the condition that made the path possible in the first place.
Re-test the path: the same sequence runs again to confirm it's closed.
Prevent recurrence: the closed path stays in the model, so a later commit that reopens it gets caught.
Patching only the exposed host leaves the leaked secret and the missing authorization check in place. The next exposed host reopens the same path.

Slide: Attack and validate, verified attack-path record, customer protection, privacy-safe abstraction, proprietary attack-path corpus.
6. Anatomy of a Proven Breach Path
This example comes from a real CodeAnt AI assessment. Hostnames and customer details are removed.
What the Assessment Found
The assessment traced proven paths from exposed hosts, through three root causes, to four categories of company data.
Layer | Finding |
|---|---|
Exposed surface | Four application hosts on a managed cloud app service (production API, data center app, portal, and staging API), plus 12 peripheral hosts |
Root cause 1 | Client-side secrets in JavaScript bundles |
Root cause 2 | No authentication on API reads |
Root cause 3 | No authorization on API writes |
Data reached | Customer PII (3,000+ records) |
Data reached | Workforce directory and passwords |
Data reached | Identity system write access |
Data reached | Asset, vendor, and OT data |
The report distinguishes proven attack paths from paths that were considered but not proven. Only proven paths drive priority.

Slide: "CodeAnt shows how companies will get breached, before attackers do." Exposed surface, company boundary, root cause, company data. Redact all hostnames before publishing.
Why Siloed Tools Would Miss It
Each root cause, found alone, looks like a routine ticket. A secrets scanner flags the bundle. An API scanner flags missing authentication. An attack surface tool lists the staging host.
None of those tools shows that the three findings together reach write access on the identity system. That chain is the breach, and it only appears when the hosts, the code, and the data sit in the same graph.
7. Pentest Auditability
Traditional pentests deliver a report after the work ends. The customer can't see every action taken during the assessment, so the findings have to be taken on trust.
CodeAnt AI records the full testing trail, including:
Every call made
Every command executed
Timestamps
Response codes
Failure rates
Latency
What was tested
What happened at each point in the attack path
Teams can inspect, visualize, download, and share the trail.
This matters for three groups. Engineers can reproduce a path before fixing it. Auditors get evidence of what was tested and when. Security leaders can verify that autonomous agents stayed in scope.
8. Compounding Intelligence With Private Boundaries
Every verified exploit makes CodeAnt stronger for every customer. The boundary that makes this safe is strict.
What Stays Private and What Is Shared
Internal learnings stay private to each customer. Only verified, externally reachable exploit patterns are shared.
Context | Examples | Handling |
|---|---|---|
Private internal context | Code and repositories, cloud and IaC, identity and access, runtime and infrastructure, CI/CD | Never leaves the customer. Improves only that customer's threat model. |
External exposure | Public IPs and domains, exposed services, internet attack surface, threat intelligence | Verified exploits can be abstracted and reused across customers. |
Privacy-Safe Abstraction
Before any verified pattern leaves a customer's model, it passes through three steps:
Remove customer data: all identifying data and content is stripped.
Preserve the graph pattern: the shape of the path (which kinds of nodes connect, in what order) is kept.
Keep the attack conditions: the conditions that made the path exploitable are retained.
What remains describes how a class of breach works without describing whose system it was found in.
The Proprietary Attack-Path Corpus
Abstracted patterns feed a corpus of four record types:
Verified attack paths
Failed attempts
Blocking controls
Proven fixes
The corpus is applied back to every customer's model. A control that blocked an attack in one environment informs how the same path is scored in another.
Re-Scoring Similar Customers
When a verified external pattern matches another customer's exposure, that customer is re-scored automatically. If Customer A's assessment proves a new path, Customers B, C, and D with matching exposure are re-scored without waiting for their own next assessment.
Every new customer adds external exploit intelligence. The model gets harder to catch up with the longer it runs.
[Image placeholder] Slide: "Every verified exploit makes CodeAnt stronger for every customer." Private graph stays with Customer A, shared patterns verified only.
9. Evidence From the Loop
The loop runs on real customer infrastructure every day. Its output is measurable.
Metric | Result |
|---|---|
Security events processed | ~15 billion per month |
CVEs discovered | 150+ |
Highest-severity finding | CVSS 10.0 in pac4j, undetected for six years |
Downloads protected | 2B+ per month, from one upstream finding |
CVE-2026-29000 in pac4j-jwt
pac4j-jwt is a widely used Java authentication library. The CodeAnt AI security research team found that an attacker could authenticate as any user, including administrators, using only the server's public key. The flaw is tracked as CVE-2026-29000 with a CVSS score of 10.0.
No single component was broken. The JWT specification allows unsigned tokens, the underlying library behaved correctly, and pac4j's null check was correct in isolation. Authentication disappeared only where those pieces met.
That is the same failure class a living threat model is built to find. Every component passes review, and the composition is the vulnerability.
After private disclosure, pac4j's maintainer released patches within two days, and CodeAnt AI contacted hundreds of downstream maintainers whose packages were affected.
10. Running Preventive Security Inside the SDLC
Preventive security doesn't replace the SDLC controls teams already run. It connects them to the question those controls can't answer alone.
Where the Threat Model Plugs In
The model rebuilds on the same events that already drive engineering work:
Commits and pull requests: code changes update the internal graph and can open or close paths.
Infrastructure changes: cloud, IaC, and identity changes re-score reachability.
Exposure changes: new subdomains, open ports, and leaked credentials update the external view.
Code review keeps catching defects at the cheapest point. The threat model tells the team which of the remaining weaknesses an adversary can actually use.
Metrics That Measure Prevention
Finding counts reward noise. These measures track whether breach risk is actually going down.
Metric | What it tells you |
|---|---|
Proven paths open to critical data | Current, verified breach exposure |
Time to close a proven path | Remediation speed on the risks that matter |
Recurrence rate of closed paths | Whether fixes address root causes |
Share of findings with verified reachability | How much of the backlog is proven versus theoretical |
External exposure drift | How fast the attack surface changes between assessments |
Adoption Sequence
Teams get to proven paths fastest by connecting signals in this order:
Establish the external baseline: map domains, subdomains, IPs, open ports, exposed services, and leaked credentials.
Connect internal context: add repositories, dependencies, binaries, cloud configurations, and identity.
Prove and prioritize: run attacks, separate proven paths from considered ones, and rank by reachability to critical data.
Remediate at root cause: close proven paths, re-test them, and keep them in the model as recurrence guards.
Run continuously: rebuild on every commit and infrastructure change, and track the prevention metrics above.
11. Conclusion
AI made software faster to build and faster to attack. The first change created more attack surface. The second removed the time defenders used to have between disclosure and exploitation.
A security stack bought in pieces can't keep pace with breaches that happen in chains. It rates findings in isolation, tests on a calendar, and never learns across the environment.
Preventive security needs one model that learns continuously from what is exposed externally, what is changing internally, how attackers behave, and which paths lead to real impact.
CodeAnt AI understands how a company works, finds the unchecked spot, identifies the root cause, and shows the path to a potential data leak. It proves that path, closes it, and makes every other customer's model stronger in the process.
Find the breach path before the attacker does.
This white paper is a living document. As attack techniques and AI capabilities evolve, so will the model it describes.
Published by CodeAnt AI | September 2026
See Your Breach Paths Before an Attacker Does
Get a pentest report that shows proven paths to your critical data, with the full audit trail behind every finding.

