AgentAudit is static analysis built for AI agents. It audits your codebase against the OWASP Top 10 for Agentic Applications, the OWASP LLM Top 10, and EU AI Act Article 50 — then hands you the evidence document you attach when an enterprise customer sends you a security questionnaire asking how you secured your AI features.
Node 18+ · runs offline · no telemetry · one-time payment
OWASP published the Top 10 for Agentic Applications in December 2025 and refreshed the GenAI LLM Top 10 on 3 August 2026. Every engineering lead who shipped an agent this year is now expected to show they've assessed against frameworks that are months old — using scanners designed for a threat model that predates agents entirely.
Generic SAST has no concept of a tool call, a system prompt, or agent memory. It sees valid code and moves on.
The dangerous patterns look ordinary. A standing admin token and a scoped one are one line apart.
"Describe the security controls applied to your AI/LLM features." There is no standard answer yet. Deals stall in that gap.
OWASP is not a jurisdiction. The ASI Top 10 describes how agents actually get attacked — prompt injection through retrieved content, a tool with a standing admin token, a shell string built from model output. None of that becomes safe because your company is in Ohio. Here is the reason to run this where you are.
Your buyer's procurement team is the regulator. SOC 2 and enterprise security questionnaires now carry AI-specific sections, and auditors are asking which framework you assessed your AI features against. "We reviewed it internally" is not an answer that closes a six-figure deal. An ASI Top 10 report is.
PIPEDA already applies to automated decisions about people, and federal procurement expects a documented algorithmic impact assessment. Most Canadian teams also sell into the US and EU, which means you inherit the strictest questionnaire you receive — usually before you have anything to answer it with.
The UK took a regulator-led route rather than a single AI act, so the ICO, FCA and MHRA each expect sector-appropriate evidence. NCSC guidance on secure AI development is the de-facto baseline, and it maps cleanly onto the same controls. UK teams selling into the EU pick up Article 50 regardless of where they're incorporated.
The sharpest deadline, and the reason this exists: Article 50 transparency became enforceable on 2 August 2026, with synthetic-content marking following on 2 December 2026. The included worksheet covers scope, classification, and the documents an assessor asks for. It is one module of the product, not the whole pitch.
The security case is the same everywhere. The paperwork differs, so the paperwork ships as a separate worksheet you use only if it applies to you.
The interesting part is how it checks. Agentic risk is usually a
missing control, not a forbidden token. Code isn't unsafe
because it calls exec — it's unsafe because it calls
exec on a model-influenced string with no sandbox and no egress policy.
Retrieved content reaching the system prompt undelimited.
Unvalidated tool parameters; no allowlist or authorisation policy.
Hardcoded and non-expiring credentials; agents on standing tokens.
Unpinned MCP servers, missing AIBOM, no provenance verification.
Shell strings built by interpolation; code tools with no sandbox.
Unscoped memory across tenants; writes with no validation or TTL.
Unauthenticated handoffs; no signing, no replay protection.
Unbounded loops; no circuit breaker, retry cap, or timeout.
Bypassed approval gates; irreversible actions with no confirmation.
No audit log, no kill switch, no cancellation path.
Prompt injection, disclosure, output handling, excessive agency, consumption.
Missing AI-interaction disclosure; unmarked synthetic content.
Two reference agents ship in the box — one deliberately unsafe, one properly secured.
Every claim here is reproducible with npm test on your own machine.
| Fixture | Findings | Controls recognised |
|---|---|---|
| vulnerable-agent 60 lines, deliberately unsafe | 26 | 0 |
| secure-agent reference implementation | 0 | 5 |
A scanner that flags everything is noise. One that flags nothing is decoration. Sensitivity and specificity are both tested, and both are in the test suite.
Fixtures prove a scanner can fire. They don't prove it's usable. AgentAudit was tuned in rounds against fifteen open-source agent frameworks — roughly 17,000 source files — with every surviving finding reviewed by hand.
| Tuning round | Findings | Precision |
|---|---|---|
| Untuned — 5 repos, ~3,100 files | 792 | ~4% |
| Tuned — same 5 repos | 36 | ~55% |
| Expanded to 10 repos, ~14,000 files | 89 | ~62% |
| + file-level context gating | 78 | ~69% |
| + targeted fixes (current) | 49 | ~75–80% |
The last row is labelled the way we'd want it labelled if we were buying: those fixes were validated against the five repositories that carried the false positives they targeted, not re-measured across all ten. Treat ~75% as the working figure and 80% as the best case.
Among the false positives removed: flagging url.startswith(('http://','https://'))
— scheme-validation code, i.e. reporting the security control as the vulnerability, 475 findings.
Matching xmlns="http://www.w3.org/2000/svg" as a network endpoint.
Matching JavaScript's regex.exec(text) as process execution. And
treating test files as production code — they were two thirds of all findings in round two.
Published benchmarks put untuned commercial SAST at 60–90% false positives, dropping to 10–20% once tuned for a specific stack. SonarQube reports 40–60% of findings requiring developer review.
A ~20–25% false-positive rate is the well-tuned commercial band. The difference is that this number is measured, published, and reproducible against named public repositories rather than asserted in a datasheet. No other scanner in this category publishes theirs — you should ask them why.
It reads source, not behaviour. It cannot see your IAM policy, network topology, runtime config, or what your model actually does at inference time.
Control probes are project-wide: if a mitigation exists anywhere, the rule stays quiet — even if it isn't applied on the path that needs it. A clean result is weaker evidence than a dirty one.
It is regex-based, not AST-based. It is not a certification, not a conformity assessment, and not legal advice.
The manual review checklist ships with it precisely because the scanner is not sufficient on its own. Anyone selling you an AI compliance scanner without that caveat is selling you a false sense of security.
Static analysis covers roughly half the ASI Top 10. The rest is architecture, runtime configuration, and process. So the other half of the box is the paperwork you'd otherwise spend a week writing.
| Component | What it is |
|---|---|
| CLI scanner | 18 rules, 4 output formats — terminal, markdown, JSON, SARIF 2.1.0 |
| GitHub Action | PR gate, uploads to the GitHub Security tab, weekly scheduled re-scan |
| Manual review checklist | 47 checks with severity and an evidence column, covering what source can't show |
| EU AI Act worksheet | Scope, classification, Art. 50 controls, and the 10 documents auditors ask for |
| Red-team probe suite | 30 adversarial probes as JSONL, mapped to risk IDs, with pass/fail signals |
| Reference agents | A vulnerable and a secured implementation, annotated line by line |
| Full TypeScript source | Readable, commented, and yours to extend with your own rules |
Perpetual license, free updates through v1.x. If it doesn't find something worth fixing in your agent codebase, email within 30 days for a full refund.
One codebase, unlimited developers at your company.
Unlimited codebases in one company, up to 25 developers.
Use it in paid client engagements, under your own brand.
Partly, and the README says so plainly. The design contribution is the control-probe model: a rule fires only when your code demonstrably performs a risky behaviour and no evidence of the mitigating control appears anywhere in the project. That maps to how the ASI list is actually written — most entries are missing-control findings. It also deliberately excludes comments from counting as evidence, so a // TODO: add sandboxing can't make the scanner report you as mitigated.
It scans TypeScript, JavaScript, Python, Go, Rust, Java, C#, PHP, plus JSON, YAML, TOML, shell, and Dockerfiles. Rule coverage is strongest on TS/JS and Python, where most agent code lives today. Rules are plain objects — extending them for your stack is a small diff, and the guide is included.
No. It runs entirely offline, makes no network calls, and has no telemetry. You can verify that in the source, which you get.
Because the EU AI Act is the smallest reason to. The OWASP ASI Top 10 describes how agents get attacked, and that threat model doesn't stop at a border — a shell string built from model output is a command-injection primitive in Toronto, Austin and Manchester alike.
The commercial reason is more immediate: enterprise security questionnaires and SOC 2 reviews now include AI-specific sections, and "we reviewed it internally" doesn't clear them. A scan report naming the framework you assessed against, plus a completed manual checklist with an evidence column, is a document you attach and move on. That's revenue protection, not compliance cost. The EU worksheet is one module in the box — use it if you sell into the EU, ignore it if you don't.
No, and be suspicious of any tool that claims it does. Compliance is a legal determination requiring a documented human assessment. What this gives you is the engineering-side evidence and the worksheet that gets your lawyer the facts they'll ask for. That's the honest scope.
Don't trust it — run it. The test suite is included and reproduces every number on this page. The two reference agents let you verify sensitivity and specificity yourself in about a minute. And there's a 30-day refund if it doesn't earn its keep.
Email it. Rules are data, not hardcoded logic — most fixes are a one-line regex change that ships in the next v1.x update, which you get free.
One command. Runs in under a second. Perpetual license.
Get AgentAudit — $149