An AppSec agent that verifies before it accuses.

It is a review methodology plus a contract, executed by a model with tool access. Three properties separate it from “ask an LLM about my code”:

Bounded scope

The run is scoped to a repository or environment you own or are explicitly authorized to test, in a declared mode (STATIC, LOCAL, STAGING, PRODUCTION_SAFE). It is not internet scanning.

Structured outcomes

Every check resolves to APPLICABLE, NOT_APPLICABLE, UNKNOWN or BLOCKED. “We could not check this” never renders as “this is fine”.

Adversarial verification

A second pass tries to refute each candidate: attacker control, reachability, whether the vulnerable state is producible at all, whether a compensating control already blocks it.

They are good at different things, and the honest answer is that you want both. A scanner is deterministic, fast, cheap to re-run, and unbeatable at the classes it encodes. An agent can reason across a call graph about intent, but it is slower, non-deterministic, and will sometimes be confidently wrong.

The other axis is runtime evidence. A typecheck can be green while the browser flow is broken, and unit tests can pass while a real database constraint or an authorization boundary behaves differently. An agent operating in LOCAL mode can require proof at the layer where the invariant actually lives — a request that should be refused, a constraint that should fire — rather than inferring it from source. A scanner cannot ask for that; a human reviewer usually does not have time to.

SecHelix does not replace scanners. It consumes their output through read-only adapters and treats every alert as a hypothesis until something supports it. If your problem is “which of my 400 Semgrep alerts are real”, that is the shape this is built for. If your problem is “am I running a vulnerable version of a library”, run the scanner.

Coverage is a 546-item catalog: 21 security families across 26 verification lenses. Each record is a review question with a stable id, not a claim. The families that get the most depth, and the page that goes into each:

Injection and dataflow, SSRF, file uploads and parsers, secrets and supply chain, authentication and sessions, and the browser boundary are all in the catalog as well; they are covered in the documentation rather than given pages of their own.

SecHelix ships as a portable SKILL.md Agent Skill plus contracts, so it runs wherever Agent Skills are supported. Compatibility is recorded per host, and the distinction between verified and documented is kept deliberately:

Yes, as source review. Routes, handlers, middleware and their authorization decisions are exactly where the authorization and business-logic lenses do their work — the common finding is not a missing check but a present check on one path and an absent one on another that reaches the same object.

What it does not do by default is send traffic. Dynamic verification happens only in a mode you declare and authorize: LOCAL against your own running app, STAGING against an allowlisted non-production environment. There is no mode in which SecHelix probes a third party.

By trying to produce them and then killing them. Every candidate goes to an independent verifier prompted to attack the claim, not to double-check it. The verifier receives the claim without the narrative that produced it.

• Attacker control was never establishedThe dangerous sink is real, but nothing reachable by an attacker reaches it.
• A compensating control already blocks itThe framework, a middleware, or a database policy neutralises the payload before it matters.
• The vulnerable state is not producibleThe path requires a combination of preconditions that the application cannot reach.
• The severity does not survive questioningReal, but the realistic outcome is smaller than the label implies — so the label changes.

A candidate that fails verification is recorded as FALSE_POSITIVE with the refutation reasoning kept. The worked example is in the argument for disproving your own findings: a remote value reaching href with only .trim() — the exact shape a scanner reports as high-severity XSS — refuted because the framework rewrote the payload and attacker control was never shown.

Good fits:

• Triaging a scanner report where most alerts are probably noise and you need the few that are not.
• Reviewing a change to authorization, payments, or an agent tool boundary before it ships.
• Auditing a codebase written largely with AI assistance, where the failure shapes are ordinary AppSec but the volume is new.
• Producing a regression test that proves a fix, rather than asserting one.

Poor fits — say so before someone finds out the hard way:

• Dependency and CVE inventory. Use a scanner and an SBOM; that is a solved, deterministic problem.
• Compliance evidence that must be identical run to run. An agent is not reproducible in that sense.
• Anything you are not authorized to test. Authorization is a precondition recorded in the scope, not a formality.
• Replacing human review. The output is evidence for a reviewer, and High/Critical findings still require a person.

Blind label suite

MEASURED — precision 0.950, detection recall 1.000, false-positive rate 0.053, FP rejection 0.947, counts TP 38 · FP 2 · TN 36 · FN 0.

Full SecHelix workflow

NOT_MEASURED — applicability accuracy, verifier effectiveness, regression-proof rate and release-gate accuracy have never been measured end to end.

Real-world evidence

One published case study, an owner self-audit. See case studies.