One Findings Model: Why Static and AI Security Findings Belong in the Same Place

Every static analysis tool ships with the same structural blind spot, and better rules won’t fix it: rules-based scanners read your code as written, not the system it becomes. Your IaC scanner reads the Terraform, not the live security group. Your image scanner reads the Dockerfile, not the built image. Your SAST engine reads a function, not the four-file path from an untrusted HTTP parameter to a cloud metadata endpoint.

This isn’t a knock on any of them. Pattern-matching over code, manifests, and dependencies is exactly what these scanners are for, and it’s fast, deterministic, and reproducible — properties you want in a build gate. But the moment your threat model includes anything that lives outside those files — the layers of the image you ship, your live IAM and network configuration, the trust boundaries between services — rules-based scanning is, by construction, looking at the wrong artifact.

This post is about what fills that gap, and — more importantly — about the unglamorous engineering that decides whether filling it actually helps you or just doubles your alert volume.

The gap: what your scanners structurally can’t tell you

Consider a few questions a security engineer actually asks, and where your existing scanners land on each:

• “Is there a secret baked into a layer of our production image?” Your image scanner reads the Dockerfileand the declared base — it doesn’t build or pull the actual image. So a credential RUN-added in an early layer and “removed” in a later one — still fully recoverable via docker history and layer extraction — is invisible to it.
• “Is this S3 bucket actually public right now?” Your IaC scanner can lint the Terraform that should produce the bucket. It cannot see the live bucket policy, the drift, the manual change someone made in the console at 2 a.m. during an incident.
• “Can a request walk from this SSRF to our IAM role?” SAST may flag the SSRF sink in isolation. It does not assemble the chain — SSRF → 169.254.169.254 → temporary credentials → privilege escalation → exfil — because no rule engine reasons across that many hops and services.

These aren’t edge cases. They’re the center of modern attack surface. The gap is structural: the tool is analyzing the blueprint, and the attacker is in the building.

Why agents change the equation

An AI agent operating in the real environment — with consent, with your credentials, on your machine — is not bound to the source tree. It does what a competent engineer would do during an assessment, faster and more exhaustively:

• Inspect image contents. Build or pull the image, run trivy or grype against it, walk docker history for secrets baked into layers, check for EOL base images, setuid binaries, world-readable secrets, and containers running as root.
• Read live cloud posture (read-only). Enumerate S3 bucket policies, trace IAM privilege-escalation paths, find security groups with 0.0.0.0/0ingress, spot public RDS or ELB endpoints and over-broad KMS grants. Live config beats reading IaC files, because it’s what’s actually exposed.
• Reason across files. Trace authz/IDOR and tenant-isolation breaks across module boundaries, follow injection from source to sink, recognize deserialization gadget chains, and — the hard one — assemble full attack chains a rule engine never will.
• Critique architecture. Identify trust boundaries with no enforcement behind them — the design-level flaws that no single line of code expresses.

The point isn’t that AI is magic. It’s that an agent reaches artifacts your scanners cannot reach, and reasons across distances no rule engine can span. Different vantage point, different findings.

There’s a real privacy property here, and it’s unusual. In this flow, the reasoning runs entirely on your side.The AI findings come only from your own AI client, running on your own machine, against your own code — so for the scan that produces them, no model runs on Intercept’s servers, and none of the model’s reasoning is stored: the platform keeps the structured finding, not the chain of thought that produced it. The intelligence lives on your side of the boundary; the platform’s job starts only once you choose to report a finding.

The models are getting genuinely good — fast

It’s fair to be skeptical that a model can find a real bug rather than hallucinate a plausible-sounding one. So look at the evidence, scoped honestly.

In April 2026, Anthropic ran Project Glasswing (opens in a new tab): an unreleased frontier model, Claude Mythos Preview, was put in the hands of Anthropic plus twelve launch partners — AWS, Apple, Cisco, CrowdStrike, Google, Microsoft, NVIDIA, the Linux Foundation, JPMorganChase, Palo Alto Networks, Broadcom — and roughly forty more organizations. Together they surfaced thousands of high-severity vulnerabilities (opens in a new tab) across every major operating system and web browser. The specific finds are the persuasive part: a 27-year-old flaw in OpenBSD, a 17-year-old NFS remote-code-execution bug in FreeBSD (CVE-2026-4747), and — the line worth sitting with — a 16-year-old bug in FFmpeg that automated testing tools had hit five million times without ever catching.

That last detail is the whole argument in miniature. Five million automated hits is not a coverage problem you fix with a faster scanner. The model caught it because it reasons about code differently than a rule engine does — a different vantage point, which is exactly the claim of the previous section. The benchmarks point the same way: Mythos Preview scored 83.1% on the CyberGym vulnerability-reproduction benchmark against 66.6% for the prior Opus generation, and on manual review, expert reviewers agreed with the model’s severity rating exactly in 89% of 198 reports, and within one level in 98%.

The capability doesn’t stop at finding, either — these models can prove what they find. Asked to turn Firefox JavaScript-engine bugs into working shell exploits, the prior Opus generation managed it twice in several hundred tries; Mythos did it 181 times (opens in a new tab), and on a fuzzing benchmark drove ten separate, fully-patched targets all the way to control-flow hijack. That 17-year-old FreeBSD flaw from earlier? It didn’t just find it — it autonomously exploited it to root. That’s not just alarming — it’s useful: the slowest part of triage was never spotting a candidate bug, it was answering is this actually exploitable, and how bad?A model that can build the exploit answers that in minutes instead of days. It cuts both ways, which is exactly why Anthropic gates the offensive version — the capability that lets an attacker weaponize a patch overnight is the one that lets a defender confirm and prioritize a real finding on the spot.

And it isn’t one lab’s result. In late 2024, a separate effort — Big Sleep, built by Google’s Project Zero and DeepMind — found a previously-unknown exploitable bug in SQLite (opens in a new tab), a stack buffer underflow in widely-deployed software, in what its authors described as the first public case of an AI agent finding an exploitable memory-safety flaw in real-world code. Same category, same shape of result, different organization and different model — which is the point. When multiple frontier labs independently land the same kind of finding, it stops reading as one vendor’s marketing.

Two honest caveats, because they matter. First, scope: this evidence is concentrated in memory-safety and logic bugs in complex systems software — kernels, browsers, codecs. It says AI is formidable in certain categories, not that it beats static analysis everywhere. Second, Mythos itself is gated research demonstrating capability, not a tool you can grab — it was suspended in June 2026 under a US export-control directive (opens in a new tab). And the research is refreshingly humble: over 99% of what they found is still unpatched, the team said plainly they “would be surprised if we got everything right,” and human validation stayed in the loop throughout — with findings clearly labeled and disclosed with restraint (opens in a new tab) rather than dumped on maintainers.

This isn’t about access to a frontier offensive model. The defender win is quieter: independent benchmarks keep finding that hybrid LLM-plus-static configurations beat either approach alone (opens in a new tab) — the model catching what tools miss, the tools grounding what the model claims. The capability is real and rising. Which moves the hard question downstream: can you actually live with what it finds?

The trap: a second silo of un-triaged noise

Here’s where most of the market goes wrong.

The easy version of “AI-powered AppSec” is to bolt a model onto a scanner and pipe its output into a newplace — a separate “AI findings” tab, a different severity vocabulary, its own half-built triage flow, no relationship to the findings your scanners already produce. You end up with two parallel streams of alerts that don’t share status, don’t share scoring, don’t deduplicate against each other, and definitely don’t roll up into the same compliance view.

That’s not a security improvement. That’s a second backlog. The AI tab becomes the tab nobody opens — everything in it is unverified, uncorrelated, and impossible to reconcile with the system of record.

The interesting engineering problem — the one that actually determines whether AI findings help — isn’t “can the model find things.” Modern models can find plenty. It’s: can the things it finds live in the same world as everything else you already manage?

The hard part: one findings model

This is the part worth caring about.

In Intercept, AI-discovered and scanner-discovered findings differ by exactly one thing: where they came from. Everything downstream — triage, status, severity, scoring, compliance, alerting — is identical. That sentence is easy to write and hard to earn, so here’s how it’s built.

AI findings are kept in a store separate from your scanner results — and that separation is deliberate, because it buys two safety properties that matter more than they sound:

• AI findings survive a rescan. When Intercept rescans, it rebuilds the scanners’ own results from scratch. That rebuild never touches the AI findings, so a finding you triaged last week is still there after today’s scan. It persists.
• AI findings can’t be silently auto-closed. The logic that resolves a scanner finding when a scan stops reporting it only governs the scanners’ own results. A scan that never looked for your IDOR chain has no authority to declare that chain “fixed.” An AI finding is only ever closed by a human or an explicit action, never by a scanner’s silence.

So the storage is separate for safety. But the lifecycleis shared, and that’s the hero. Every AI finding you keep gets the same first-class resolution object a scanner finding gets. Same triage UI. Same statuses — open, fixed, accepted risk, false positive, mitigated, won’t-fix. Same severities — Critical through Low. The same finding categories the scanners use, too: SAST, secrets, dependencies, IaC, containers, pipeline, platform.

And — this is the part that makes it real rather than cosmetic — AI findings count toward your Intercept Score and your compliance controls. They’re folded into the same scoring and compliance evaluators as scanner findings, and the score updates immediately on ingest. An AI-discovered critical isn’t sitting in a side tab being ignored; it moves your posture the moment it lands, exactly as a scanner critical would.

That’s the whole thesis in one line: AI-discovered and scanner-discovered findings differ only by where they came from. Everything downstream is identical.

The four honest questions, answered straight

If you’ve been doing this long enough, four questions formed somewhere around the phrase “AI findings.” Here are straight answers.

1. Validation — does the AI mark its own homework?

No. And it’s important to be precise here: there is no automated server-side re-validation or confidence-scoring of AI findings. Intercept does not “verify” the model’s output for you, and anyone claiming their platform does should be asked exactly how.

What there isis a trust model with three layers that don’t pretend to be something they aren’t:

• Provenance over confidence. Every finding records who and what produced it — the producer, its version, the specific model, the scan recipe, and the exact git branch and commit. Notably, the ingest contract strictly rejects anything it doesn’t expect — including any confidence score or chain-of-thought the model tries to attach. Intercept deliberately refuses to store the model’s self-assessment, because a model’s stated confidence is not evidence.
• A quality bar in the scan recipe. The scan instructions tell the agent to report only what it can stand behind: quality over volume, lower the severity or omit entirely when unsure, one finding per discrete issue.
• Human triage. /intercept:triage re-verifies each finding against the actual code, so a person (assisted by the agent) makes the keep/clear call.

The honest framing is provenance plus human-in-the-loop, not the AI self-certifies.That’s a weaker claim than some vendors make, and it’s the correct one. It’s also worth noting whois doing the producing: the findings come from an agent the platform never had to trust with a long-lived credential — there’s no API key to issue, store, or leak (more on that connection model below).

2. Deduplication — won’t the AI just re-report what the scanner found?

This is well-designed, because the AI can’t cheat its way to a match. It invents its own rule identifier and has no idea what the scanner’s rule was called, so matching has to be rule-agnostic.

On ingest, Intercept computes the samecanonical, line-sensitive fingerprint a scanner produces. A new AI finding is considered to corroborate a scanner finding when it’s the same category at the same file and line within a ±2-line window. When that happens:

• the AI finding is suppressed and hidden from the primary list, and
• the scanner finding gets a “Confirmed by AI” indicator.

An AI-only finding — something no scanner produced — stays first-class.

Call this what it is: corroboration, not perfect dedup. It’s a heuristic (same-category, same-file, ±2 lines), and heuristics have edges. But it means the common case — AI re-confirming a known SAST hit — strengthens the existing finding instead of cloning it.

3. Provenance in the UI — can I tell origin at a glance?

Yes, by design. AI-discovered rows are marked with an “AI” badge. A row without it is scanner output — there’s no separate “Scanner” badge to hunt for; the absence of the AI badge is the signal. And when the agent independently confirms something a scanner already found, that scanner finding gets a small “Confirmed by AI” label. You never have to guess where a finding came from.

4. Signal vs. noise — and what about an auditor?

A few things keep the AI stream from becoming the noisy tab:

• Duplicate AI findings auto-suppress against scanner findings (see above), so corroboration doesn’t inflate counts.
• The scan recipe instructs the agent to report one finding per discrete issue — so if there really are 12 injection flaws, that’s 12 pinpointed, individually trackable findings, not one vague “multiple injection points” that hides how much is actually wrong.
• Abuse caps exist (batch limits and the like) but are invisible in normal use.

And for compliance specifically: the Scanner-only filter doubles as the audit-grade, reproducible view. An auditor who wants a deterministic, AI-free picture of your posture flips one filter and the AI findings are gone — same data, same lifecycle, just scoped to the reproducible scanners. You get the AI coverage anda clean compliance story; they don’t fight each other.

How it works in practice

Watch it work

Everything above is architecture. Here is what it actually looks like when the agent runs — and the tell that it isn’t a scanner with a language model stapled on is that, before it touches a single line of your code, it goes and does its homework.

Point Claude Code at a repo, run /intercept:scan, and the first thing it does is teach itself the job. It loads the Intercept scanning skills — the scan methodology, how to talk to the platform, how to read a stack — so it starts from a defined workflow instead of improvising one. Then it looks around and figures out where it is: three Python services, three Dockerfiles, a docker-compose file, Kubernetes manifests, and a local toolbox it can actually use (a running Docker daemon, trivy, grype, syft, checkov, the AWS CLI). No configuration. It detected the stack the way you would — by reading it.

Then comes the move that separates judgment from noise. Before hunting for anything, it reads your existing posture: it resolves the repo in Intercept and pulls the current grade and the open scanner findings — here, an unhealthy Grade F with 35 findings already on the board. It notices something a naive tool never would: a prior AI scan already ran at this exact commit. So it makes a decision a good engineer makes reflexively — don’t re-report what’s already known. It sets the existing scanner and prior-AI findings as a dedup baseline and deliberately steers toward genuinely new ground: how subprocess and ffmpeg commands get built, how file paths are handled, the model-driven content flow, the Dockerfiles, the Kubernetes ingress and secrets. It arrives already knowing what not to waste your attention on.

Ten minutes of reading in, the payoff — and it reads like an engineer’s handoff, not a scanner’s dump.

Fourteen net-new findings land in Intercept, AI-badged. The agent tells you plainly what it did to earn them: it read the whole codebase across all three services and traced taint from model- and API-response sources through to filesystem, subprocess, and network sinks. It built and scanned two of the three container images with trivy; the third — the frontend — failed to build on a missing directory, so rather than skip it silently, it scanned the exact base image the broken build would have used and wrote the build break into the finding.And it did not touch live AWS, because you didn’t consent to that — so it says so, and marks that portion of the analysis as static. Consent is a gate here, not a footnote.

The headline finding is the kind of thing that justifies the whole exercise: a path traversal where a model-controlled value flows through a sanitizer that turns out to be a no-op, into a file-write path that can escape onto a writable mount. That’s a cross-file, cross-function data flow — sink in one place, source in another, the “sanitizer” a third — the sort of chain a rule engine doesn’t assemble because no single rule spans it. Alongside it: an internet-facing load balancer serving everything over plaintext HTTP (TLS was clearly intended — there’s a certificate reference sitting in a comment — but never actually turned on), unpinned pip dependencies, an npm install fallback that quietly defeats lockfile reproducibility, and ten image CVEs, filed one finding per CVE.

Then the part you almost never see a tool do. Under a heading the agent labels “Logged caps (not silently dropped),” it tells you what it chose notto report and why. It filtered the image CVE noise down to fixable HIGH and CRITICAL. It found roughly a dozen more HIGH CVEs buried in a base image’s bundled npm dependencies — and it declined to file them individually, because the running service never invokes that code path, so their real exploitability is bounded. The point isn’t the judgment call itself; reasonable engineers can argue it. The point is that it made the call out loud, in writing, where you can see it and overrule it — instead of quietly inflating your backlog by twelve or quietly hiding a gap. That is the entire difference between a finding you can trust and a number you can’t.

And the baseline held. None of the fourteen collided with an existing scanner or prior-AI finding — zero suppressed — because it had read what was already there before it started. Coverage went up; noise didn’t.

That’s the behavior the rest of this section makes possible: an agent that asks before it acts, reads your posture before it adds to it, reasons across files no rule engine spans, and shows its work — including the work it decided to leave undone.

The agent runs with your access

The reason it reaches all this is almost boring, and it’s the whole point: it’s your Claude Code, on your machine, running as you. Not a vendor appliance peering in from outside — an agent standing where you already stand.

So it uses the tools already on your box — trivy, grype, syft, checkov, the Docker daemon — with nothing for Intercept to provision. And with your consent, it can use the sessions and credentials you’re already authenticated with: your internal package registry, a service behind the VPN, a staging environment, the cloud account read-only. That’s reach a hosted SaaS scanner structurally cannot have, because it lives outside your network and you’d never hand it those keys.

The ceiling is your access, not our integration list. It’s a general agent with tool use, so point it at more of what you can already reach. Consent-gated, read-only against anything live — it skipped live AWS earlier because you didn’t approve it. Same rule, everywhere.

The reporting path

Intercept runs a remote, OAuth 2.1 MCP server. Your AI client — Claude Code, in the current flow — submits a batch of up to 500 findings, and Intercept ingests them as AI-sourced. Each finding carries its category, severity, the model’s own rule identifier, a title, a description, the affected repository and file, line ranges, and the snippet of vulnerable code. The batch carries the provenance discussed above: the producer and its version, the model that produced it, the scan recipe and its version, the git branch and commit, and an idempotency key so a retried batch doesn’t double-report.

Two design choices in that contract are worth calling out, because scanned code is hostile input:

• The ingest contract is strict — it refuses anything it doesn’t expect at the edge, including, as noted, the model’s own confidence or reasoning.
• Titles and descriptions are sanitized and treated as data, not instructions — your repository may carry prompt-injection payloads in comments or fixtures, and the platform won’t act on them.

And reporting findings is only one of the things the agent can do. The connection is two-way: the agent can read your posture and act on it — pull the current findings, verify one against the code, leave a comment, change a finding’s status, trigger a rescan to prove a fix landed, and report new findings. That read-and-act depth is the difference between a one-way firehose and an agent that actually participates in your remediation workflow.

The connection: zero install, no API key

Here’s the part that should matter most to a security engineer, because it’s what most “AI integration” stories get wrong.

There is exactly one connection surface: a hosted, zero-install remote MCP server speaking OAuth 2.1 at https://intercept.hijacksecurity.com/mcp/ (the trailing slash is load-bearing). You install nothing. This is the successor to an earlier local, self-hosted package that required you to install software and manage a long-lived API key — that approach has been retired in favor of the hosted, browser-login server, and it’s a strictly better security posture.

The headline property: there is no API key. Nothing to copy out of a dashboard, nothing to paste into a config file, nothing to commit by accident, nothing to rotate, nothing to leak. Connecting is a browser login, not a secret hand-off:

claude mcp add --transport http intercept https://intercept.hijacksecurity.com/mcp/

Then, in Claude Code, run /mcp → a browser window opens → log in → Approve. That’s the whole flow.

Under that simple flow is an auth model worth three specific beats:

• The thing that holds your data never issues your credentials. Sign-in and data live in separate services: a dedicated identity service authenticates you and issues the session; the data connection only ever validates what that service issued. The component holding your findings is not the component minting access to them.
• A leaked web or API login can’t be replayed against the AI connection. A credential issued for the web app or the REST API simply won’t work against the MCP connection — each is scoped to its own surface. Even a valid, unexpired first-party token is rejected at the AI boundary, so the blast radius of a stolen token doesn’t cross surfaces.
• The agent is isolated exactly like the web app. The agent is held to the same tenant boundaries as the browser UI, enforced by the same machinery. There’s no second, weaker enforcement path that exists only for “the AI.”

Tokens are per-user and tenant-scoped at consent time — short-lived access, auto-refreshed, granted only to read and to act within that tenant. And disconnecting is fast and real: revoke access, and the agent loses it within roughly 30 seconds. No key sitting in a .envsomewhere that’s still valid until someone remembers to rotate it.

This is where the privacy story compounds. In this reporting flow the model runs on your machine, not Intercept’s — andthe connection never holds a standing credential to your data on the agent’s behalf; it’s a revocable, scoped, browser-granted session. Two of the usual “we added AI” liabilities — vendor-side model access to your source, and a sprayed-around API key — simply don’t exist here.

The plugin

On the client side, there’s a single Claude Code plugin named intercept (one plugin, not a series) that wires up the remote MCP server automatically and exposes six slash commands:

• /intercept:posture — score, grade, and per-category finding breakdown for the repo; also confirms the connection works.
• /intercept:scan — the deep AI scan that supplements your scanners, targeting image contents, live cloud/infra, and cross-file logic; records net-new findings.
• /intercept:triage — pull open findings and verify each against the code, tracing taint flow to clear false positives or confirm real ones. Works on scanner and AI findings alike.
• /intercept:fix— fix a finding end-to-end: confirm it’s real, apply the minimal root-cause fix, prove it with tests/build, mark it resolved. Handles code, base-image bumps for image CVEs, dependency bumps, and platform config.
• /intercept:hunt — natural-language hunt for a specific vulnerability class (auth bypass, tenant isolation, SSRF, insecure deserialization, business logic).
• /intercept:advise— pull the repo’s AI Advisors and verify each recommendation against your actual local code, returning a per-rec verdict with file:line evidence. Report-only — it never edits.

The plugin is the batteries-included path — it wires up that same MCP connection and adds all six commands in one install. It’s open source, on GitHub at hijacksecurity/claude-plugins (opens in a new tab).

claude plugin marketplace add hijacksecurity/claude-plugins
claude plugin install intercept@hijacksecurity
/mcp

Run /mcp, approve in the browser (the same no-API-key OAuth login shown above), and the six commands are live. If you’d rather wire just the MCP server without the plugin, the claude mcp add command earlier does that.

A note on scope, because it matters for trust: the agent deliberately stays in lane. It does not re-report repository secrets — that category is refused at the ingest boundary, so secret detection stays with your dedicated scanner — or repository dependency CVEs, which SCA already owns. It goes where the scanners can’t, and stays out of their way where they’re authoritative. No turf war.

The plugin is the on-ramp, not the ceiling

The plugin is a guided on-ramp — a curated scan recipe and a set of commands that set you up for success without having to think about any of this. But the recipe isn’t the product; the reporting engine underneath it is, and the plugin is just one client of it.

So if you’re the kind of team that already knows exactly what to hunt for — a bespoke detection your threat model demands, a check no off-the-shelf recipe runs — you can point your own AI client at that same MCP engine and report straight into it. Your findings land first-class: deduplicated, scored, corroborated against your scanners, triaged in the same model as everything else. The methodology is yours; the system of record is shared.

Where this is heading

The framing of “AI vs. traditional scanning” is going to age badly. It sets up a contest that misunderstands the problem. SAST, SCA, secrets, IaC, image, and pipeline scanners aren’t being replaced — they’re fast, deterministic, reproducible, and exactly right for the build gate. AI agents aren’t a better scanner; they’re a different vantage point — reasoning across your whole codebase, inspecting the artifacts you ship, reading your live cloud configuration, none of which a rule engine over source files can do.

This isn’t a bet only vendors are making. At DARPA’s AI Cyber Challenge (opens in a new tab), which concluded in 2025, autonomous systems found 18 real, previously-unknown vulnerabilities across more than 54 million lines of code and patched them in roughly 45 minutes on average — and several of the competing systems were open-sourced afterward. AI reasoning paired with existing tooling, working on real code at real scale, is where the field is already moving, not where one product wishes it would.

The future isn’t one or the other. It’s both, in one findings model — where a finding’s origin is metadata, not a wall. Where an AI-discovered IDOR chain and a scanner-discovered SQL injection share a status, a severity scale, a score, and a compliance evaluator, because they’re the same kind of thing: a security problem you have to decide what to do about.

The hard part was never adding AI. The hard part is the plumbing that makes static and AI one coherent system instead of two backlogs — the unified model, findings that survive a rescan and can’t be silently closed, rule-agnostic corroboration, a provenance-not-confidence trust model, and a connection surface with no standing secret to steal. That plumbing is where AppSec is actually heading. We think it’s where the category lands.

Try it

Intercept is in Early Access. If your threat model has outgrown what source-only analysis can see — image layers, live cloud posture, cross-file attack chains — and you don’t want that work landing in a second, ignored backlog, we’d like you in the program.