The AI era cuts both ways. The same models that help an attacker find a flaw faster can help a defender find it first, understand it more deeply, and prove whether it actually matters. Over the past year we made a deliberate bet at Eightfold: point frontier AI at our own platform, continuously, before anyone else does. Today we run ten AI-driven security capabilities in production to augment and enhance our human driven processes, most of them run automatically on every change we ship.
In this post, we’ll cover what we built, why we chose gating over periodic checks, and how these new security measures impacted our metrics. We’ll also explore the other side of “safer in the AI era”: securing the AI products we ship to customers, not just using AI to defend our internal systems.
The year in numbers
We measure our security program by one question: are we finding and fixing more, earlier, than we were a year ago? Our measurements show we are.
- 5x more security bugs identified proactively, before reaching production than the prior year.
- 4.7x more vulnerabilities remediated year over year.
- 64% reduction in mean time to remediate a validated critical finding.
- 86% of false-positive vulnerability noise removed before a human is involved, through reachability and exploitability triage.
- New features AI red-teamed before release.
The rest of this post explains how those numbers happen.
From checks to shift-left security
The biggest enhancement we made was not technical. It was applying additional security checks when code is written, not after it is released.
Traditional security programs are built around periodic checks. They inspect a snapshot of the system at a single point in time and inevitably fall behind as the codebase evolves.
We chose a different model. Instead of treating security only as a periodic review, we embedded it directly into the software delivery lifecycle. Security runs automatically on changes,pull requests, and deployment. Developers get feedback while the context is still fresh and fixes are inexpensive.
Nine of our ten security capabilities operate as automated gates rather than scheduled reviews. That distinction matters. Periodic checks provide temporary confidence that begins to decay the moment they finish. Shift-left security compounds. Changes are evaluated against the same baselines, releases reinforces that baseline, and the security posture improves continuously.
The foundation: frontier AI
None of this works without access. Red-teaming and vulnerability research are exactly the use cases that general-purpose AI terms of service tend to prohibit, so most security teams hit a wall the moment they point a commercial model at offensive security work.
We do not. Eightfold is an active participant in both the OpenAI and Anthropic cybersecurity programs, which give us sanctioned access to apply frontier models to security research without the usual usage restrictions. This is the foundation the other nine capabilities depend on, and it has a compounding property we did not fully appreciate at first: when the underlying frontier models improve, our security tooling improves with them, without us rebuilding anything. Our floor rises as the labs ship.
Secure by construction
The cheapest vulnerability is the one that never merges. Three capabilities push security to the earliest possible point in development.
Pull requests (PRs) are security-reviewed by AI. Claude Opus 5 reviews every PR diff in CI, reasoning about intent and data flow the way a human reviewer would rather than pattern-matching signatures. It flags XSS, SQL injection, broken authentication, IDOR, SSRF and injection classes, triages its own true and false positives, and gates the merge. It surfaces an average of 3+ real issues per pull request. Traditional SAST is strong on known signatures and blind to intent, and noisy enough that developers learn to skip it. A model that reads the diff does not have that blind spot.
New features are threat-modeled. Design docs now carry a mandatory security, permissions and privacy section that states the expected permission model per endpoint. The developer authors a threat model, Claude Opus 5 augments and stress-tests it, and GPT-5.6-terra hunts for bugs in the new code. Then the threat model itself becomes the QA test plan. Threat modeling is something most teams reserve for major releases if the calendar allows; we don’t have those limits – we do it by feature, and by release.
Fixes are verified independently. A ticket that says “fixed” is an assertion. When a security fix is developed, Claude Opus 5 re-executes the original test case against the fix, scans the change for regressions and side effects, and escalates back to the security team when the issue is not actually resolved. It closes on evidence, and saves roughly 30 minutes of manual verification per test.
Continuous discovery, focused on real risk
Shipping securely is not enough, because latent flaws hide in code nobody touched recently. Three more capabilities keep looking.
We scan the codebase, daily. Claude Opus 5 and GPT-5.6-sol examine the codebase on a daily cron, and whenever a new endpoint is added; the focus is not on just the code that changed. We deliberately run two frontier models from different labs so that a blind spot in one is not a blind spot in the program.
We focus on exploitability instead of counting CVEs. A raw CVE count makes real risk compete with noise for the same engineers. We combine code-level reachability analysis with Claude Opus 5 and live exploit intelligence, including EPSS scores, CISA Known-Exploited-Vulnerabilities status, and public exploit availability, to determine what is genuinely reachable and exploitable in our environment. Non-exploitable findings are auto-filed, de-duplicated and auto-closed. The result is 86% less noise and roughly a day faster on both triage and fix.
Secret scanning is AI-triaged. Claude Opus 5 continuously scans our public repositories for leaked secrets, where exposure is immediate and irreversible, and separates live credentials from test fixtures, examples and expired keys. The security team sees real exposures, not a regex backlog.
Detect, red-team, and respond
We red-team ourselves, continuously. GPT-5.6-terra and GPT-5.4 simulate real adversarial attacks against our own platform. The red-teaming is code-aware: it infers input and output parameters, crafts the pentest scenarios that actually matter for each API endpoint, reasons in OWASP Top threat scenarios, and produces reproducible failure cases. It already runs against 70% of epics before release.
Production is monitored around the clock. Dropzone AI and Claude Sonnet 5 triage and investigate production alerts in real time, backed by endpoint detection and response on production hosts. Alerts get a full investigation rather than a queue position, so an attacker who gets past the perimeter still trips a detection on the host itself.
Alerts and reports are validated before a human sees them. Claude Opus 5 validates and triages output from SAST, DAST and AI source-code scanners, and validates, reproduces and de-duplicates inbound reports from our private bug bounty program. Humans adjudicate real findings instead of hand-sifting duplicates.
Why this compounds
The system gets stronger over time for three reasons.
First, security runs as automated gates. Changes are evaluated by default, so coverage expands with each release instead of fading between checks.
Second, the knowledge base continuously grows. Threat models, and test plans accumulate over time. Coverage built for one feature continues protecting the features that follow, turning each investment into a permanent asset rather than a one-time review.
Finally, we benefit from advances in the underlying models. Access to frontier models means improvements in reasoning, code understanding, and vulnerability detection immediately strengthen our security pipeline without requiring us to redesign it. As the models improve, so does our security posture.
What we’re working on next
- Continuous red-teaming. Adversarial testing of our own platform runs on request today. We’re moving it to a continuous schedule, so the platform is under simulated attack constantly rather than whenever someone starts a run.
- Exploitability proof across the full dependency tree. Reachability analysis today tells us whether vulnerable code is callable from our own code. We’re extending it through transitive dependencies — the packages we never import directly but ship anyway.
- Automatic validation for finding sources. Static analysis findings are validated and de-duplicated automatically. AI source-code and dynamic scanning findings still wait for a human to kick off the run. We’re closing that gap so finding get the same treatment, regardless of which tool produced it.
Security at scale is a posture, not a project. AI has not changed that. What it has changed is how much of the posture we can verify on builds, and how honestly we can answer the only question that matters: is this correct, and will it stay correct as the platform grows.
Want to see the controls behind these claims? Explore our Trust Center, or if you are a security researcher, our private bug bounty program is where we would love your help.