The platform · Redthread

Graph the entire estate first. Everything else follows from that.

Most platforms scan a layer and hand you a list. 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.

Start a scan Read the docs
Clouds
AWS · Azure · GCP
Access
agentless
Runtime sensor
Optional eBPF, off by default
Write access to your cloud
Never ours
How it works

Four steps, in this order.

Each step writes what it learns back into the graph, so the next one starts with more context than the last.

01
Graph the whole system
Connect agentless — Terraform for AWS, an app registration for Azure, a service account for GCP — and we build the estate: every AI agent, repository, workload, identity, network route and data store, plus the relationships between them. Credentials are verified with a real call before they're stored. Cloud and cross-cloud enumeration is operator-enabled per tenant.
Documented in
Identity & access Scanning
02
Inventory what you didn't know you had
Shadow-AI discovery finds the AI in your estate that nobody registered — agents and models in repos, managed AI services across your clouds, and endpoints exposed to the internet. Nothing is auto-registered: every result is a candidate an operator confirms, and every run states its coverage. Repo discovery is self-serve today; cloud and external enumeration is operator-enabled.
Documented in
Shadow-AI discovery
03
Scan, exploit, and constrain
Autonomous penetration testing against the AI applications you point us at — standard, deep, or complete, which chains a black-box pass into a white-box one. Excessive-agency testing shows what each agent's identity can actually reach. Network, cloud and detection scan types have proven reasoning cores but are off by default.
Documented in
Scanning
04
Defend with what you learned
Findings with evidence at every hop, mapped to MITRE and your compliance frameworks. Gate the build with the GitHub Action, put the asset on a schedule with drift detection, and let us write the patch as a draft pull request against your own repo. Runtime response — isolating a host, killing a process, quarantining a file — runs through a connected partner engine; ask us to activate it for your workspace.
Documented in
CI/CD Continuous Platform Reports

Five findings, and what actually happens next

A remedy nobody applies is not a fix. Where the fix is code, we write it and open a draft pull request against your repo. Where the fix is cloud configuration, we never touch it — we sign a remediation and hand it to automation you own.

Finding
Remedy
How it ships
Prompt injection exfiltrates another tenant's data
Constrain the agent's tool surface on untrusted input — allowlist the callable tools, drop the outbound one, require a human on the action that leaves your boundary.
Draft PR
Handler trusts a client-supplied tenant id
Scope the query to the caller's tenant server-side, so User A cannot read User B's records by changing a parameter.
Draft PR
Reachable CVE in a dependency
Bump the package to the patched version in the manifest that declared it, using the fixed-version data from a fresh scan of your repo.
Draft PR
An agent loop with no spend ceiling
Cap tokens and spend per request, so a runaway or attacker-driven loop stops at a ceiling you set instead of exhausting the budget.
Draft PR
Public bucket holding personal data
Remove public access and re-scope the policy — escalated above the other public buckets because this one is on a path from the internet to classified data.
Signed remediation
Trust

What we will never do.

Hold write access to your cloud
We detect and sign. A function you own and deploy holds the credentials and makes the change — so every modification lands in your audit trail, under your role.
Move your data
Content sampling is bounded and stays in your account. Where a disk needs deeper inspection, the worker runs inside your account and transmits findings only — never a value, never a row.
Merge our own code into your repo
Every auto-fix lands as a draft pull request and stops there. A machine-written security fix must be read by a person before it ships.
Claim more than we proved
Findings are labelled by how we know them: observed, reported by another tool, or proven by exploitation. Compliance mappings are evidence toward a control, never a pass.

Agentless by default. Connecting a cloud installs nothing on your servers. An optional eBPF runtime sensor is available for teams who want in-kernel visibility — off unless you turn it on, and it detects rather than blocks. Most customers never need it.

The whole product, in three moves

Know what you have. Prove what is reachable. Fix it at the source.

Six product areas, three jobs — and each one hands its context to the next. That is what the graph is for.

01
Know
Connect agentless and we build the estate — every agent, repo, workload, identity, route and data store — then find the AI nobody registered.
Products
Shadow-AI discovery Continuous Platform
02
Prove
An autonomous agent attacks your own AI application and walks the chain. Every finding carries a working, reproducible proof of concept — or it is not reported.
Products
Scanning Reports
03
Fix
A validated finding becomes a minimal patch in a draft pull request on your own repo, and the next pull request is gated against your live graph.
Products
Scanning CI/CD
Then it repeats without anyone remembering: schedules, drift detection and the CI gate re-run all three on every release. Explore the platform
One proven path, as the graph returned it
Critical · MITRE T1552 · T1530 Internet → web-01 → app-role → customer-data
web-01
Exposed workload
exploited
Credential in memory
app-role
Role assumed across accounts
customer-data
Read access to personal data
Exposed workload → credential in memory → read access to personal data. Found by traversing the graph, confirmed by exploiting it.
The engine · Redthread

Attackers see one graph. Now you do too.

An attacker never thinks in silos. They follow relationships — this agent holds that permission, which reaches that bucket. Your tools think in lists, which is why the risk that spans layers is the one nobody sees. Redthread connects your AI agents, source, cloud and infrastructure into the same picture an attacker builds by hand, then sends an autonomous agent to walk it and find the entry point for real.

Graph
Your whole estate — every agent, repo, workload, identity, network route and data store across AWS, Azure and GCP, agentless.
Scan
That graph, for the toxic combinations that exist only because two safe-looking things are connected.
Exploit
What matters — our AI agent attacks your AI application and walks the chain until it returns a working proof of concept or nothing at all.
Act
Gate the pull request before it ships, open the fix as a draft pull request on your repo, and — on Enterprise — watch what runs anyway with an optional eBPF sensor that detects and never blocks.
The secret sauce

“Could reach” is a guess. “We exploited it” is a fact.

Every other platform ends at the first half of that sentence. They read your configuration, calculate that one thing could reach another, and hand you the list to sort out. We run the attack — and what comes back is not a higher confidence score, it is a different kind of fact.

Their output · inferred
“this VM could reach that bucket”
Ours · proven
“we exploited the app, took the credential, read the bucket”

Same two assets. Completely different object in your priority list — one is a calculation, the other has a request, a response and a re-runnable proof attached.

We run the exploit
An autonomous offensive engine attacks your application the way an attacker would — prompt injection, tool abuse, excessive agency, the chain through to your data. Every finding ships with a working, reproducible proof of concept. If we could not prove it, we do not report it.
The result is written into the graph
A successful attack becomes a proven edge in your estate graph — a different object from an inferred one, not the same object with more confidence. Our top-severity rule refuses to fire without one, so “proven” can never be quietly assumed.
Your list is sorted by what was reached
Not by CVSS. Proven outranks potential, always, and the report never blurs the two. The thing at the top of your queue on Monday is the thing an attacker already got through — not the thing that scored highest in isolation.

Hundreds of criticals is not a priority list, and a finding is not a risk. On a real production account this turned 17 findings into one — the other sixteen were true, and unreachable.

Evidence

Nobody takes your word for it — not your auditor, not your customer's security team.

Every assessment produces three artifacts, because the people who need proof that you tested are rarely the people allowed to see how we broke in.

Letter of Attestation
Your legal name, the exact test dates, scope, methodology, severity counts and a signature — and no exploit detail whatsoever. Send it into a security review or a third-party-risk questionnaire without an NDA round-trip or a redaction pass.
The full technical report
For your engineers and your auditor: every finding with its evidence, a reproducible proof of concept, CVSS where it genuinely applies, the kill-chain narrative for chained exploits, and a phased remediation plan.
A machine-readable twin
The same assessment as structured JSON, so it lands in Vanta, Drata or Secureframe as evidence against a control rather than as a PDF somebody has to read and re-key.

Findings map to SOC 2, ISO 27001, ISO 42001, PCI DSS, HIPAA, NIST AI RMF, NIST CSF 2.0, the EU AI Act, and GDPR Articles 25 and 32. Those mappings are stated as evidence toward a control — never as a pass. We are not your auditor, and a vendor that tells you it has certified you has told you something untrue.

See a real finding in the next few minutes.

Start free — no card. Point it at a staging app and get real findings in minutes. The working exploit and the drafted fix unlock on a paid plan — then you scan on every release.

Start a scan See pricing