Redthread documentation

Redthread is an AI-Native Application Protection Platform (ANAPP), powered by Redthread. It is agentless-first — it installs nothing to deliver its core value — and every capability is a module you switch on per workspace from one console.

Redthread starts by building the map — because until you know how your agents, code, cloud and infrastructure connect, a list of findings is just a list. It assembles one graph of your whole estate — agents, applications, code, cloud accounts, identities, the security controls you already run, and the data they can reach — and every module reads and writes that same graph, so the risk you see first is the one that spans layers, not an isolated finding on a list.

On top of that map, the platform runs as modules you enable per workspace:

• AI risk assessment (Assess & Consolidate) — the free, agentless front door: every AI you run, the toxic combinations ranked first and mapped to the OWASP Top 10 for LLM and Agentic applications, plus connect agentless and get a posture score, the AI surfaces nothing is watching, and a replace-map of the incumbent tools a Redthread module can retire, with input-driven consolidation ROI.
• Exploit validation (AI application testing) — proves the riskiest paths the assessment ranks: autonomous agents probe your chatbots, agents and RAG endpoints against the OWASP LLM Top 10 (mapped to MITRE ATLAS); every finding carries a reproducible proof of concept.
• Shadow-AI discovery — inventory every AI-powered feature across your estate, including the ones nobody registered.
• Cloud & infrastructure posture — connect a cloud agentless (nothing installed) to map assets, identities and data, classify sensitive stores (DSPM), and surface cross-cloud attack paths.
• Endpoint telemetry (detect-only) — an optional, in-core thin agent on OS-safe surfaces reports on-host inventory and posture. It never blocks; real-time prevention is a partnered add-on on the roadmap.
• Agentic Trust & Protection Platform — give every agent/identity a SPIFFE id and broadcast signed, TTL'd trust-state events (safe/unsafe/revoked) off proven exploits, so orchestrators, gateways and SIEMs react in seconds. See Agentic Trust & Protection Platform.
• CI/CD gating — scan on every pull request and block a merge that would introduce a proven attack path.
• Continuous platform — scheduled re-assessment with drift and trend, so coverage reflects what is in production this week.
• Remediation & reports — plain fixes and draft pull requests; a Letter of Attestation, the full technical report, and a machine-readable twin, mapped to the frameworks your auditors ask about.
• Identity & access — SSO, SCIM provisioning, roles and audit logs for your workspace.

Proven, not inferred. A finding is something the engine actually reached or exploited, with the exact steps to reproduce it; coverage is only claimed where the graph carries it. The platform is agentless and detection-first — any prevention/blocking action is a signed, opt-in, customer-owned exception, never a default, and every update we push to a sensor is staged behind the AI Rollout Safety gate (canary rings, automatic halt).

This documentation covers getting started, the platform architecture, the core concepts behind how the platform works, task-based guides, and the full API reference so you can drive every module from CI or your own scripts.

Latest updates

31 October 2026

• White-label reports. On paid plans the owner sets a firm name, contact line and logo under Settings → General → Report branding. The Compliance Report and the Letter of Attestation then show your firm as the issuing party, with Redthread credited as the platform unless you tick the box that removes it.
• Staged sensor updates are live. A new endpoint-agent build is validated, then offered to canary rings (1% → 10% → 50% → 100% of your hosts) and halted automatically if a ring does not come back healthy.
• One asset, entered once. Pentest Scan now picks from the sites already in your estate, and a new URL is saved once. A manual scan of a registered site uses that site's Knowledge and history. Scan now, schedules, drift re-scans and CI triggers all require a verified domain, like manual scans. Infrastructure Scan can add another cloud and disconnect a single cloud.
• The daily MCP registry scan now covers 53,270 servers. Every server gets a signed claim, and the day's signed manifest is anchored in the public Sigstore Rekor log. The scan of 30 October found 1,489 listing swaps (the name now leads to a different domain or package owner), 227 listings that name a version that was never published, and 35 packages built from a repository other than the one declared. See the live numbers.
• Tool definitions are fingerprinted (rules atf-6). For the remote servers that answer without credentials (20,504 so far), the scan records a sha256 fingerprint of the tool list and fails a server whose tools changed while its version did not, the rug-pull pattern. The gate and the hooks deny it.
• Hooks for Claude Code and Cursor, and an AIBOM (preview). atpp hook claude|cursor checks each MCP tool call against the server's signed claim before it runs. atpp check-config --cyclonedx writes a CycloneDX 1.6 bill of materials of the MCP servers you have configured.
• Enforce inspects content (preview). The gateway now looks inside agent traffic for prompt-injection directives, secrets leaving in a request, and poisoned MCP tool lists. It only observes until you switch an identity to enforce, and it matches patterns, so a paraphrase can slip past it: it is one layer, not a guarantee.
• Workspace signing keys moved out of the app. The key that signs your trust events now lives in a separate signer service, sealed with a key from Oracle Cloud Vault. The app can ask for a signature but cannot read or copy the key.
• The trust ledger cannot be edited. Agent trust events are stored in PostgreSQL, and the database itself refuses updates, deletes and truncation of the ledger, so the guarantee does not depend on the application behaving.
• Compliance Report and Attestation letter open inside the app, by standard. Choose SOC 2, ISO 27001, ISO 42001, PCI DSS v4.0, GDPR, HIPAA, NIST CSF, NIST AI RMF or the EU AI Act, then download (HTML, PDF, JSON) or share by email or Slack. The views are cross-references that support an audit, never a certification. See Reports & attestation.
• The website knows you are signed in. The menu shows Dashboard instead of Log in, and a docs link that needs sign-in takes you back to that section after you sign in.
• Account and session data is written safely. Writes are atomic with a recovery copy, so a crash can no longer truncate your workspace, and a failed read can no longer turn into an empty one.

7 October 2026

• Oracle Cloud connects on every Oracle account. Accounts created since 2023 use identity domains, which refused our scan user because it had no email address. The one-click setup now gives it one, and its user, group and policy are named Redthread.
• Endpoint sensors install with one command. Mint a key in Estate Scan and paste one command on macOS, Linux or Windows. It checks the download, installs a background service, sends the first report, and the screen confirms when the machine appears. A matching uninstall command is on the same screen.
• Every reporting machine stays in your estate. Each new report used to replace the whole list, so only the last machine to report showed. Now each report updates just its own machine, and sensors stay on the graph through a cloud re-scan.
• A sensor on a cloud VM joins that VM. On AWS, Oracle Cloud, Azure or Google Cloud the sensor reads its instance ID, so a VM your cloud scan already found shows as one node with both views.
• Existing cloud VMs from your own Cloud Shell. One command for Oracle Cloud, Azure or Google Cloud installs a sensor on every running VM, using your own login. Redthread gets no access to your VMs.
• New cloud VMs on first boot. A startup script for the VM's startup-script field installs a permanent sensor the first time a new VM boots.
• Pentest scans follow your estate. Each paid plan includes one pentest scan a month for every 10 workloads (Starter 3, Growth 15, Enterprise 15 and up). Past that, use a scan pack or pay per scan. See plans.
• Your whole estate on one map. Redthread Flow now opens on an estate map of every cloud, machine and identity and the links between them, including the links between clouds. Cloud issues and Attack paths have their own pages in the left menu.
• Every connected cloud is scanned. With more than one cloud connected (for example AWS and Oracle Cloud), Scan my estate now scans each one, and each cloud's findings and part of the graph are kept separately, so scanning one never replaces another.
• Your Mac shows by name. A Mac now appears under its Computer Name, not its network address.

Guide: connect your whole estate

Goal: connect every source once, so a single Scan my estate maps your websites, code, clouds, machines and the AI running on them. Everything here is read-only and free to connect. Do the steps in any order; each lane on Estate Scan turns green when it is connected.

Before you start

1. Sign in at app.redthreadsec.com with your work email.
2. Click the link in the verification email. Scans stay locked until you do.
3. Open Estate Scan. It is the first page after sign-in.

1. Websites & apps

1. In the Websites & apps lane, paste your main website or app address and add it.
2. Repeat for each public site. No credentials are needed; we only read public pages.
3. To run a pentest against a site later, you prove you own it first (how).

2. Code

1. In the Code lane, click Sign in with GitHub.
2. Approve read-only access. Your repositories are swept for AI frameworks, secrets and infrastructure code.

3. Cloud & infrastructure

Each cloud connects in one click, with read-only access you can revoke in your own console. The first scan runs by itself as soon as a cloud connects.

• AWS: click Open AWS and create the role, tick the IAM acknowledgement, click Create stack, wait about a minute, then type your 12-digit AWS account number back in Redthread. Not the person who runs AWS? Use Get a link to send them.
• Azure: under Not on AWS?, choose Microsoft Azure, sign in with Microsoft, approve Redthread, pick the subscription and click Create.
• Google Cloud: choose Google Cloud, sign in with Google, approve, and pick the project to scan.
• Oracle Cloud: choose Oracle Cloud, click Open Oracle Cloud and create the access and sign in as an administrator. Tick I have reviewed and accept the Oracle Terms of Use, click Next twice, tick Run apply and click Create. Come back to Redthread; it connects in a few minutes.

Later scans do not run on a timer: click Scan my estate, or Scan on a cloud's card, to pick up changes.

4. Endpoint sensors (optional)

A sensor watches one laptop, server or cloud VM and reports its software, security settings and the AI tools running on it. It never blocks anything.

1. In the Install endpoint sensors lane, click Mint an enrolment key.
2. A laptop or server: copy the macOS or Linux command into Terminal, or the Windows command into PowerShell. On a server, put sudo in front of sh so it installs for the whole machine. The screen says when the machine is reporting.
3. Cloud VMs you already run: open Existing cloud VMs: install on all of them, copy the command for your cloud and paste it into that cloud's Cloud Shell. In Oracle Cloud, Cloud Shell is under Developer tools at the top right; in Azure and Google Cloud it is the Cloud Shell icon at the top of the console. It installs on every running VM and prints a summary. On AWS, use the install command on each instance.
4. New cloud VMs: open New cloud VMs: install automatically and paste the script into the VM's startup-script field when you create it.
5. To remove a sensor: run the command under Uninstall on that machine.

5. AI agents & services

Nothing to enter. They are found from the sources above and listed in your AI inventory.

6. Scan

1. Click Scan my estate. It maps everything connected; it never uses your pentest scans.
2. Open the graph and What we found to see your assets, the AI on them, and the attack paths between them.
3. For an exploit-proving pentest of one app, start a pentest scan. The Free plan includes one black-box scan of your website, for life; paid plans include one a month for every 10 workloads.

Quickstart — in the browser

The fastest way to see a result. No install, no card.

1. Create your account. Go to app.redthreadsec.com/app and sign up with your email. A work email is best; a personal one works too. No card.
2. Connect your estate. You land on Estate Scan. Connect as much or as little as you like — a website URL needs no credentials, GitHub is one click, each cloud is one click, and endpoint sensors are one command per machine; a read-only cloud connection is the single biggest jump in coverage. Step-by-step: connect your whole estate. Discovery across all of it is free and unlimited; the meter shows what's still dark and nothing blocks the scan.
3. Verify your email. Click the link we send you. This unlocks active scanning. (Didn't arrive? Use "Resend" in the app.)
4. Point a pentest at one target. For the active, exploit-proving scan, paste your app's staging URL — the live address where it's running (not production). On a paid plan you can also drag in your code (a .zip) for a deeper scan. Press Start a scan.
5. Watch it work. The scan runs in an isolated sandbox and typically finishes in minutes. You'll see it probe each category live.
6. Read the findings. Each proven vulnerability comes with its severity, impact, and a plain remediation. On a paid plan, every finding also includes a working proof of concept and a draft fix.

Prefer an app? Redthread is also available for Mac and Windows from the download page. It is the same product in its own window; your data stays on the server, so the app and the browser always show the same workspace. To sign in, enter your email in the app and open the emailed link — your browser asks to open Redthread and hands the sign-in to the app (the millenniums:// link is single-use and expires in 15 minutes). The installers are not yet signed with an Apple or Microsoft certificate, so a downloaded copy is blocked until you confirm it once. On a Mac, the one-line Terminal install on the download page avoids the prompt entirely; with the .dmg you confirm once via System Settings → Privacy & Security → Open Anyway. On Windows, click More info → Run anyway.

Quickstart — with the API

Prefer to drive it from a terminal or CI? Everything the app does is a REST call. Your access token is created at signup and shown in the app; it goes in an Authorization: Bearer header.

1. Check your account

Confirm your token works and see your plan and remaining quota.

curl https://app.redthreadsec.com/api/me \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

{ "tenant": "acme-3f9a2c", "plan": "starter", "plan_display": "Starter", "poc": true,
  "scans_used": 1, "scans_limit": 5, "apps_used": 1, "apps_limit": 1, "verified": true }

2. Start a scan

Give it a target. On a paid plan, optionally add source (a repo or path) for a much deeper white-box scan, and a budget spend cap.

curl -X POST https://app.redthreadsec.com/api/scan \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"target":"https://staging.yourapp.com/chat","budget":10}'

{ "run_id": "20260731-abc123" }

3. Read the results

Poll the run until running is false, then read its findings.

curl https://app.redthreadsec.com/api/runs/20260731-abc123 \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

That's the whole loop: me → scan → runs/<id>. The API reference documents every field.

How it works

Redthread is agentless: you connect a target or a cloud, switch on the modules you want per workspace, and everything runs from our cloud. Under every module sits one idea — the graph.

1. Map. Redthread builds one graph of your estate — agents, applications, code, cloud accounts, identities, and the data they can reach — from whatever you connect: an agentless cloud role, a repository, a running app.
2. Assess. The modules you enabled run over that map. Autonomous agents pentest your AI apps in an isolated sandbox; shadow-AI discovery inventories every model surface; cloud & infrastructure posture and DSPM classify assets and sensitive data; dependency-CVE analysis checks what you inherit.
3. Prove. A finding is something the engine actually reached or exploited — with the exact steps to reproduce it. Only real results become findings; unproven leads are held separately. Nothing is inferred.
4. Rank. Findings go back onto the graph, so the risk that spans layers — an internet-facing app whose credential reaches classified data in another cloud — surfaces above a list of isolated issues.
5. Act. Each finding carries a plain remediation and, when you want it, a draft pull request. The CI gate blocks a merge that would introduce a proven attack path, and remediation can fire a signed webhook or open a Jira / ServiceNow ticket.

Nothing is installed on your systems for the core product; modules are switched on per workspace from the cloud (see the architecture diagram). Optional agents go deeper when you want them: a thin outbound-only connector for scanning inside your network, a Kubernetes eBPF runtime sensor, and a per-host endpoint agent — all detect-only, never blocking. AI-app scans run in an isolated per-scan Docker sandbox that is destroyed when the scan ends.

Tools: autonomous AI agents driven by frontier LLMs, guided by our vulnerability skill pack (OWASP LLM Top 10 2025 + MITRE ATLAS); CVSS 3.1 scoring; dependency CVEs via osv-scanner; the estate graph exports as plain node-link JSON. The flagship module is the AI-application pentest — the rest of this section documents every module and the API behind it.

Platform architecture

Customers can read this section in the app: sign in and open any docs link.

Endpoint sensors: what they collect and how it is used

A sensor runs on one laptop, server or cloud VM. It only reads and reports; it never blocks, kills or changes anything. It sends a report when it starts and every 15 minutes, and between reports it checks every 20 seconds which AI tools are running, so short runs are counted too. To see exactly what a machine would send before you install, run redthread-agent -print: it prints the report and sends nothing.

What a report contains

Every machine with a sensor counts as covered by Redthread's detection in Assess. In Estate Scan, Install endpoint sensors lists each reporting machine with what it reported and when.

What it never sends

File contents, keystrokes, screenshots, network traffic, environment variables, passwords or tokens, the raw hardware ID, or process command lines. Command lines are read on the machine only to recognise an AI tool, then discarded.

Automatic updates. The sensor keeps itself current: every six hours it checks for a newer published build, verifies it against the published SHA-256 checksums exactly as the installer does, swaps it in and restarts. A build that does not match its checksum is never installed. Sensors installed before October 7, 2026 need their install command run once more to get this; after that, nothing needs re-running. To turn updates off on a machine, set MAI_AUTO_UPDATE=0.

Assess & Consolidate

Customers can read this section in the app: sign in and open any docs link.

Agentic Trust & Protection Platform

Agentic identity + continuous trust signals, on SPIFFE.

The Agent Trust & Enforce page. In the console (Govern → Agent Trust & Enforce) an owner turns Agent Trust on or off with one button, and registers an agent by giving it a name and its scopes: the exact tool or action names it reports. Each agent card shows its badge state, shadow or enforce mode, its identity and scopes, when a gateway last decided traffic for it, and its burn-in progress: shadow decisions out of 100, minutes in shadow out of 60, and would-have-blocked decisions waiting for review. The owner reviews those in groups (should block / was legitimate) and can switch the agent to enforce once the burn-in is complete. The gateway and enforce mode are marked Preview.

One-command gateway (preview). After you register an agent, Redthread shows one command with its identity and key filled in. Run it on the machine that runs the agent (macOS or Linux, Python 3.10+): it installs the reference gateway as a background service on 127.0.0.1:8888 and prints the lines to start your agent with (the proxy address, and the certificate the gateway generated on that machine). In shadow mode it decides and records every request and blocks nothing; decisions appear on the agent's card under Activity and Burn-in. Each agent card also has a grant editor (host, methods, paths). Run the command with --uninstall to remove it.

An opt-in module that gives every discovered agent and identity a durable, verifiable identity and broadcasts its trust state — safe / unsafe / degraded / revoked — in real time, so orchestrators, agent gateways, and SIEMs can react in seconds instead of waiting for someone to read a report. It rides the graph and the exploit-validation pipeline you already have; it is off by default and strictly additive — a workspace that never activates it sees no change.

It sits at the intersection of two industry categories: non-human / workload identity (the same problem SPIFFE/SPIRE solves for service accounts and machines, extended to AI agents) and continuous access evaluation (the CAEP/RISC Shared-Signals pattern used for real-time revocation in enterprise identity). Agentic Trust & Protection Platform is our name for both halves as one mesh — every agent gets a verifiable identity, and its trust state streams live to whatever needs it.

• Identity — SPIFFE/SPIRE. Every agent/identity/AI node gets a spiffe_id. Deploy the CNCF SPIRE engine per-tenant with one Terraform step from the console (it targets the same cluster discovery already reads; the signing keys never leave your cloud) and it issues short-lived, auto-rotated SVIDs that flow back onto the graph. Until you deploy it, Redthread assigns a deterministic SPIFFE id so the layer works today. Vendor- and model-blind: identity is issued to the workload, never to the model inside it.
• Trust badges on the graph. Once active, every node in the Redthread Flow view carries a trust badge (green safe / red unsafe / amber degraded / gray revoked), sourced from the same trust_state field.
• Trust state, proven not guessed. A node flips to unsafe only on a proven exploit (never an inferred one); degraded covers a potential-but-unconfirmed finding or an expired SVID; revoked is a manual operator override.
• Signed, TTL'd events. Every trust-state change is emitted as an Ed25519-signed, expiring event shaped after the CAEP/RISC standards, with a link back to the finding that caused it. Any third party can verify an event offline against your workspace's public key — no live call back to Redthread.
• Delivery. Register one or more webhooks (with an optional HMAC shared secret); a signed event fans out on every change. An append-only ledger lets a subscriber that missed events catch up.
• Keys and ledger. Each workspace's signing key is held by a separate signer service, sealed with a key from Oracle Cloud Vault: the app can ask for a signature but cannot read or export the key. The append-only ledger lives in PostgreSQL, and the database itself refuses to update, delete or truncate it.
• Enforce — preview. An opt-in inline gateway that decides allow / deny / deny-and-pause on a live request against a structured grant (host, method, path, body size) before it reaches its destination, instead of only recording it afterward. Every new grant starts in shadow — decide and record, forward everything, exactly like today — and the API itself refuses to switch an identity to enforcing until a burn-in gate is satisfied: real traffic watched under that exact grant for long enough, and every request it would have blocked reviewed and agreed by the operator. There is no override. Since October the gateway also inspects content: prompt-injection directives and secrets in an outgoing request, and a poisoned MCP tools/list in a response. This is pattern matching, observe-only until an identity is switched to enforce, and a paraphrase can evade it. See the API for the full route surface.

The default is still identity + trust-state only — not a permissions/VC system, and not (in v1) cross-organization federation. Enforce, where an identity has earned it, adds a real decision point in the request path; it is never claimed as a guarantee against a novel attack that matches no rule.

Public badges: the image is a pointer, the claim is a signed file

Any README badge is an image fetched from somebody's server, and the picture can show whatever that server decides. So no ATPP claim lives in an image. A level-1 (MCP publisher) claim is an in-toto statement in a DSSE envelope, signed with Ed25519 by our daily scan job (it runs on Redthread's own infrastructure), whose subject is the sha256 of the exact registry manifest that was scanned. Since rules atf-5 the claim also names what the listing installs: the npm integrity hash, the PyPI file sha256s or the container digest behind each image tag, and the repository named in the package's Sigstore build provenance, where npm or PyPI keeps one. The servers behind trust.redthreadsec.com hold only the public key, so they cannot mint a claim that verifies, and they render a badge grey unless the signature checks.

• Pinned badge (default). The publisher commits .atpp/badge.svg and .atpp/attestation.dsse.json (download both from /v/mcp/<namespace>/<server>). Their README fetches nothing from us; the badge states its version and date; its sha256 is inside the signed claim.
• Live badge (optional). /badge/mcp/<namespace>/<server>.svg follows each re-scan; on GitHub it lags about 10 minutes (image cache). Plain shapes and text only — no links or animation.
• Check it yourself. python3 atpp.py verify <namespace>/<server> or a repo path, from github.com/bl014h/atpp: signature against a pinned key, live registry hash, committed badge, expiry. Keys: /.well-known/atpp-keys.json. Each day's signed manifest of every envelope is at /v/log/latest.json, and its hash is committed to that public repo.
• Check what you already installed. python3 atpp.py check-config reads your Claude Desktop, Claude Code, Cursor, VS Code or Windsurf MCP config on your machine, finds the registry listing behind each package or URL, and prints its signed score, the exact version or digest to pin and who built it. !! marks a server not to trust by name (listing swap, missing version, built from another repository). Your config file is never uploaded.
• Tool definitions are fingerprinted. Since rules atf-6 the scan sends the MCP handshake and tools/list (no tool is called) to each remote server that answers without credentials and signs a fingerprint of the tool definitions into the claim. tools-stable fails when the definitions change while the version does not, the rug-pull pattern (OWASP MCP03).
• Servers that publish an Agent SD-Card are checked against it. Since rules atf-7, a remote server that serves an Agent SD-Card at /.well-known/sd-card/mcp (draft-nandakumar-agent-sd-card) gets one more check, sd-card-consistent: do the tool definitions it serves match the ones its own card discloses? The scan judges the server against its own card, not the card issuer’s signature. Servers without a card are not marked down: the check does not apply to them. The verify page and the check_mcp_server answer show it.
• Hooks and a bill of materials (preview). atpp hook claude (a Claude Code PreToolUse hook) and atpp hook cursor check each MCP tool call against the signed claim and deny a listing swap, a missing version, foreign build provenance or a silent tool change. atpp check-config --cyclonedx bom.json writes a CycloneDX 1.6 AIBOM of your configured servers.
• Gate a launch (preview). python3 atpp.py gate <namespace>/<server> exits 0 to allow or 1 to deny; a check that cannot run denies. Use it before a launch, in CI (the atpp GitHub Action with mode: check-config fails a pull request that adds a server needing review), or in front of ToolHive (atf_receipts.py serve --gate). It checks the published listing and the artifact digest against a static scan; it does not watch what a server does once it runs.
• Your policy, enforced by your runtime. An organisation's allow-list and pinned image digests live in a file you own: atpp gate --policy org.json denies anything else, and atpp profile --policy org.json turns an entry into a ToolHive permission profile (allowed outbound hosts and file mounts) for thv run --isolate-network. The signed claim never grants a permission.
• Keyless co-signature. Each day's manifest is also signed with Sigstore keyless signing by a read-only workflow in the public atpp repository (GitHub's identity, a short-lived certificate, a Rekor entry). Verify it with sigstore verify identity; the bundles are in that repository's log/ folder.
• Rollback-proof. Each day's manifest is also anchored in the public Sigstore Rekor transparency log, and the verifier checks that a claim is in the latest manifest — so even a compromised server cannot replay an older, better-scoring claim, and a repo cannot borrow another server's .atpp/ files (the claim must belong to the repository it sits in).
• Watched from outside. An hourly canary and a daily red team run on GitHub against production; results are public.
• The full design, for developers and security leaders: trust.redthreadsec.com/technical.
• Report a problem: [email protected] · disclosure policy.

How we compare

Where Redthread sits, architecturally, next to platforms teams already know. On the agent axis we are agentless-first, like Wiz; what is different is that we prove risk by exploiting it, and the Redthread graph treats AI agents and applications as first-class nodes, not just cloud infrastructure. This is an architecture comparison — Wiz, Palo Alto and CrowdStrike are large, multi-product suites, so the point here is shape, not feature parity.

Closest to Wiz. Agentless by default, with a security graph at the core that turns raw findings into ranked attack paths and toxic combinations. The difference: Wiz infers risk from cloud state; we prove it — an autonomous pentest runs the exploit and attaches a reproducible PoC — and our graph makes LLM apps and agents first-class nodes (OWASP LLM Top 10, MITRE ATLAS), not just cloud resources. So we are, in shape, "an agentless CNAPP graph with an offensive AI-application pentester on top."

Unlike Palo Alto. Prisma Cloud + Cortex is platformization — many products and agents (agentless + Defender + an AI SOC across endpoint, network, cloud and identity). We are one agentless platform with modules switched on per workspace. Palo Alto prevents and responds at runtime; we stay a testing and assessment tool by design — our optional runtime sensor only detects.

Unlike CrowdStrike. Falcon's premise is one agent on every endpoint doing runtime EDR. We install nothing for the core product and do not do runtime prevention. We overlap only in "cloud-activated modules" and in running a correlation graph — but Falcon graphs endpoint events, Redthread graphs your estate and its proven attack paths.

What to point it at

The single most common question, answered up front: you give us a target, and optionally your source. They're not the same thing.

Staging vs production — always aim at staging

• Production is the real app your customers use, with real data.
• Staging is a separate, running copy in a test environment — the same app, but with no real customers or data.

The scanner is a real attacker: it submits inputs, can create records, trigger actions your app exposes, and drive up model cost against your app. On staging that's harmless. On production it can mean junk data or real side effects for real users. Only scan production if you understand and accept that (a test account and a quiet time help).

How do I know my URL? A staging URL looks like…

It's just a web address where your app runs. Common shapes:

• staging.yourapp.com or app-staging.yourapp.com
• A preview URL from Vercel or Netlify (they mint one per change)
• A *-staging.onrender.com or *.herokuapp.com app
• A local address (localhost:3000) exposed to the internet with a tunnel (ngrok, cloudflared)

Easiest: let the app find it for you

In the app, paste the one link you already know — your main website or app address — into "Not sure what to scan?" and press Find what to scan. We look at the page, spot the AI features and API endpoints, and check public records for your other environments (like staging. and app.). You get back a short list of recommended targets — click one to scan it. No hosting logins, no hunting.

Find it yourself — no developer needed

Prefer to do it by hand, or want to double-check? You don't need anyone technical. Two reliable ways:

1. Open your own app and copy the link. Use your product the way a customer does — go to the page with the AI feature (the chat, the assistant) and copy the address straight from your browser's address bar. That address is your target.
2. Follow the money to your hosting account. Your app runs somewhere, and whoever's card pays the hosting bill can see every URL. Check your statements for Vercel, Netlify, Render, Heroku, AWS, DigitalOcean, Google Cloud, log into that account, and the dashboard lists your app's addresses — production and any staging/preview ones.

Backup routes: your domain registrar / DNS (GoDaddy, Namecheap, Cloudflare — wherever you bought the domain) shows subdomains like staging., app., api.; or ask your hosting provider's support from inside your account.

I don't have a staging URL — how do I get one?

• Most hosts spin up a staging copy in one click from your account — Vercel, Netlify, and Render all offer free preview/staging environments, no code required.
• If your app is on GitHub, a preview URL is often generated automatically on each pull request.
• Only have production? You can still scan it — just treat it as a live attack (quiet time, a test account, expect some junk data). See Staging vs production above.
• No one technical at all? A freelancer can stand up staging in an afternoon — then you paste that URL here.

Once you have the URL, follow Run your first scan. On a paid plan, add your code (upload or repo) for a deeper white-box scan.

Black-box vs white-box

How much you give the scanner decides how much it finds.

• Black-box — you give only a live URL or API. The scanner attacks from the outside, like an anonymous attacker. Fast, zero setup, but it can only find what's reachable from the front door.
• White-box (paid plans) — you also give the application's source. The scanner reads the code as it attacks, so it understands the tools, prompts, and data paths behind the endpoint. This is a large uplift in both the number and the depth of findings.

Two ways to hand over the source — you don't need to know git:

• Upload a .zip of your project. In the app, drop it into the scan box; over the API, upload it and pass the returned upload_id. Your code is held only for that scan and deleted when it ends — never used to train.
• Point at a git repo — GitHub, GitLab, Bitbucket, or Azure DevOps. Paste the repo URL in the source field, or in the app Connect GitHub once and pick a repo (including private ones) from a dropdown. For other hosts, paste the URL; private repos there use the .zip upload.

Complete scan — both passes, one click

Turn on Complete scan (the checkbox on the scan form) to run both passes for one target automatically: a black-box pass probes the live endpoints, then a white-box pass reads your source and re-tests the known surface. You get one merged findings list, each card tagged by the pass that found it. It needs your source (a repo or .zip) and uses about twice the budget of a single scan.

The white-box pass carries the black-box findings forward and re-tests each one: an issue that's still exploitable is shown as a ↻ re-confirmed regression (counted once, not twice), and anything only the source could reveal is added as new. The Complete scan, like any source-code (white-box) scan, is available on paid plans only; the Free plan includes one black-box scan of your website.

What it tests

Every category on the OWASP LLM Top 10, mapped to MITRE ATLAS:

• Prompt injection
• Sensitive information disclosure
• Supply chain
• Data & model poisoning
• Improper output handling
• Excessive agency (tool & agent abuse)
• System prompt leakage
• Vector & embedding weaknesses (RAG)
• Misinformation
• Unbounded consumption (runaway cost)

The full matrix, with the mapping to MITRE ATLAS, is published on the Trust Center.

Tools: our per-category vulnerability skill pack, keyed to OWASP LLM Top 10 2025 and MITRE ATLAS v5.6.0 (technique ids verified against the source, not recalled). Supply chain has its own section.

Findings & proofs of concept

A finding is a vulnerability the scanner proved, not a guess. Each one carries:

Reading a finding — the labels explained

Every finding is tagged with standard security labels so you can judge the risk and decide what to fix first. Here is what each label means, how to read it, and why it matters.

OWASP LLM Top 10 — what each risk means

Spend caps & safety

Autonomous agents call a language model, which costs money. Two independent limits make sure a scan can never surprise you:

• Per-scan budget cap. Every scan takes a budget (US dollars, default 10). The engine stops when it hits that ceiling.
• Token watchdog. A separate backstop kills any scan that blows past a hard token count, even for a self-hosted model the pricing layer can't see. So a runaway loop can't drain your account.

Every scan also runs in its own isolated sandbox, and concurrency is capped per plan so you can't accidentally launch a hundred scans at once.

Authorization & domain verification

Because a scan is a real attack, you may only scan an app you own or are authorized to test. To make that more than a promise, the first time you scan a new public domain we ask you to prove you own it — one time per domain. This stops anyone from pointing us at a competitor.

Verify by either method (pick whichever you can reach — you only need one):

• Meta tag (easiest). Add a line to your homepage's <head>. Most site builders — Wix, Squarespace, Webflow, Shopify — have a "header code" or "site verification" box for exactly this:

  <meta name="millenniums-verification" content="YOUR-TOKEN">

• DNS TXT record. Add a TXT record at your domain registrar:

  millenniums-verification=YOUR-TOKEN

Verifying the root domain covers all its subdomains — verify acme.com once and you can scan staging.acme.com, api.acme.com, and the rest. You'll also confirm a short authorization certification (that you own the app, or are authorized to test it) before the first scan runs.

Verify in the app when prompted, or over the API at POST /api/domains/verify. Discovery (reading a public page) needs no verification — only scanning does.

Your data

Your code and scan results are yours. Each scan runs in a throwaway sandbox that is destroyed when the scan finishes, so we hold as little of your code as possible and only for as long as the scan needs it. We never use your code or results to train any model. Full details, including sub-processors, are in the Trust Center and Privacy Policy.

Traceability report

Every scan produces a chain-of-custody report so you can prove — to yourself, a customer, or an auditor — exactly what happened to your data. It's not a marketing claim; each line is derived from a recorded event in the scan's lifecycle.

The report includes:

• A timestamped timeline: scan created → source received → isolated sandbox launched → scan finished → sandbox torn down → (for uploads) uploaded source deleted.
• Source provenance: whether the scan was black-box (live target only), or white-box from an upload or a git repo. Git URLs are recorded by host only — no paths or credentials.
• Attestations: isolated sandbox, sandbox torn down (verified against the container runtime), uploaded source deleted, spend cap enforced, and never used to train a model.
• Usage: tokens and LLM calls for the run.

Get it in the app on any run under Data trail — chain of custody (with a one-click JSON download), or over the API at GET /api/runs/{run_id}/trace.

Continuous scanning & drift

What: turns a point-in-time scan into ongoing coverage. Register your app as an asset, put it on a schedule, and Redthread re-scans it for you — and re-checks whenever it changes.

How: two controls, set per asset in the Continuous view (or over the API):

• Schedules — a daily, weekly, or monthly cadence. Re-scans run down the same path a manual scan does, so your quota, concurrency, and spend caps all still apply.
• Drift detection — turn on watch changes and, between scheduled runs, we re-fingerprint the app (preferring its OpenAPI/Swagger spec). A material change kicks off an out-of-cycle scan. Fingerprints ignore CSRF tokens, nonces, timestamps, and cache-busters, so a dynamic page doesn't false-trigger.

Why: apps change every release, and a yearly pentest can't see a hole a Tuesday deploy opened. Continuous scanning catches regressions when they land; drift means you only spend a scan when something actually changed — hands-off monitoring instead of a calendar reminder.

Tools: the same scan engine driven by a per-asset scheduler; app fingerprinting from the OpenAPI/Swagger spec (or a normalized surface crawl), diffed between runs with dynamic-token noise filtered out.

Dashboard & trends

The home Dashboard is the risk read, not the activity log. It opens on a risk band of four tiles — proven attack paths (of how many risks, from how many open findings), open findings by severity with the opened / resolved delta against the previous scan, coverage (registered assets, cloud connection, endpoint hosts, age of the last scan), and Agentic Trust & Protection Platform state (safe / unsafe / degraded agents, or off). Beneath it, the top three attack paths from Redthread are drawn as hop chains — Internet → web-01 → data-ingest-role → customer-records — each marked Proven · PoC or Potential, ranked by severity, proven before potential. Recent scans sit below.

Every tile and panel carries a one-line description of what it counts. The Coverage tile counts how many of the four clouds (AWS, Azure, Google Cloud, Oracle Cloud) are connected and names them.

Every tile is a saved query: clicking it opens the view that produced the number, already filtered — a severity bar opens Findings on that severity, a path opens the ranked risk it came from, coverage opens Targets, the trust tile opens Assess. Open-finding counts are taken from the latest scan of each registered asset (a rerun never double-counts); a workspace with no registered assets reads its latest scan instead. The figures come from /api/cloud/risks, /api/overview, /api/cloud/status, /api/endpoint and /api/trust-signal/status.

Below the paths sit three more panels. What changed since last scan lists each registered asset with its opened / resolved count against the previous scan and its next scheduled run — assets with newly opened findings sort first, and a row opens that asset's latest scan. Next actions is derived from state you already have: auto-fix pull requests ready to merge, shadow-AI candidates waiting to be confirmed, exposed credentials to rotate (from ranked risks), and the proven path to fix first. Open findings · 8 weeks is a sparkline summed across your registered assets (each asset's latest open count carried forward week to week, from /api/assets/<id>/trend), with a ↑ / ↓ arrow against the prior week that is repeated on the severity tile; it appears after the second scan of a registered asset.

Executive view. The Analyst / Executive toggle at the top of the Dashboard switches the same numbers one altitude up: the proven-path figure with its funnel line, a plain-language summary written from the current state (what Redthread maps, what is proven, open findings by severity, the change since the previous scan, agent trust, and the next action), then coverage, trust, severity and the 8-week trend, and the top attack paths. Scan mechanics are hidden. Executive is the default view; the Analyst view is one click away and the choice is remembered in the browser.

Saved views. On a scan's Findings, the severity / PoC / exploited chips filter the list; ＋ Save view keeps the current severity filter and dismissed-toggle under a name, per workspace in your browser, and the saved views appear as ★ chips beside the filters.

The console navigation is grouped by what you are doing rather than by scan type: Overview (Dashboard) · Connect (the scan types; registered targets are managed under Settings → Targets) · Explore (Redthread Flow, Assess & Consolidate, Chat, Cloud issues; Knowledge opens from the Knowledge pill on the Chat page) · Handle (Findings, PR Reviews) · Govern (Assess & Consolidate, Settings).

The Continuous view rolls up every registered asset in one place, so a security lead — or a board — can see the whole estate at a glance and prove it is moving in the right direction. It is fed entirely by the scans your schedules and CI already run; there is nothing extra to instrument.

Per-asset rollup — GET /api/overview. Each asset shows its latest scan status, findings by severity, the opened / resolved delta versus the previous scan, and its schedule and next run. You see not just where an asset stands, but what changed since last time.

Risk trend — GET /api/assets/<id>/trend. Every asset carries a findings-over-time series — each scan oldest → newest, with the open count and the number opened and resolved at that step — so you can show risk trending down over weeks, not just a single snapshot. This is the sparkline behind the dashboard.

Export — GET /api/overview.csv. One click exports the whole-org rollup as CSV for a spreadsheet, a QBR deck, or your own BI.

Shadow-AI discovery (AI inventory)

What: finds the AI your organization is using that security doesn't know about — "shadow AI." Repositories quietly calling an LLM API, managed AI services switched on in a cloud account, self-hosted model servers or chatbot UIs exposed on your domains. It is a discovery and inventory capability: it tells you where AI exists, not whether it's vulnerable.

How: connect the surfaces you want looked at, and each run reports exactly what it covered. Every result is a candidate you confirm — it never registers anything on its own. Confirmed candidates merge into one deduped AI inventory with a coverage banner; dismiss the ones already known or out of scope.

Why: you can't secure or govern AI you don't know you have. Shadow AI is where data leakage, runaway cost, and compliance gaps hide — an inventory is the first control. What you confirm here becomes the set that gets tested and monitored. See Discovery & inventory.

Tools: GitHub org/repo API + LLM-SDK usage detection (repos); agentless cloud enumeration via boto3 — Bedrock, SageMaker, Lex, Comprehend (cloud); HTTP/TLS surface probing for model servers and OpenAI-compatible endpoints (external). All agentless.

AI supply chain

What: the risk that comes from the AI components your app is built on — third-party foundation models, fine-tuned or pretrained weights, training and RAG datasets, embeddings, plugins/tools, and the ML/LLM libraries and model registries in your stack. A poisoned model, a backdoored dataset, a typosquatted model on a hub, or a vulnerable ML dependency can compromise your app before you write a line of code. This is OWASP LLM03:2025 Supply Chain.

How: during a scan the agent inspects the AI components in scope — where models and datasets come from and whether that source is trusted, how plugins/tools are wired and how much they're trusted, and the dependency tree of your ML/LLM stack. Dependency CVEs are triaged by real exploitability (KEV / EPSS) and reachability, so you see the ones that actually matter rather than a wall of noise.

Why: your AI app is only as trustworthy as the models, data, and libraries it inherits — and those come from outside your codebase, bypassing your app-level controls. It's on the OWASP LLM Top 10 for exactly that reason.

Tools: osv-scanner for the dependency CVE inventory, then the EPSS / CISA-KEV / reachability triage funnel (see Dependency CVEs); our LLM skill pack maps findings to OWASP LLM03 and MITRE ATLAS AI Supply Chain Compromise (AML.T0010).

Infrastructure & Cloud

What: cloud security posture management (CSPM). Beyond the app, it checks your cloud for the exposures attackers hunt for — public buckets, over-broad IAM, ports open to the world, unencrypted or public data, and blind spots in your audit trail. agentless, CVSS-scored.

How: connect an agentless role and we assume it, enumerate read-only, and run deterministic checks — no keys, no write access. A finding fires only on a resource that actually fails a check.

AWS in two clicks, no command line. Press Open AWS and create the role: it opens the AWS CloudFormation console with everything filled in — our scanner, your unique external ID, and a read-only role (ReadOnlyAccess + SecurityAudit) named millenniums-cloud-scan. Tick the IAM acknowledgement box, click Create stack, wait about a minute, then type your 12-digit AWS account number back in the app. We build the role ARN ourselves and prove it with one real read-only call before storing anything; if the stack is still creating you're told to wait and retry, not handed an error. To revoke, delete the MillenniumsCloudScan stack. Already created millenniums-cloud-scan earlier (for example with the Terraform)? The stack will report that the role already exists — skip it and just enter your account number; the existing role works as long as it trusts our scanner with your external ID. The template is public and short — read it before you run it: millenniums-cloud-scan-v1.yaml. Prefer Terraform or your own role? The Infrastructure page still generates the Terraform and takes a role ARN.

Not the person who manages AWS? From the Estate Scan page, Get a link to send them creates a private link that opens those same two steps for whoever runs your AWS — no account needed on their side. It can do exactly one thing: connect AWS for your workspace. It shows only your company name, never your email or findings; it expires after 7 days; and making a new link cancels the previous one. Your Estate Scan lane turns green when they finish.

Azure, Google Cloud and Oracle Cloud connect in one click too, with nothing to copy or paste. Azure: sign in with Microsoft and approve Redthread; Azure opens a pre-filled deployment that grants our scanner Reader + Security Reader on the subscription you pick. Each grant carries a marker unique to your workspace, and we connect only a subscription whose grant carries yours. Google Cloud: sign in with Google, pick a project you own, and we add Viewer + Security Reviewer for our scanner on that project with your sign-in; your Google token is used for that one change and then dropped. Oracle Cloud (OCI): Oracle opens a pre-filled Resource Manager stack that creates a RedthreadCloudScan group and an API-key-only user (with an email address, which Oracle accounts on identity domains require), a read-only policy (inspect all-resources, plus read on bucket, network and user settings — never file contents, database wallets or VM console output) and uploads your workspace's public key, then reports the user back to us. In every case you hand us no secret, revoking is one click in your own console, and every connection is verified with a real read call before it is stored. Prefer the command line? Each cloud still offers the manual commands (an Azure app registration, a GCP service-account key, or OCI Cloud Shell); secrets you paste there are write-only — never returned by any screen or API. Kubernetes and any Prowler inventory can still be ingested directly. See the API.

Why: your app can be flawless and still be breached through the infrastructure it runs on — and posture drifts every time a team ships. Because it's agentless, it's safe to run continuously, not once a quarter.

Tools: agentless cloud enumeration via boto3 (AWS) against a role you grant (ReadOnlyAccess + SecurityAudit), then our deterministic, CVSS-scored posture checks. Any Prowler-format inventory can be ingested instead, and the same checks run for GCP / Azure / Kubernetes.

Redthread — risk graph & attack paths

Redthread is our graph engine. It is the layer underneath the attack-path report, the pull-request gate, the query builder and the runtime sensor — all four read and write the same graph, which is why they never disagree with each other.

What: every asset, identity, network route and finding across your clouds, in one normalized graph — and the ranked list of attack paths through it. A finding says "this bucket is public." A risk says "the internet reaches this workload, which holds a credential, which reads your customer data." The path is the product.

How: provider terminology stops at the collector. An AWS role, an Entra ID service principal and a GCP service account all become the same kind of node, so a path can cross a cloud boundary. Eight rules run over the result — exposed workload → sensitive data, credential chains, cross-cloud pivots, privilege escalation, shadow data, exposed AI assets, and proven cross-layer chains. Each returns a path, not an alert.

Why: posture tools produce hundreds of criticals and no priority. Ranking by CVSS alone tells you nothing about whether an attacker can actually get there. Reachability is the priority, and reachability only exists in a graph.

Tools: Redthread is the engine; the file is not proprietary. The graph is emitted in graphify's node-link format, so you can traverse it yourself — graphify path "internet" "customer-data" — or download it from the Risks view. No graph database to run, and no lock-in: if you leave, the graph leaves with you.

Architecture & validation

Customers can read this section in the app: sign in and open any docs link.

Redthread Flow — reading the graph

Redthread Flow is the console panel where you ask the graph a question and get the answer drawn rather than listed. It sits in the left-hand nav, directly under Dashboard.

Estate map. Redthread Flow opens on your whole estate as a network. Every asset is a dot coloured by where it lives (orange for AWS, teal for Oracle Cloud, blue for Azure, green for Google Cloud, purple for your machines with sensors, pink for outside identities, black for the internet) and sized by what it is, so machines, workloads and AI agents stand out. Assets of one cloud pull together into a lightly shaded area, and a cloud with three or more assets gets a labelled marker at its centre. Ordinary links are thin blue lines; links that cross from one cloud to another are red, and attack paths are thick lines in their severity colour. A wildcard permission (a role allowed everything on every store) is drawn as one line to an “Every data store” hub for that cloud, not one line per store. Names are short (for example aws-ecs) and sit on small white labels that never overlap one another; the internet, the hubs and every asset on a critical or high attack path are always named, and the rest appear as you zoom in. Assets with critical or high issues carry a red ring. The map is drawn with Sigma.js, so estates with thousands of links stay smooth, and hovering an asset greys out everything it does not touch.

Highlight risks. The map opens with Highlight risks switched on: everything that is not a problem turns light grey, so what stands out is every asset with critical or high issues (named, on a red label) and every critical or high attack path. The panel on the right lists those attack paths; click one to show only that path and zoom to it, and click it again to go back. Switch Highlight risks off to see the whole estate in its cloud colours.

Reading it: scroll or use + and − to zoom, drag the background to move, drag a dot to place it, and Fit to reframe. A coloured ring and a number mark issues (the ring is the worst severity); a small green dot means a sensor reports from it. Click a dot for a card with its details, issues and links; its neighbours stay lit and the rest fades. You can hide identities, or show only the links between clouds.

Ask the graph is the second tab: the question-and-answer view described below. Attack paths is the third tab: the ranked chains from the internet to something worth protecting. Cloud issues has its own page in the left menu, under Chat, listing every misconfiguration across your clouds, filterable by cloud.

Using it

The panel opens with a graph already drawn. It runs the saved questions in order and stops at the first that returns a path, highlighting which one it chose — so you land on a real answer rather than an empty canvas. There are three ways to ask your own:

• Plain English. Type a question — "is anything on the internet holding a key that reaches customer data in another cloud?" — and press Ask. A model translates it into a structured graph query. The query it ran is always shown under "the query I ran": expand it and confirm it understood you. If the question is outside what the graph can express, it says so and names what is missing, rather than running the nearest query that happens to validate. An answer to a question nobody asked looks exactly like an answer.
• Saved questions. The buttons below the box are the common ones, already written: exposed VM with a leaked key that reaches PII in another cloud, workloads holding a credential that reaches a data store, identities that can become another identity, sensitive stores reachable from the internet, and others. Click one to run it.
• Build it by hand. Expand Build it by hand for dropdowns: find [asset kind] in [cloud] that is [exposure], connected by [relationship], to [asset kind] holding [data classification]. No query language to learn.

Questions are rate-limited per hour by plan — 10 on Free, 40 on Starter, 120 on Growth, 400 on Enterprise — because each plain-English question costs a model call. Saved and hand-built queries run against the graph directly and are not limited.

Reading the picture

The drawing is a layered flow, left to right: the direction of the arrows is the direction of the attack. The leftmost column is where an attacker starts — usually the internet — and the rightmost is what they reach.

Break the chain

Below the graph is the ranked cut list. Every hop in the full result set is scored by how many routes die if you cut it, and each row states the action (rotate and remove the credential, narrow the permission, close the exposure), why it works, and the evidence. The number on the left is routes broken. On a live AWS account the top cut — rotating one credential on one role — closed 86 of 1,382 paths.

What "no path matches that" means

An empty result is an answer, not a failure. Nothing in the current graph connects those things. Two honest caveats: coverage is whatever you have connected, so a path we cannot see is not a path that does not exist; and data classification is never inferred — a store stays unknown until DSPM samples it or you label it, so classification-filtered questions correctly return nothing on an account that has not been classified yet. Run a scan with classification enabled and they start answering.

Attack path analysis — what it is

Attack path analysis maps the routes an attacker could use to move through your environment and reach the assets that matter. It exists because individual scans produce thousands of findings without showing which of them chain into something exploitable. A misconfiguration alone is rarely a breach; a misconfiguration plus a weak permission plus an exposed host is.

Four steps, and we run all four:

1. Asset and risk discovery. Full agentless visibility of workloads, identities, configurations and data — plus vulnerabilities, exposed secrets, misconfigurations and excessive permissions. On a mid-sized AWS account this is typically several hundred assets and tens of thousands of permission relationships.
2. Graph-based mapping. Those risks are placed onto one graph that connects the resources and shows how they relate — a workload with a public IP and a critical vulnerability, linked to an over-privileged identity. Every edge carries a confidence: proven, extracted from configuration, or inferred.
3. Path identification. The graph is searched for toxic combinations — sequences where several individually low-severity issues chain into a high-impact route to something valuable. Eight rules run over it, each returning a path rather than an alert.
4. Prioritisation. Paths are ranked by severity, then proven before theoretical, then how direct the path is, then blast radius. A route to a crown-jewel asset or to elevated privilege ranks above one that ends somewhere harmless.

A note on how the search works, because it changes the answers. A plain shortest-path search finds the shortest route to each target — which is frequently not the route that matters. A publicly readable bucket is reachable in one hop, and that one hop hides the three-hop credential-theft chain that reaches the same bucket. So a rule that depends on a specific kind of hop searches through that hop explicitly, and the chain is reported rather than masked.

Cross-cloud risk

What: the attack paths that begin in one cloud and end in another — the ones neither provider's own tooling can see, because each only looks at itself.

How: we read the trust relationships that actually cross the boundary: an AWS role whose trust policy names an Entra ID or Google issuer, a GCP workload-identity pool trusting an AWS account. Both sides must agree before an edge exists — a granted permission alone is never enough.

On the graph: a confirmed cross-boundary trust becomes a can-assume edge between clouds, and any attack path that crosses it is ranked as a T3 — cross-cloud pivot risk on GET /api/cloud/risks, with the full edge-by-edge path and its evidence, ordered proven-before-potential. Because the graph exports as open node-link JSON you can also traverse it yourself: graphify path "aws-prod" "azure-tenant" --graph graph.json.

The over-broad trust is its own finding. A role whose trust policy has no sub (subject) condition trusts every identity in that external tenant, not the one you meant — easy to ship by accident when copying an OIDC snippet, and a critical finding on its own even before any path is drawn.

Beyond identity trust, three more links between clouds.

• Network: site-to-site VPN tunnels on AWS, Oracle Cloud, Azure and Google Cloud are read on each side and matched by their public IPs, so a tunnel from AWS to an Oracle gateway shows as one link between the two networks.
• Observed use: AWS CloudTrail records the address behind every API call in the last 24 hours; a call that came from a VM in another connected cloud draws a proven link from that VM to the AWS identity it used.
• Keys made for use elsewhere: Oracle's S3-compatible keys are listed with the user they belong to. Cloud keys found in your code, and Oracle sign-in federation on accounts using identity domains, are not covered yet.

Why: federated identity is how teams avoid long-lived keys — and it is also how an attacker moves between your clouds. Neither AWS, Azure, nor GCP flags a trust the other side extended, so this is exactly the blind spot single-cloud posture tools leave open.

Tools: AWS IAM trust policies, Entra ID via Microsoft Graph, GCP workload-identity federation. Issuers are identified, never guessed — an unrecognised issuer produces no cross-cloud edge, because a mislabelled one is worse than a missing one.

Data security posture (DSPM)

What: what is actually in your data stores — personal data, cardholder data, health data, credentials — and where a copy of production has quietly ended up.

How: two tiers. Bounded sampling reads a small, capped sample of objects through the same agentless role you already granted — no snapshots, no extra permissions, nothing installed. For unmanaged databases living on a VM disk, an ephemeral snapshot worker runs inside your account, mounts a snapshot read-only, and transmits findings only — never a value, never file contents, never a row — then terminates.

Shadow data: stores are schema-fingerprinted, so a production schema sitting in a staging bucket is flagged as a copy worth reviewing — and escalated to critical when that copy is also internet-exposed.

Why: severity is meaningless without knowing what is at stake. A public bucket of CSS files and a public bucket of customer records are the same finding and completely different risks. Classification is what separates them — and it is why we never guess: an unlabelled store stays unknown, never assumed safe and never assumed sensitive.

Tools: pattern + entropy classifiers with validity checks (Luhn, SSN structure), column-name corroboration, and schema fingerprinting for lineage. Bounded per object and in total; coverage is reported as what was actually sampled, never extrapolated.

Code-to-cloud — stop it before it ships

What: a check on every pull request that reads your Terraform, CloudFormation, ARM and Kubernetes manifests and fails the build when a change would create a real problem.

How: the planned resources are merged into your live risk graph, and we report what the change would introduce — not what your account already looks like. Findings post back to the pull request as a single comment that is edited on each push, never a new one each time.

The gate blocks on exactly what your diff is responsible for: a critical misconfiguration it declares, an attack path it introduces, or a credential it commits. Pre-existing account risk never blocks a pull request — that is how a gate gets switched off. Report-only mode is a one-line change.

Why: the cheapest moment to fix a misconfiguration is before it exists. Everything after that is remediation, a change window, and an argument about priority.

Tools: a real HCL parser (not line matching), plus CloudFormation / ARM / Kubernetes. Secret scanning excludes placeholders and variable references — a scanner that flags password = var.db_password trains people to ignore it. Ships for GitHub Actions and Azure DevOps; authenticates with a per-asset key, never your account token.

Ask the graph

What: saved questions and a query builder for the ones we did not anticipate — "show me every internet-exposed VM holding a plaintext key that grants access to a store containing personal data."

How: pick a kind of asset, filter on its attributes, then follow a relationship to what it can reach. Results are paths with the evidence for each hop, not a list of names.

Why: your questions during an incident are not the ones a vendor pre-wrote. Free-text search cannot express "A and B and reaches C" — that is set membership and reachability, which needs the graph.

Tools: a closed, safe query form — a query is data, never code, with validated relations and bounded traversal, so it can neither be turned into code execution nor hang on a large estate.

Remediation & ticketing

What: a signed webhook when a risk matches your rules — wired to your own automation, or straight into Jira or ServiceNow with the attack path in the ticket.

How: you register a workflow with POST /api/workflows — { name, url, kind: "webhook|jira|servicenow", rules: ["T2"], min_severity: "critical", proven_only: false, auth_header }. A delivery fires only when a risk matches all of your filters: one of the named graph rules (T1–T8), at or above min_severity, and — if you set proven_only — only when the path was actually exploited, not merely reachable. The signing secret is returned once and never again; POST /api/workflows/<id>/test fires a synthetic delivery so you can prove the wiring before a real event.

Verify every delivery. Each request carries an HMAC signature in the X-Millennium-Signature header over the raw body; recompute it with your secret and reject anything that does not match. Deliveries are replay-bounded (a timestamp + nonce), and destinations must be HTTPS resolving to a public address — a webhook can never be aimed at an internal service or a cloud metadata endpoint.

Prevention, upstream: the same risk graph powers the code-to-cloud PR gate — POST /api/iac/scan fails a pull request that would introduce a critical attack path against your live graph, so the cheapest fix (never merging it) happens before there is anything to remediate.

Why: a security vendor holding write credentials across your cloud is a single point of catastrophic failure, and the hardest thing to get through a security review. Splitting detection from execution removes both problems.

Runtime sensor Enterprise add-on

What: optional runtime detections from your Kubernetes nodes, Linux VMs and machines with the endpoint sensor, landing on the same risk graph as everything else.

How: a Falco DaemonSet that posts its detections straight to Redthread, plus a small heartbeat sidecar so a quiet node still shows online. Enable it in the app, add a sensor, and run the three commands shown. Turning it off revokes every sensor immediately.

Linux VMs: run the one command shown after you enrol a sensor on the VM, as root. It installs Falco from the official falco.org package repository, picks its modern eBPF probe (Linux 5.8 or newer, no kernel module), writes a root-only config that posts each detection to Redthread, and starts Falco as a service that survives a reboot. Falco's HTTP output cannot set headers, so the sensor key is part of the URL in that config; the key can only post detections. Debian and Ubuntu (apt) and RHEL, Oracle Linux, Amazon Linux and Fedora (dnf or yum) are supported; run the same command with --uninstall to remove it.

Every VM in a cloud: the Cloud Shell fleet commands also install Falco when you add MAI_SENSOR_KEY (Runtime → Add a sensor shows them filled in). On Azure (Run Command runs as root) and Google Cloud (gcloud ssh with sudo) every Linux VM gets Falco; on Oracle Cloud, Run Command runs as a limited user, so Falco installs only on VMs where the one-time admin setting gave that user sudo, and the summary names the others.

Machines with the endpoint sensor: the endpoint sensor also checks running processes every 20 seconds for a crypto miner, a reverse-shell pattern, or a program running from a temporary folder, and sends a detection the first time one appears (once an hour per match). It needs no kernel access and works on macOS and Linux; it cannot see anything shorter than one check, so Falco remains the thorough option on Linux. Command lines are matched on the machine and never sent: a detection carries the rule, a short process name and the time. Detections are accepted only while Runtime is on; otherwise the sensor stops sending for six hours.

Why: configuration drifts and a workload can be compromised without a single setting changing. Provider threat feeds catch a lot of that with no agent at all — this is for teams who have decided that sub-minute, in-kernel visibility is worth a privileged DaemonSet, and it is deliberately their decision rather than our default.

Detection, not prevention. It never blocks, kills, or quarantines. The rest of the platform installs nothing on your servers; this deliberately does, which is why it is a separate add-on and off by default. If you would rather stay fully agentless, GuardDuty, Security Hub and Inspector findings are ingested onto the same graph with no agent at all.

Tools: Falco (CNCF) for the eBPF probe and rule set. The heartbeat sidecar is unprivileged and drops all capabilities. Ingest is capped; over the limit, events are dropped and counted, never lost silently.

Network penetration testing — the phases

Customers can read this section in the app: sign in and open any docs link.

Compliance report & attestation

Every completed scan produces an audit-support report grounded in the standards enterprises test against (PTES, NIST SP 800-115, OWASP WSTG, CREST, CVSS). It ships in three tiers so each reader gets the right cut:

• Letter of Attestation — a redacted, signed one-pager you can hand to your customers, procurement, or third-party-risk reviewers. It has the scope, dates, methodology, and severity counts — no exploit detail. Get it at GET /api/runs/{id}/attestation.
• Full compliance report — executive summary plus per-finding technical detail: Rules of Engagement, a severity heat-map, a remediation roadmap, and an AI traceability matrix mapping each finding to OWASP LLM 2025 → MITRE ATLAS → NIST AI RMF / ISO 42001 / EU AI Act. Cross-mapped to SOC 2, ISO 27001, and NIST CSF. GET /api/runs/{id}/compliance.
• JSON twin — the same data as report.json for Vanta, Drata, or Secureframe. GET /api/runs/{id}/compliance.json.

Honest scoring. CVSS is a real advisory score for dependency CVEs, or the standard class base vector for a vulnerability class (labeled as such) — never a fabricated number. Behavioral findings (jailbreaks, prompt injection) carry an Attack Success Rate — a real successes/trials figure — when you measure one (POST /api/runs/{id}/measure-asr), because a jailbreak that fires 3 times in 100 isn't one that fires 90.

Tools: CVSS 3.1 scoring; OWASP LLM 2025 + MITRE ATLAS v5.6.0 traceability; framework cross-maps to PCI DSS 11.4, SOC 2, ISO 27001 / 42001, NIST CSF / AI RMF, EU AI Act; OpenVEX for affected/not-affected determinations; and Attack Success Rate reported with a Wilson 95% interval. Optional certified CREST/OSCP human review.

SSO, SCIM & roles

What: enterprise identity for teams — single sign-on, automatic user provisioning and deprovisioning, role-based access, and an audit log. Every asset, scan, and finding is scoped to your workspace.

How: four roles — owner (everything, incl. billing), admin (manage the workspace), member (do the work), viewer (read-only) — plus:

• Single sign-on (OIDC) — your team signs in with your identity provider (Okta, Entra/Azure AD, Google, Auth0); new users in your email domain are provisioned automatically. Owner-configured with an issuer URL, client ID/secret, and your domain.
• SCIM 2.0 provisioning — your IdP creates and, critically, deprovisions users automatically. Deactivating someone in your IdP cuts their access here immediately: their tokens are revoked, not just a flag flipped.
• Audit log — who triggered which scans, and who viewed or exported which reports.

Why: at team scale the risk isn't only outside — it's a former employee whose access never got cut, or an over-privileged account. SSO centralizes sign-in on your IdP's policy (MFA, conditional access); SCIM guarantees off-boarding is instant, not a ticket someone forgets.

Tools: OpenID Connect (OIDC) for SSO — Okta, Microsoft Entra ID, Google Workspace, Auth0; SCIM 2.0 for provisioning/deprovisioning; per-tenant bearer tokens with constant-time comparison and immediate revocation. Enterprise plan. See SSO & SCIM to set it up.

Guide: run your first scan

Goal: go from a fresh account to a proven finding.

Prerequisites

• A verified account (browser quickstart).
• A target URL — a live, running instance of your app that you own or may test. Use a staging URL, not production. This is required; your code alone isn't a running app. Don't have one? See What to point it at.
• Optional, paid plans: your source — a git repo URL or a .zip upload, for a deeper white-box scan.

Steps

1. Open the app and paste your target into the scan box, or call POST /api/scan.
2. If you have the source, add it — a repo URL or local path in the source field. This is the single biggest lever on finding quality.
3. Start the scan. Note the run_id.
4. Wait for it to finish (status running → false). Minutes, typically.
5. Open the report and triage from the top: criticals first.

Troubleshooting

• 403, "verify your email" — click the verification link, or hit "Resend" / POST /api/resend.
• 402, quota reached — no included or pack scan left. Buy a scan pack in Billing (plans).
• 500, "scan did not start" — the engine couldn't launch (Docker or the model key). For self-hosted, check your .env; on our hosted app, retry.
• Zero findings on a URL-only scan — provide source and re-run. Black-box alone often misses AI-specific paths.

Guide: register a target

If you scan the same app repeatedly, register it once on the Targets tab instead of pasting it in every time. Each target remembers its own settings, so a re-scan is a single click on Scan now. Registered targets are also what the CI plans scan automatically on each pull request.

What each field does

What happens when you click Scan now

1. Your settings are checked, and anything that can’t work is caught right away — for example Changed files only needs a code repository, so you’re told before the scan starts rather than after it fails.
2. Your plan and spend cap are applied, so a scan can never run past your budget (see Spend caps & safety).
3. The test runs in a throwaway, isolated sandbox — your code is never reused or kept (see Your data).
4. When it finishes, the results appear under Pentest Findings (see Read your scan results).

Guide: read your scan results

When a scan finishes, open it from the Scans list. Its results appear under Pentest Findings, organised into tabs so you never have to scroll to reach a section.

The tabs

Filter the findings

A large scan can surface hundreds of findings. The coloured pills above the list let you focus — click one to filter, click ✕ clear filter to see everything again:

1. Severity pills — Critical High Low — show only findings at that level. A big scan opens focused on the most severe by default, so the worst is in front of you first.
2. ⚡ PoC — show only findings that come with a working, proven exploit (the highest-confidence ones).

Every finding is also adversarially re-checked before it's shown: anything the scanner judges a likely false positive is hidden by default (a toggle brings it back so you can review the call yourself).

Read one finding

1. Start with Critical and High — those are what an attacker reaches soonest.
2. Open "Proof of concept" to see, in plain steps, exactly how the vulnerability is exploited. On paid plans, expand ▸ Exploit script for the actual runnable exploit so an engineer can reproduce it.
3. Read "Remediation" — the concrete fix — and the code locations.
4. Fix it (see the next guide) and re-scan to confirm the hole is closed.

Guide: fix what the scan found

On the Starter plan and above, with GitHub connected, Redthread can draft the fixes for you as pull requests — you review and merge; nothing changes on its own. Two one-click actions sit in the top row of a completed scan.

Before you start

• You're on the Starter plan or higher.
• You've connected GitHub (Integrations tab), and the scan used a GitHub repository as its source.
• The scan has completed — a scan that stopped early can be Resumed to completion first.

1. Fix your own code — ⚙ Generate fix PR

For application findings — flaws in your code, like broken access control or injection:

1. Open the completed scan and click ⚙ Generate fix PR in the top row.
2. It locates the code behind each finding, writes a minimal fix, and opens a draft pull request on your repo.
3. Click ↗ View fix PR to review it on GitHub.
4. Fix not quite right? Click ↻ Regenerate and tell it what to change or preserve (e.g. "keep the existing session check"). It retries with your guidance and updates the same PR — no duplicates.

2. Fix vulnerable libraries — ⬆ Update dependencies

For dependency findings — known CVEs in the third-party libraries your app relies on:

1. Click ⬆ Update dependencies in the top row.
2. It bumps each vulnerable package to its patched version in your editable manifests (requirements.txt, package.json) and opens a draft PR.
3. Vulnerabilities pinned in a lockfile (package-lock.json, poetry.lock, uv.lock) can't be safely edited by hand — the PR lists each with the exact command to run (e.g. npm install [email protected]).
4. Review the changes, run any listed lockfile commands, and merge.

Guide: scan on every pull request

On the Starter plan and up, a scoped scan runs on each pull request that touches your AI surface and blocks the merge on a proven, net-new vulnerability. Recurring findings are de-duplicated, so the pipeline stays quiet until something real appears. On the Starter plan and above, a confirmed finding can also open a draft fix pull request (and a dependency-update PR) your engineers review — nothing merges on its own. Review status is available at GET /api/pr-reviews.

Guide: scan with the GitHub Action

Wire scanning into any pipeline with our published GitHub Action. It scans on push and gates the build — or just notifies.

Install it from the GitHub Marketplace →

1. Get a trigger key. In the Continuous view, open your asset and click CI to reveal its per-asset trigger key and asset id. The key is scoped to that one asset — it can start and read that asset's scans, never your whole account.
2. Store it as a repo secret named REDTHREAD_SCAN_KEY.
3. Add the workflow at .github/workflows/security.yml:

name: security
on: [push]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: bl014h/redthread-scan-action@v1
        with:
          api-key: ${{ secrets.REDTHREAD_SCAN_KEY }}
          asset-id: "abcd1234"
          fail-on: high   # critical | high | medium | low | never

fail-on: never is notify-only — it runs the scan and posts a job summary, but never fails the build. Rotate a key any time from the same panel; the old one stops working immediately.

Guide: use Redthread in ChatGPT & Claude

Redthread runs an MCP server, so you can ask an AI assistant about your security posture in plain language: what changed since the last scan, which attack paths are proven, which AI services nobody reviewed. It works in ChatGPT, Claude and any client that supports remote MCP servers with OAuth.

1. Add the server. The address is https://app.redthreadsec.com/mcp. In Claude, open Settings → Connectors → Add custom connector. In ChatGPT, open Settings → Apps & Connectors and create a connector (this needs developer mode).
2. Sign in and allow. Your assistant opens a Redthread page. Sign in, check the workspace and click Allow.
3. Ask. For example: “What are my worst attack paths?” or “Show the findings from the last scan of the checkout API.”

The assistant can read your security overview, attack paths, scan findings and shadow-AI inventory, check an MCP server against Redthread’s signed registry scans, and start a read-only re-scan of clouds you already connected. It cannot connect new clouds, change settings, see keys or remove anything.

Guide: ask questions about a scan

Not sure what a finding means, or how to fix it in your stack? Ask. POST /api/chat takes a list of messages and, optionally, a run_id so the answer is grounded in that specific scan's findings. Use it to turn a report into a fix plan.

Plans, quota & overage

Plans are quoted to fit your estate and usage — request a quote on the pricing page. Your plan's quota and limits are shown in the app under Billing.

• What's a scan? One run against one target. A pull-request check and a full scan each count as one.
• Pentest scans. Each paid plan includes one pentest scan a month for every 10 workloads (rounded up; Starter 3, Growth 15). A bigger estate earns more. Past that, a scan uses a prepaid scan pack (5 or 20 scans, valid 12 months) or, with a card on file, is billed per scan.
• Free tier. One black-box scan of your website, for life (never resets), with one report for one reporting standard, so you can see a real finding before you decide. Source-code (white-box) scans, the working exploit, autofix, the full pentest report and the attestation letter unlock on any paid plan.

Existing customers can change plan from the app, or with POST /api/billing/checkout. For a new plan, talk to us.

Development phases

Customers can read this section in the app: sign in and open any docs link.

API reference

Customers can read this section in the app: sign in and open any docs link.