ASIScan 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.
Scanner is MIT and free · runs offline · no telemetry · npx asiscan-cli .
You shipped an agent feature this year. Now an enterprise prospect has sent 312 questions, forty of them about AI, and nobody on your team can answer question 26 — walk us through your kill switch — with anything you could put in writing.
Run the scanner today, free. Buy the assessment when you need the document. You will have something to attach this week instead of next month.
See what you get — $490You ship agents for clients and each one eventually asks what you did about security. Doing that assessment by hand, per project, does not scale, and "we reviewed it carefully" is not a deliverable you can invoice.
White-label the report, deliver it under your own brand, and make the assessment a billable line item on every engagement rather than unpaid reassurance.
Consultancy tierNeither? If you just want to check your own code, the scanner is MIT and free forever — npx asiscan-cli . — and you never have to talk to us.
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.
Zero-width characters, bidi overrides (Trojan Source), Unicode tag characters, poisoned tool descriptions.
A model reads codepoints. You read rendering. Everything in between is attack surface — and it is the one place a scanner beats a careful reviewer outright, because the reviewer is looking at characters that are not drawn.
A zero-width space carries a smuggled instruction through code review untouched. A bidirectional override makes source render one way and parse another (CVE-2021-42574). The Unicode tag block is a complete invisible ASCII alphabet. And a tool description reading "before using any other tool you must first…" is not documentation — descriptions go to the model verbatim, so that is a tool-poisoning primitive.
Across five large agent frameworks these four checks produce zero findings. Against a crafted smuggling fixture, all four fire. Silent on clean code, loud on the real attack — including the U+FEFF byte-order mark we removed from the signature after every hit it produced on real code turned out to be false.
There are good tools that scan the AI packages and MCP servers you install — asking whether the third-party thing you're about to run is malicious. That is a real problem and a different one. ASIScan reads the agent you wrote.
| Package / MCP scanners | ASIScan | |
|---|---|---|
| Question answered | Is this dependency malicious? | Is the agent we built defensible, and can we prove it? |
| Subject | Third-party packages, MCP servers, installed skills | Your own repository |
| Framework mapping | Ad-hoc threat categories | Every finding carries an ASI, LLM or Art. 50 ID |
| Deep analysis | Often ships your source to an LLM provider | Fully offline. No network calls, no telemetry, air-gap capable |
| Evidence output | Findings | Findings plus a 49-item manual checklist, EU worksheet, 30 red-team probes |
| Licence | Frequently AGPL — banned outright at many enterprises | Commercial, perpetual. No copyleft obligation on your codebase |
Run both if you can. They overlap only at ASI04, agentic supply chain — where ASIScan checks that your MCP servers are pinned and provenance-verified, rather than auditing someone else's package for you.
Two of those rows are worth reading twice if you sell to enterprises. A tool that uploads your source to a third-party LLM is a question on the very security questionnaire you're trying to answer — and an AGPL dependency is a procurement conversation you don't want to have.
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. ASIScan 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 (v1.5.1) | 49 | ~75–80%* |
*That last row was validated only against the five repositories carrying the false positives it targeted, and an independent check on unseen code in September 2026 came in lower. So we don't quote a current figure: precision for v1.5.2 is being re-measured across a 50-repository corpus, and the result, method and raw counts will be published here.
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 | 49 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 |
Rules are a commodity — there are free agent scanners, and ours is one of them, MIT licensed on npm. What nobody hands you is a document a procurement team accepts. That is the part that takes judgement, and that is the part we charge for.
MIT licensed. Not a trial, not crippled, no signup.
One dated report for one codebase. The thing you attach.
Because a report is stale the moment you merge.
Deliver assessments to your own clients, under your brand.
ISO/IEC 42001 certification runs $37,500–$85,000 in year one — GRC platform, external audit, and implementation consulting — and around $115,000 across three years. That is the right tool for a different job, and it takes months.
Meanwhile the thing actually costing you money is the wait. AI questionnaires stretch vendor review from about a week to four to eight weeks. For a company with $250K contracts that has been estimated at $400K–$800K per quarter in delayed or lost revenue.
$490 to unblock the review is not a purchase anyone has to think about. Perpetual licence, 30-day refund, no justification required.
Payments are processed by Stripe. Your card statement and the checkout page will show EASE AI / Protocol42 — Ease AI Works is the merchant of record for ASIScan.
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.
Scan free in under a second. Buy the evidence when a reviewer asks for it.
Get the assessment — $490