ALGIS Documentation

Everything you need to understand how ALGIS works, what it finds, and how to get the most out of it.

Introduction

ALGIS is an AI-powered security scanner that finds security problems in your code, configuration files, and running websites, then explains each issue in plain language and gives you a precise, working fix.

Most security tools produce a long list of warnings with technical jargon. ALGIS is different: it acts like a senior security engineer reviewing your project. For every issue it finds, you get a clear explanation of what the problem is, why it is dangerous, and exactly how to fix it, including a corrected code snippet.

Who is it for?

Solo developers and indie hackers

Cannot afford a dedicated security consultant. Get pro-grade analysis at a fraction of the cost.

Small teams shipping quickly

No dedicated security person on staff. Run a scan before every release instead.

Non-security specialists

Want a plain-English answer to: "Is my code safe?" No prior security knowledge needed.

You do not need to know what SQL injection or SSRF is to use ALGIS. The tool explains everything it finds.

Quickstart

There are three ways to start a scan. All three return the same type of report. Pick whichever fits your situation.

Option 1: Paste code

Open the live scanner on the homepage. Paste any code, a single file, a configuration block, or even a short snippet. Click Scan. Results appear within seconds.

This is the fastest way to check a single file. Good for: checking a deployment config before you ship, reviewing a new dependency's source, or getting a second opinion on code you just wrote.

Option 2: Upload files

Upload a zip archive of your project folder. ALGIS scans every file in the archive and cross-references findings across files. For example, a secret in one file may be flagged in the context of how it is used in another.

You do not need to upload your entire repo. Zip just the source folders you want scanned. Exclude large directories like node_modules or .git.

Option 3: Scan a URL

Enter any public URL. ALGISsends a real HTTP request to the site, inspects the response headers, cookies, TLS configuration, and visible page content. This is the fastest way to check a live website's security posture without touching source code.

What you get back

Every scan produces a report with:

  • A summary dashboard: total findings by severity, and a single security score.
  • A list of findings, each with a severity badge, category, file and line reference, plain-English explanation, danger description, and step-by-step fix.
  • A corrected code snippet where applicable.
  • The ability to mark findings as resolved as you work through them.

How scanning works

ALGIS uses a three-layer pipeline. Each layer does a specific job. This design is faster, cheaper, and more accurate than sending everything to one AI model.

The key insight: deterministic tools catch known patterns instantly, a small AI model removes the noise, and a large AI model does the actual explaining and fixing. Each layer is used only where it excels.
INPUT: code / files / url
Layer 1
Deterministic
Fast, rule-based. No AI cost.
  • Secret pattern matching
  • Static analysis (SAST rules)
  • Dependency CVE lookup
  • URL header / TLS probe
Layer 2
AI Triage
Fast model. Cleans the signal.
  • Removes false positives
  • Groups duplicates
  • Ranks by real-world risk
Layer 3
AI Deep Analysis
Capable model. Explains and fixes.
  • Plain-English descriptions
  • Why it is dangerous
  • Step-by-step fix
  • Corrected code snippet
REPORT

Layer 1: Deterministic scanners

The first layer runs fast, rule-based tools that have no AI cost. These tools look for known patterns, such as the structure of an AWS access key, a dangerous SQL query construction pattern, or a CVE-flagged package version.

This layer is exhaustive and intentionally over-inclusive. It is fine if it flags something that turns out not to be a real problem, because the next layer exists to clean that up. Speed and coverage are the priorities here.

  • Secret pattern matching: regex patterns for AWS keys, GitHub tokens, Stripe keys, generic high-entropy strings, and hundreds more.
  • Static analysis: Semgrep-style rules for injection vulnerabilities, unsafe function calls, and insecure coding patterns.
  • Dependency CVE lookup: compares your package manifest against the OSV (Open Source Vulnerability) database and the National Vulnerability Database.
  • URL probing: for URL inputs, sends an HTTP/HTTPS request and inspects headers, cookies, TLS certificate, and redirects.

Layer 2: AI triage

The second layer is a fast, lightweight AI model. It reads the raw findings from layer 1 along with the surrounding code context, then does three things:

  • Removes false positives. For example, a regex pattern might flag a test fixture that contains a mock API key. The triage model looks at context and removes it.
  • Groups duplicates. The same underlying issue may appear in 20 places. The triage model groups them so the final report is not cluttered.
  • Ranks by real risk. Not all critical patterns are equally dangerous in context. The triage model re-orders findings by actual exploitability.

Security scanners are infamous for alert fatigue, where so many warnings fire that developers start ignoring all of them. Layer 2 exists to prevent this.

Layer 3: AI deep analysis

The third layer is a larger, more capable AI model. It takes the confirmed, ranked findings from layer 2 and, for each one, generates:

  • A plain-English description of what the issue is.
  • A clear explanation of the real-world danger if this is exploited.
  • A numbered list of steps to fix it.
  • A corrected code snippet showing exactly what the safe version looks like.

This is the part that sets ALGIS apart. Finding a problem is only half the value. Explaining it and providing a working fix is what turns a scan report into actionable guidance, especially for developers who are not security specialists.

The deep analysis layer (Layer 3) runs on Anthropic Fable 5, Anthropic's newest and most capable model. This is what makes ALGIS explanations and fix suggestions genuinely good. Layer 2 (triage) runs on Anthropic fast tier for speed and cost efficiency. External non-AI scanners (Semgrep, OSV/CVE database, secret-pattern sets) feed the models grounded facts so they do not hallucinate.

Why these models

The model choices are intentional. Here is the reasoning behind each one.

Why Fable 5 for deep analysis

Good security output is genuinely hard to produce. The model has to read code in context, judge whether an issue is actually exploitable in that specific codebase, explain it clearly to a non-specialist, and write a correct, working fix. Weaker or older models give generic or wrong advice. Anthropic Fable 5 is Anthropic's newest and most capable model for this kind of structured reasoning. It is also grounded with real scanner findings (Semgrep output, CVE records, secret-pattern matches) rather than being asked to guess from scratch. That combination is what makes the explanations trustworthy and the fixes usable.

Why Anthropic fast tier for triage

False positives are the number one problem with security tools. A cheap, fast model filters the noise, removes false positives, and groups duplicates before the expensive model runs. This keeps reports clean, response times short, and costs low. The fast model does not need to reason deeply; it needs to be consistent and quick.

Why two AI models instead of one

Running the strongest model on every raw pattern match would be slow and expensive. Running only a cheap model would give shallow, untrustworthy explanations. Layering deterministic scanners, then fast triage, then deep analysis gives the best accuracy per dollar and the fastest end-to-end result. Each layer is used only where it excels.

Why Anthropic

Strong code reasoning and a low hallucination rate on grounded tasks. The models work well when given concrete, structured inputs (a specific code snippet, a known CVE, a matched pattern) rather than open-ended questions. That is exactly how ALGIS uses them.

Inputs

ALGIS accepts four types of input, all available now.

Code / text

Paste any text directly into the scanner. This can be a complete file, a function, a configuration block, an environment variable file, or even an unstructured snippet.

What it looks for: hardcoded secrets, injection vulnerabilities, insecure coding patterns, bad crypto usage, and PII in plaintext.

Language detection is automatic. Supported languages include JavaScript, TypeScript, Python, Go, Ruby, Java, PHP, C, C++, C#, Rust, and configuration formats (YAML, JSON, TOML, Dockerfiles, .env files).

Files and zip archives

Upload a zip file containing your project. ALGIS recursively scans every source file in the archive. Cross-file analysis allows it to trace how a secret defined in one file is used in another, or how a dependency declared in package.json is actually imported and used.

What it looks for: everything in the code/text category, plus dependency risks from your package manifest files.

Exclude node_modules, .git, build output folders, and binary assets before zipping. This keeps the upload small and fast, and avoids scanning thousands of files in your dependencies (the dependency risk check reads your manifest file, not the installed packages).

URL / live site

Enter a URL starting with https:// or http://. ALGIS connects to the live site and inspects:

  • HTTP response headers: checks for Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy.
  • Cookie flags: checks that all cookies have the Secure, HttpOnly, and SameSite attributes set appropriately.
  • TLS configuration: validates the certificate, checks for expired certs and weak cipher suites.
  • Information leakage: server headers that reveal software names and versions, verbose error pages, directory listings.
  • Third-party trackers: detects analytics and advertising scripts loaded over plain HTTP, which can be intercepted.
URL scanning only inspects the publicly visible HTTP response. It does not log in, fill forms, or scan authenticated pages. For a full scan of a web application, upload the source code.

Repo connect

Connect a GitHub, GitLab, or Bitbucket repository. Once connected, ALGISscans the full repository including commit history (for accidentally committed secrets that were later removed), dependency graphs, and CI/CD configuration files.

Repo connect is part of the paid plans.

Detection categories

Every finding is assigned to one of seven categories. These categories appear as filter options in the report, and as the category field in the API.

Exposed secrets

exposed-secrets

Finds API keys, tokens, passwords, private keys, and database connection strings hardcoded anywhere in your code or config files.

Examples

  • AWS access key and secret hard-coded in source
  • Stripe secret key in a .env file committed to git
  • Database password in a config.js file
  • GitHub personal access token in a script

Vulnerabilities (SAST)

vulnerabilities

Static analysis catches common code-level vulnerabilities: injection flaws, unsafe output, insecure file handling, and more.

Examples

  • SQL injection: user input passed directly to a query
  • Cross-site scripting (XSS): user data echoed into HTML without escaping
  • Command injection: shell commands built from user input
  • Path traversal: file paths constructed from user-supplied data
  • Server-side request forgery (SSRF)
  • Insecure deserialization of untrusted data

Dependency risks

dependency-risks

Scans your package files (package.json, requirements.txt, Gemfile, etc.) against the OSV and CVE databases to find known-vulnerable library versions.

Examples

  • npm package with a known remote code execution CVE
  • Python library with an open security advisory
  • Outdated dependency with a public exploit available

Bad configuration

bad-config

Finds insecure settings that are commonly left in place during development and accidentally shipped to production.

Examples

  • Debug mode enabled in a production config
  • CORS set to wildcard (allow all origins)
  • Missing authentication on admin endpoints
  • Default credentials left unchanged
  • S3-style bucket with public read/write access

Insecure crypto

insecure-crypto

Detects use of cryptographic functions that are considered weak or broken, as well as common implementation mistakes.

Examples

  • MD5 or SHA-1 used for password hashing
  • AES in ECB mode (same input always produces same output)
  • Hardcoded initialization vector (IV) for encryption
  • No salt added to password hashes
  • Random number generator seeded with a predictable value

Data leaks / PII

data-leaks

Identifies personal or sensitive data that appears in code or is returned in API responses when it should not be.

Examples

  • Email addresses hardcoded in test fixtures or seed data
  • Credit card numbers appearing in logs or responses
  • Social security numbers or national IDs in source code
  • Full names and addresses stored in plaintext

Web hygiene (URL scans)

web-hygiene

For URL scans, checks the live HTTP response for missing security headers, insecure cookies, information leakage, and third-party tracker presence.

Examples

  • Missing Content-Security-Policy (CSP) header
  • Missing HTTP Strict Transport Security (HSTS) header
  • Cookies set without the Secure or HttpOnly flag
  • Server header revealing software version
  • Error pages exposing stack traces
  • Third-party analytics or tracking scripts loaded over plain HTTP

Severity levels

Every finding is assigned a severity level. The level reflects how dangerous the issue is in practice, not just in theory. The AI triage and analysis layers take context into account when assigning severity.

How the security score is calculated

The security score (0 to 100) is a single number summarizing your scan result. A higher score is better. It starts at 100 and deductions are applied for each finding:

  • Critical: 30 points each
  • High: 15 points each
  • Medium: 5 points each
  • Low: 1 point each
  • Info: 0 points

The score floors at 0. Marking a finding as resolved adds its points back.

CRITICAL

Score: 9.0 - 10.0

Directly exploitable. If someone finds this issue today, they can immediately take over your account, steal your data, or attack your users. No special knowledge required.

Fix immediately. Do not ship. Assume the vulnerability may already be known.

HIGH

Score: 7.0 - 8.9

Significant security risk with a realistic attack path. May require some specific conditions, but an attacker with basic knowledge can exploit it.

Fix before the next release. Prioritize over feature work.

MEDIUM

Score: 4.0 - 6.9

A real issue that reduces your security posture, but exploitation typically requires more circumstances to align, or the impact is limited.

Add to your next sprint. Should not be deferred indefinitely.

LOW

Score: 1.0 - 3.9

Minor issue. Low impact or very difficult to exploit in practice. Still worth fixing over time.

Add to your backlog. Fix when touching that area of code.

INFO

Score: 0

Informational finding. Not a vulnerability by itself, but something worth knowing: a deprecated API, a code pattern that could become a risk later, or a missing best practice.

Review and decide. No immediate action required.

Reading a report

Finding anatomy

Each finding in a report is a self-contained explanation of one security issue. Here is what a finding looks like, with each field explained:

CRITICALHardcoded AWS secret access key
src/config.js : line 12

What it is

Your AWS secret access key is written directly in the code. Anyone who sees this file, for example if it is pushed to a public repository on GitHub, gets full access to your AWS account.

Why it is dangerous

Attackers run automated bots that scan public repositories for keys within minutes of a push. This can lead to data theft, account takeover, and very large cloud bills.

How to fix

  1. Remove the key from the code file.
  2. Move it to an environment variable: const key = process.env.AWS_SECRET_ACCESS_KEY
  3. Rotate the key in the AWS console. Assume the old key is already known to attackers.
  4. Add the config file to .gitignore so it cannot be committed accidentally.

Fixed snippet

config.js (fixed)
// Before (insecure):// const awsSecret = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY";​// After (safe):const awsSecret = process.env.AWS_SECRET_ACCESS_KEY;

Summary dashboard

At the top of every report is a summary dashboard showing:

  • Security score: a single number from 0 to 100. Higher is better. See the severity levels section for how this is calculated.
  • Total findings: the total count across all severity levels.
  • Severity breakdown: counts per level: Critical, High, Medium, Low, Info.
  • Category breakdown: which detection categories had findings.
  • Report download: export as PDF, Markdown, or JSON (PDF and Markdown require a paid plan).

Privacy and data handling

A security tool that leaks your code is worse than no security tool at all. Here is exactly how ALGIS handles your data.

Your code is not stored

Scans are ephemeral by default. When you submit code or files, they are loaded into memory, processed through the scan pipeline, and the resulting report is returned. The raw source code is not written to a persistent database and is not retained after the scan session ends. If you choose to save a report to your account, only the findings and metadata are saved, not the source code.

Your code is not used for AI training

Your code is never used to train, fine-tune, evaluate, or improve any AI model. It is passed to the AI layers solely to generate your scan report, within the scope of your scan session, and is not logged for any other purpose.

The AI sees only what it needs

The AI deep analysis layer receives individual findings and the specific code context around each finding, not your entire codebase. This limits exposure to only the relevant snippets.

URL scans

For URL scans, ALGIS makes a standard HTTP request from our servers. This request is visible in your server logs, just like any other web crawler. No authentication credentials or cookies from your browser are sent.

Transmission security

All data is transmitted over TLS. API keys are hashed before storage. Scan submissions are encrypted in transit.

The full privacy policy is at /privacy. The policy is written in plain English, not legal jargon.

Payments

ALGIS uses x402, an open HTTP-native payment protocol, so you can pay for scans in USDC stablecoin without creating an account or entering a credit card. Pay per scan in USDC. No account, no card.

What is x402?

x402 is a payment protocol built on top of the standard HTTP 402 Payment Required status code. Instead of redirecting users to a payment page, the API embeds a payment challenge directly in the HTTP response. The client pays in USDC and retries the request with proof of payment. The entire flow is HTTP-native and wallet-to-wallet.

  • No signup required for pay-per-scan. Run a big scan, pay a few cents in USDC, get the report.
  • No card stored on our servers. Payment is settled stablecoin-to-stablecoin.
  • No chargebacks. Stablecoin settlement is final.
  • Self-custody. You pay from your own wallet. We never hold your funds.

Payment flow

Here is what happens when a scan requires payment:

  1. You submit a scan request (code paste, file upload, or URL).
  2. If it exceeds the free tier, the API responds with 402 Payment Required, containing a payment challenge: amount, asset (USDC), and recipient address.
  3. Your wallet settles the payment on-chain in USDC.
  4. The client retries the scan request with proof of payment in the header.
  5. The scan runs. The full report is returned.
Client
-->
API
POST /v1/scans
API
<--
Client
402 Payment Required
amount, asset: "USDC", recipient, nonce
wallet settles payment in USDC on-chain
Client
-->
API
POST /v1/scans
x402-payment: [proof of payment]
API
<--
Client
200 OK - scan report

Payment safety

  • No credit card number, billing address, or card token is ever stored.
  • Payment is settled stablecoin-to-stablecoin. No intermediary holds your funds.
  • Stablecoin settlement is final. Disputes are not possible in the traditional sense, which also means no chargeback fraud.
  • Subscription plans (Pro and Team) use the same x402 protocol for recurring USDC payments.
See the pricing section for the full billing model: free tier limits, pay-per-scan rates, and Pro/Team subscription pricing.

API reference

The ALGIS REST API lets you integrate security scanning into your own tools, CI/CD pipelines, and workflows. Every endpoint path, request shape, and response shape is documented below.

Authentication

All API requests must include your API key in the X-API-Key header. API keys are issued from your account dashboard.

curl
curl -X POST https://api.algis.security/v1/scans \  -H "X-API-Key: your_api_key_here" \  -H "Content-Type: application/json" \  -d '{"input_type": "code", "content": "const key = \"AKIAIOSFODNN7EXAMPLE\""}'

Base URL

text
https://api.algis.security

Endpoints

POST/v1/scans

Start a new scan. Returns immediately with a scan ID and status. The scan runs asynchronously.

Request body

json
{  "input_type": "code" | "files" | "url",  "content":    string,  // code string for 'code', base64 zip for 'files', URL for 'url'  "filename":   string   // optional: hint for language detection}

Response

json
{  "scan_id":    "scn_7xKm3pQr",  "status":     "queued",  "created_at": "2026-06-12T10:00:00Z"}
Rate limit: 10 scans per minute on the Free plan. Files input supports zip archives up to 50 MB.
GET/v1/scans/{id}

Get the status and summary of a scan. Poll this endpoint until status is 'complete'.

Response

json
{  "scan_id":     "scn_7xKm3pQr",  "status":      "queued" | "running" | "complete" | "failed",  "created_at":  "2026-06-12T10:00:00Z",  "completed_at": "2026-06-12T10:00:05Z",  "summary": {    "total_findings": 4,    "by_severity": {      "CRITICAL": 1,      "HIGH":     1,      "MEDIUM":   2,      "LOW":      0,      "INFO":     0    },    "security_score": 42  }}
GET/v1/scans/{id}/findings

Get all findings for a completed scan.

Response

json
{  "scan_id":  "scn_7xKm3pQr",  "findings": [    {      "id":            "find_9kXa2bQc",      "category":      "exposed-secrets",      "severity":      "CRITICAL",      "title":         "Hardcoded AWS secret access key",      "file":          "src/config.js",      "line":          12,      "description":   "Your AWS secret access key is written directly in code.",      "why_dangerous": "Attackers scan public repos for keys within minutes of a push.",      "fix_steps":     [        "Remove the key from code.",        "Move it to an environment variable: process.env.AWS_SECRET_ACCESS_KEY",        "Rotate the key in the AWS console. Assume the old key is compromised.",        "Add the file to .gitignore."      ],      "fixed_snippet": "const key = process.env.AWS_SECRET_ACCESS_KEY;",      "references":    ["https://cwe.mitre.org/data/definitions/321.html"],      "resolved":      false    }  ]}
PATCH/v1/scans/{id}/findings/{finding_id}

Mark a finding as resolved or unresolved.

Request body

json
{ "resolved": true }

Response

json
{ "id": "find_9kXa2bQc", "resolved": true }

Finding object schema

Every finding returned by the API has this structure:

FieldTypeDescription
idstringUnique identifier for this finding within the scan.e.g. "find_9kXa2bQc"
categorystringOne of the 7 detection category slugs.e.g. "exposed-secrets"
severitystringCRITICAL | HIGH | MEDIUM | LOW | INFOe.g. "CRITICAL"
titlestringShort human-readable summary of the finding.e.g. "Hardcoded AWS secret access key"
filestring | nullRelative file path where the issue was found. null for URL scan findings.e.g. "src/config.js"
linenumber | nullLine number within the file. null if not applicable.e.g. 12
descriptionstringPlain-English description of what was found.e.g. "Your AWS secret access key is written directly in code."
why_dangerousstringExplanation of the real-world risk if this is exploited.e.g. "Attackers scan public repos for keys within minutes..."
fix_stepsstring[]Ordered list of steps to fix the issue.e.g. ["Remove the key from code.", "Move it to an environment variable."]
fixed_snippetstring | nullThe corrected code snippet, if applicable.e.g. "const key = process.env.AWS_SECRET_ACCESS_KEY"
referencesstring[]URLs to relevant documentation, advisories, or CWE entries.e.g. ["https://cwe.mitre.org/data/definitions/321.html"]
resolvedbooleanWhether the finding has been marked resolved by the user.e.g. false

Enums

severity
"CRITICAL" | "HIGH" | "MEDIUM" | "LOW" | "INFO"
category
"exposed-secrets"| "vulnerabilities"| "dependency-risks"| "bad-config"| "insecure-crypto"| "data-leaks"| "web-hygiene"
input_type
"code" | "files" | "url"
scan status
"queued" | "running" | "complete" | "failed"

Error codes

All error responses follow this shape:

json
{  "error": {    "code":    "invalid_input",    "message": "The 'input_type' field is required.",    "status":  400  }}
CodeStatusDescription
invalid_input400The request body is malformed or a required field is missing.
input_too_large413The uploaded file or code exceeds the size limit for your plan.
unsupported_input_type422The input_type field is not one of: code, files, url.
scan_not_found404No scan exists with the given ID, or it belongs to a different account.
scan_not_complete409You requested findings for a scan that has not yet finished.
rate_limit_exceeded429You have exceeded the rate limit. Check the Retry-After header.
unauthorized401The API key is missing, malformed, or revoked.
internal_error500An unexpected error occurred on our end. The request can be retried.

Rate limits

PlanScans / minuteMax file sizeConcurrent scans
Free51 MB1
Pro3050 MB5
Team60200 MB10
EnterpriseCustomCustomCustom

When a rate limit is exceeded, the API returns HTTP 429 with a Retry-After header indicating how many seconds to wait.

CLI and CI/CD integration

The ALGIS command-line interface (CLI) lets you run security scans from your terminal and integrate them into your build pipeline so every code push is automatically checked.

CLI usage

terminal
# Installnpm install -g @algis/cli​# Scan a directoryalgis scan ./src​# Scan a single filealgis scan ./src/config.js​# Scan a URLalgis scan --url https://mysite.com​# Output JSON for programmatic usealgis scan ./src --format json

GitHub Actions integration

.github/workflows/security.yml
name: Security scan​on: [push, pull_request]​jobs:  scan:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - name: Run ALGIS scan        uses: algis-security/algis-action@v1        with:          api-key: ${{ secrets.AEGIS_API_KEY }}          path: ./src          fail-on: HIGH  # fail the build on HIGH or CRITICAL findings

The CI/CD integration fails the build when findings above a configured severity threshold are detected. This brings security checks into the normal development workflow rather than treating them as a separate audit step.

FAQ

No. By default, scans are ephemeral. Your code is loaded into memory, scanned, and the results are returned. The raw code is not written to persistent storage and is not retained after the scan completes. You can optionally save the report (not the source code) to your account history.

No. Your code is never used to train, fine-tune, or improve any AI model. It is sent to the AI layer solely to generate your report, and only within the scope of your scan session.

The deterministic layer (SAST and secret detection) supports most common languages: JavaScript, TypeScript, Python, Go, Ruby, Java, PHP, C/C++, C#, Rust, and configuration formats like YAML, JSON, TOML, and Dockerfiles. The AI analysis layer can reason about any language.

The scanner is designed to minimize false positives through a layered approach. The deterministic layer catches patterns with high precision. The AI triage layer then filters those results, removing likely false positives before the expensive deep analysis runs. That said, no automated security tool is perfect. You can mark any finding as resolved if you believe it does not apply to your code.

Free scans are available without an account and support single code pastes and URLs. Paid plans add larger file uploads, batch scanning, scan history, PDF and JSON report exports, and higher API rate limits. Exact pricing is on the Pricing page.

Yes. The API reference on this page specifies the endpoints your pipeline calls, and there is a dedicated CLI tool and GitHub Action for dropping scans straight into your build.

Send an email to the support address listed in the footer. Feature requests and bug reports are welcome.

The deep analysis layer runs on Anthropic Fable 5, Anthropic's newest and most capable model. It writes the plain-English explanations, the risk descriptions, and the exact fix code for every confirmed finding. The triage layer (Layer 2) uses Anthropic fast tier, a faster and cheaper model that filters false positives and ranks findings before the expensive analysis runs. Layer 1 uses no AI at all: Semgrep, CVE databases, and secret-pattern matching do the initial sweep. Each layer is used where it performs best.

Good security output is genuinely hard to produce. The model has to read code in context, judge whether an issue is actually exploitable in that specific codebase, explain it clearly to a non-specialist, and write a correct, working fix. Weaker or older models give generic or wrong advice. Anthropic Fable 5 is Anthropic's most capable model for this kind of structured reasoning, and it is grounded in real scanner findings (Semgrep output, CVE records, secret-pattern matches) rather than being asked to guess from scratch. That combination is what makes the explanations trustworthy and the fixes usable.

x402 is an open, HTTP-native payment protocol. When you request a scan that exceeds the free tier, the API responds with a standard HTTP 402 Payment Required challenge containing the payment amount, asset (USDC), and recipient address. Your client settles the payment in USDC from your own wallet, then retries the request with proof of payment. The scan runs and the report is returned. No card details are ever stored.

No. The pay-per-scan option via x402 requires no account and no credit card. You pay in USDC stablecoin directly from your own self-custody wallet. There are no chargebacks and no card details stored anywhere. Subscription plans (Pro and Team) also use x402 for recurring USDC payments.

Was this page helpful?