Frequently asked questions

It reads the source code of an AI agent application and flags patterns that map to known agentic security risks — the OWASP Top 10 for Agentic Applications (ASI01–ASI10), the OWASP Top 10 for LLM Applications, and EU AI Act Article 50 transparency obligations. It outputs a terminal report, a markdown evidence document, JSON, or SARIF for GitHub code scanning.

It also ships the paperwork half: a 49-item manual review checklist, an EU AI Act readiness worksheet, and 30 red-team probes mapped to risk IDs.

Because it has no concept of a tool call, a system prompt, or agent memory. Semgrep and friends were designed for a threat model that predates agents. Shown an agent that interpolates a retrieved document into its system prompt, a generic scanner sees valid string concatenation and moves on.

The risks are also structurally different. Most agentic risk is 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. ASIScan models that directly.

Partly, and we say so in the README rather than hiding it. The design contribution is the two-probe model. Presence probes flag genuinely dangerous constructs. Control probes fire only when your code demonstrably performs a risky behaviour and no evidence of the mitigating control appears anywhere in the project. Trigger without control is the finding.

Comments never count as evidence of a control. A // TODO: add sandboxing comment must not make a security scanner report you as mitigated — that was a real bug we found in our own tool during testing, and it's the kind that gives a false all-clear exactly when someone has written down that they're worried.

We're re-measuring it, and won't quote a current figure until that's done. Version 1.5.2 is being measured across a 50-repository corpus of open-source agent code, with every finding in a random sample reviewed by hand. The result, the method and the raw counts will be published here — expect roughly one finding in several to be something you dismiss, which is normal for static analysis.

It got there in rounds, each one hand-reviewed: untuned it was ~4% precision at 792 findings; tuning took it to ~55%; expanding the corpus to ten repositories took it to ~62%; adding file-level context gating took it to ~69%; and a final pass of targeted fixes took it to 75–80%. That last figure was validated against the five repositories carrying the false positives it targeted rather than re-measured across all ten, and an independent check on unseen code in September 2026 came in lower — which is why it is being re-measured.

For context: published benchmarks put untuned commercial SAST at 60–90% false positives, dropping to 10–20% once tuned for a stack, and SonarQube at 40–60% of findings requiring developer review. A ~25% false-positive rate is the well-tuned commercial band. The difference is that ours is measured against named public repositories and reproducible, not asserted in a datasheet. No other scanner in this category publishes its rate at all — that's worth asking them about.

Worth knowing, because they're the failure modes every regex-based scanner has:

We were flagging url.startswith(('http://', 'https://')) — that's scheme-validation code, meaning the scanner was reporting the security control as the vulnerability. 475 findings. We were matching placeholder credentials like api_key='your_vercel_api_key'. We were matching sensitive words inside log strings rather than logged values. We were matching "YOLO" the object-detection model inside recorded test fixtures. And we were flagging JavaScript's regex.exec(text) as process execution.

Two more were worse than noisy. We were treating test files as production code — config_test.py and test_routes.py are full of deliberately fake secrets and example URLs, and they accounted for roughly two thirds of all findings across a ten-repository corpus. And we were matching xmlns="http://www.w3.org/2000/svg" as a network endpoint: 56 findings in a single icon file.

All fixed, all covered by regression tests.

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 carry 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. In the US your buyer's procurement team is effectively the regulator; in Canada, PIPEDA already covers automated decisions about people and federal procurement expects a documented algorithmic impact assessment; in the UK, the ICO, FCA and MHRA each expect sector-appropriate evidence with NCSC secure-AI guidance as the de-facto baseline.

The EU worksheet is one module in the box. Use it if you sell into the EU, ignore it if you don't — the security case is identical either way.

It will. A clean report means "nothing detectable from source" — it does not mean secure, and we've written that into the terms rather than burying it.

The Software is provided without warranty and our liability is capped at what you paid. See sections 9–11 of the Terms. If you need assurance rather than tooling, you need a penetration test by a qualified assessor — a different product at a different price.

That said, please report misses. False-negative reports are the most valuable feedback we receive.

Yes. Add an inline directive on the line:

const cmd = build(choice); // asiscan-ignore ASI05 reviewed: choice is an enum

Works in //, #, and /* */ comments. The rule ID and reason aren't parsed, but write them anyway — an unexplained suppression is indistinguishable from someone who got bored.

Suppression applies to presence probes only. A control probe asks whether a mitigation exists anywhere in the project, which isn't a question one line can answer.

It scans TypeScript, JavaScript, Python, Go, Rust, Java, C#, and PHP, plus JSON, YAML, TOML, shell scripts, and Dockerfiles.

Rule coverage is strongest on TypeScript, JavaScript, and Python, where most agent code lives today. A polyglot test fixture asserts that ASI01, ASI03, and ASI05 fire correctly in Python, C#, and Go — that claim is enforced by the test suite rather than asserted in marketing.

No. It runs entirely offline, makes no network calls, and has no telemetry, analytics, or licence phone-home. You can run it on an air-gapped machine.

You get the full source, so you can verify this rather than trust it. See the Privacy Policy.

Node 18 or later. Unzip, npm install && npm run build, and run. A 2,000-file repository scans in a few seconds.

Yes. A GitHub Actions workflow ships with it — PR gate, job-summary report, weekly scheduled re-scan, and SARIF output. Exit codes are configurable via --fail-on so you can gate on critical findings only while you work through a baseline.

One caveat worth knowing in advance: uploading SARIF to the GitHub Security tab requires GitHub Advanced Security on private repositories. It's free on public ones. The workflow treats that upload as best-effort and archives the SARIF as a build artifact either way.

Scanner — free. MIT licensed, on npm. All 18 rules, every output format, the CI gate. Not a trial and not crippled. If you only want to check your own code, stop here.

Assessment — $490 once. One dated, scoped assessment report for one codebase, plus the NIST AI RMF / ISO 42001 crosswalk, the questionnaire answer pack, the 49-item manual checklist, the EU AI Act worksheet and the red-team probes.

Continuous — $2,400/year. Everything above, unlimited repositories and re-scans, a re-issued and re-dated report every quarter with a drift diff, and a hosted trust page you can point buyers at. Most teams land here, because a report is stale the moment you merge and reviewers increasingly want evidence dated within the last 6–12 months.

Consultancy — $6,000/year. Everything above, plus the right to run assessments in paid client engagements and deliver white-labelled reports to third parties. If you are handing reports to clients, you need this tier; the others do not permit it.

Full terms in section 3.

No — and be suspicious of any tool that claims otherwise.

Compliance is a legal determination that requires a documented assessment by qualified professionals. What ASIScan gives you is the engineering-side evidence and a worksheet that gets your lawyer the facts they'll ask for: scope, classification, Article 50 controls, and the ten technical documents auditors request first.

Article 50 transparency obligations became enforceable on 2 August 2026. The synthetic content marking obligation was extended to 2 December 2026. Verify current status independently — regulatory dates move, and this page is not legal advice.

No. Section 5 of the Terms permits use only against systems you own or hold documented written authorisation to test. Breach terminates your licence immediately and without refund.

This isn't boilerplate — it's the clause that separates lawful use from a computer-misuse offence, and you are responsible for holding the authorisation.

30 days, no justification required. Email hello@protocol42.io from your purchase address and we'll process it to the original payment method, normally within five business days.

We'd rather refund you than have you feel stuck with something that didn't help.

Don't trust it — run it. The test suite ships with the product and reproduces every number on the sales page. Two reference agents, one deliberately unsafe and one properly secured, let you verify sensitivity and specificity yourself in about a minute.

Then there's the 30-day refund. And the fact that we publish our precision rate, our false-positive history, and an explicit list of what the tool cannot do — which is not what you'd do if the goal were to oversell it.

It reads source, not behaviour. It cannot see your IAM policy, network topology, runtime configuration, 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's regex-based, not AST-based. It will miss things a compiler wouldn't, and unusual formatting can fool it.

It covers roughly half the ASI Top 10. The rest is architecture, runtime config, and process. That's exactly why the manual review checklist ships with it — the scanner is not sufficient on its own, and we'd rather say that than let you discover it.