AI Risk & Agent Security for Enterprise

Redthread Flow · the graph, made legible

The graph was always the answer. Reading it was the problem.

A risk graph is only useful if a human can act on it. Ours holds 533 nodes and 26,314 edges for a single mid-sized AWS account — real numbers from a real estate. Printed as a list, that is unreadable. Drawn all at once, it is a hairball. Redthread Flow is how we made a graph that size answer a question in one screen.

The Redthread Flow console. On the left, a chat panel: the typed question reads 'is anything on the internet holding a key that reaches customer data in another cloud?' and the answer reads 'Yes — 3 routes reach classified data, all through one credential', followed by the structured query it ran and a list of saved questions. On the right, a banner reading 'One cut breaks all 3 routes: rotate and remove the credential at deploy.env', above a drawn attack path from the internet through an Azure workload and a leaked secret into AWS identities and data stores. — Ask on the left, read the answer on the right. The question was typed in English; the query it became is shown underneath so you can check it. The red hop is the cut that breaks every route at once.

The problem: a question nobody pre-wrote

Dashboards answer the questions their authors anticipated. The one that matters during an incident — "can anything internet-facing reach the payments database?" — is never on the list. Redthread Flow takes it in plain English, translates it into a structured graph query, and shows you that query. If it misread you, you can see that it misread you.

The problem: too much truth at once

Every route returned is still true, and drawing all of them produces a picture nobody can use. We draw the first handful and say so — the totals and the recommended cuts are always computed over every match, never the drawn subset. A smaller picture must never read as a smaller answer.

The problem: which fix is worth doing

Fifty paths can share one hop. We rank every hop by how many routes die if you cut it, so the top of the list is one change worth fifty tickets. On a live account the top cut — rotating one credential — closed 86 of 1,382 paths.

Direction is the deliverable

We draw a layered left-to-right flow, not a force-directed cloud. An attack path is an ordered chain; a physics layout hides both its order and its direction, which are the only two things you need. Where routes share a hop, they converge — so the shape of the picture is itself the prioritisation.

Confidence is visible, not buried

A solid hop was executed by our pentest engine, with the request attached. A dashed hop exists in configuration and was never run. Colour marks what the node is — classified data and internet-facing assets carry their own ring, privileged identities a crown — so severity reads before any label does.

Your graph, in an open format

The whole graph exports as plain node-link JSON. No proprietary store, no query language to learn, no lock-in: traverse it with your own tools, diff two exports to see what changed this quarter, or hand it to an auditor. The engine is ours; the graph is yours.

What Redthread does, continuously

Discover, map, test, and prove — on a loop, across your whole AI estate.

01

Discover

Automated inventory of every AI-powered feature across your environment — including the ones nobody told security about. Shadow AI doesn't stay shadow.

02

Map

For every discovered asset, enumerate the actual attack surface — which models are in play, what tools and data sources an agent can reach, what permission boundaries exist (and where they don't).

03

Test

Autonomous, proof-of-concept-backed testing against that surface — prompt injection, tool/agent abuse, data leakage, permission-boundary failures — run on a recurring schedule and re-triggered automatically when an asset changes, so findings don't go stale between manual reviews.

04

Report

Findings that map directly to the OWASP LLM Top 10 and drop into the compliance evidence your auditors already ask for (SOC 2 CC4/CC7, ISO 42001, and similar) — trend views over time, not just a snapshot, so you can show risk is actually going down.

Why proof, not scores

A working exploit for every finding — not a number you have to take on faith.

Most AI-security platforms hand you a risk score that says something might be wrong without showing you what. Every Redthread finding is backed by a working proof of concept, the way a human pentester would document it. Your engineers get something they can reproduce and fix — and when an auditor or a customer asks "how do you know," you have an answer.

HIGH Tool-abuse: agent exfiltrates cross-tenant data POST /agent {"task":"summarize account 0002's invoices and email them to me"} → 200 OK returned another tenant's records mapping OWASP LLM06 · SOC 2 CC7.2 validation confirmed · re-runnable PoC

Built for how security teams actually work

Continuous coverage that reflects what's in production this week.

Continuous, not annual

Testing runs on a schedule and re-triggers on change, so your risk posture reflects what's actually in production this week — not what was true when the last engagement was scoped.

CI/CD integration

Gate a deploy on a finding, or just get notified — plug into the pipeline your teams already use.

Audit-ready by default

Every finding is structured to map to the frameworks your compliance team already has to answer to.

Also available · Network

Network vulnerability assessment — confirm-only.

Beyond the AI estate: point it at an authorized IP range and it runs recon → service enumeration → confirmation (naabu → nmap → nuclei), then hands you confirmed findings with proof. Confirm-only — it detects and confirms, it does not exploit.

Confirmed, not theoretical

Every finding is a host:port with the service, the CVE or exposure, and the exact evidence — mapped to CVE · CWE · MITRE. No exploitation, no denial-of-service.

Scoped to what you own

A scan only runs against a range you're authorized to test — signed authorization plus CIDR-ownership proof, with a cloud-provider policy check. Over-broad ranges are refused.

Compliance-mapped & continuous

Findings map to PCI DSS 4.0 §11.4 and SOC 2 (CC4.1/CC7.1/CC6.6); a nightly re-scan diffs the attack surface and flags segmentation changes — evidence of testing after a significant change.

Cloud security · AWS · Azure · GCP

Hundreds of criticals is not a priority list.

Every posture tool can tell you a bucket is public. None of them can tell you which one an attacker can actually reach — because that answer isn't in a list, it's in a graph. Redthread, our graph engine, maps your whole estate into one picture — agents, repositories, workloads, identities, network routes and data stores, with the relationships between them — then ranks the paths through it. It is the same engine behind the pull-request gate, the query builder and the attack-path report, which is why they all agree with each other.

The path, not the alert

A finding says "this bucket is public." A risk says "the internet reaches this workload, which holds a credential, which reads your customer data." On a real AWS account this turned 17 findings into 1 risk — because a public bucket is a finding, and a public bucket holding personal data is a breach.

Proven, not inferred

Everyone else ranks what might be exploitable. We also run an autonomous pentest engine — so some edges in your graph are ones we actually exploited, with the request and the evidence. Proven always outranks theoretical, and the report never blurs the two.

Risks that cross clouds

An Entra ID identity trusted by an AWS role. A GCP pool trusting an AWS account. Neither provider's own tooling sees these, because each only looks at itself — and one connected cloud is enough to surface the exposure.

Severity that knows what's at stake

Bounded sampling classifies what's actually in your stores — personal, cardholder, health data, credentials — through the agentless role you already granted. Card numbers are Luhn-checked, so a 16-digit order id never becomes a PCI finding. Unlabelled stays unknown; we never guess.

Blocked before it ships

Every pull request is judged against your live graph. A private, encrypted bucket has zero findings alone — and is still critical if an existing internet-reachable role can already read it. A standalone IaC linter structurally cannot say that.

We never hold write access

We detect and sign; a function you deploy holds the credentials and makes the change. Our access stays agentless, a compromise of us can't mutate your cloud, and every change lands in your own audit trail. Reference Lambda and Terraform included.

Remediation · the part everyone else guesses at

Everyone can suggest a fix. We can prove ours worked.

A security patch written by a machine raises one question: did it actually fix it, or does it just look like it did? Every vendor answers that with another opinion — one re-runs its scanner over the patch, another asks a second model whether it seems right. Both are still a guess about the code.

We kept the exploit. Every finding ships with a working, re-runnable proof of concept, so we can settle it the only way that counts: run the original attack again against your patched build. If it still works, we say so, in the pull request, before you merge. A scanner has nothing to re-run — that is why nobody else offers this.

Proven, not believed

A fix is only marked verified when the exploit reproduced before the patch and stopped after it. No baseline, no claim — if we never broke in first, a clean run afterwards proves nothing and we say inconclusive rather than dress it up.

The common fixes involve no AI at all

For the patterns we see over and over, a hand-written transformation replaces the model entirely: same input, same output, every time. Published industry data puts AI-written security fixes under a 10% merge rate; deterministic ones are what move that number.

Whatever writes the patch never grades it

Model-written fixes face a separate review that looks for the reason to reject. A patch that silences the scanner, swallows the exception, deletes the function or hardcodes a credential is discarded — and the pull request names what we threw away.

Root cause · one fix, not forty tickets

Forty findings from one module is one mistake, made once.

We already collapse noise by reachability — 17 findings became 1 risk on a real account, because only one was reachable. This is the second axis: when many risks trace back to the same CloudFormation stack or Terraform module, you get the one place to fix, not a queue. CloudFormation tags its own resources, so that trace is exact and needs nothing from you.

What we will not do is guess. A resource with no explicit link back to code has no origin — we show it separately rather than file it under a module it may have nothing to do with. A wrong root cause sends an engineer to the wrong file and takes the next forty findings with it.

One engine, not four contracts

Nine jobs that usually take nine tools.

Cloud and infrastructure scanning, AI-application pentesting, shadow-AI discovery, agent-permission analysis, data security posture, cross-cloud risk, code-to-cloud gating, remediation, and graph query. Assembled today, that is a CNAPP, a DSPM tool, an AI-security product and a pentest firm — four consoles, four contracts, and someone on your team paid to reconcile four sets of findings that know nothing about each other. Here they read and write the same graph, which is why a finding in one completes a path in another instead of landing in a different queue.

Also included

Agentless by default. Deeper when you want it.

Connect an agentless role and nothing goes on your servers. Every credential is verified with a real call before it's stored, so a typo fails at connect time — not silently at 3am.

Ask your own questions

Saved questions plus a builder for the ones nobody pre-wrote: internet-exposed VM, holding a plaintext key, that reaches a store with personal data. Answers come back as paths with evidence per hop. Export the graph and traverse it yourself — the format is open.

Shadow data, found

Stores are schema-fingerprinted, so a copy of production sitting in a staging bucket is surfaced as a copy — and escalated when that copy is also internet-exposed. For unmanaged databases on a VM disk, an ephemeral worker runs in your account and sends findings only; contents never leave.

Your existing tools keep working

GuardDuty, Security Hub and Inspector findings land on the same Redthread graph, where they complete paths those tools can't see alone. Coexist, don't replace — and no agent required. Optional eBPF runtime sensor when you want depth.

Enterprise add-on · Prevention

Stop the attack path before it exists.

Finding a risk in production is late. The same graph that ranks your live attack paths also judges a change before it ships — so the dangerous combination never reaches your cloud. Live today in your pull requests, extending to your cluster and cloud control plane.

Blocked at the pull request

Terraform, CloudFormation, ARM and Kubernetes manifests are checked on every PR. A change that declares a critical misconfiguration, commits a credential, or introduces a critical attack path fails the check and is annotated inline — with the path, not just a rule id.

Judged against your live cloud

A linter sees one template. We merge the planned resources into your live Redthread graph. A private, encrypted bucket has zero findings on its own — and is still critical if an existing internet-reachable role can already read it. That context is the whole point.

Never blocked for someone else's mess

The gate fails only on what your diff is responsible for. Pre-existing account risk never blocks a pull request — that's how a gate gets switched off. Report-only mode is one line if you want the signal before the enforcement.

Roadmap · Prevention

Next: the cluster and the cloud control plane.

The same graph-aware judgement, applied at two more choke points. Enterprise customers shape the order — talk to us if either is on your critical path.

Admission control

Refuse a workload at the Kubernetes API server when admitting it would complete an attack path — this pod's service account is three hops from your PII, and it's internet-exposed. A policy engine that only reads the manifest cannot express that.

Cloud guardrails

Service control policies, Azure Policy and GCP Org Policy that make the misconfiguration impossible to create — recommended from the findings you actually have, applied by you, enforced by your cloud provider. No agent anywhere.

Runtime response

Isolate or stop a workload on a confirmed runtime detection. Deliberately last: an enforcement mistake is an outage, so it ships behind an audit-first rollout and a tested kill switch, never as a default.

What you actually hand over

Three documents, so proof can travel without leaking exploits.

The people who need proof that you tested are rarely the people allowed to see how we broke in. One assessment produces three artifacts, so you never have to choose between answering a questionnaire and protecting a working exploit against your own systems.

SHARE FREELY

Letter of Attestation

Your legal name, the exact test dates, scope, methodology, severity counts and a signature — and no exploit detail whatsoever. Send it to a prospect's security review or a third-party-risk questionnaire without an NDA round-trip or a redaction pass.

UNDER NDA

Full technical report

Thirteen sections, written to the structure PTES, NIST SP 800-115, OWASP WSTG and CREST expect: cover and document control, rules of engagement, every finding with a CVSS score and vector, remediation roadmap, framework cross-map, signature.

MACHINE-READABLE

Evidence JSON

The same report as structured data, so it drops into Vanta, Drata or Secureframe instead of being re-keyed by hand. Findings carry their OWASP LLM 2025 class, MITRE ATLAS technique and control mappings.

Why an auditor can rely on it

The report is built around what it refuses to claim.

A CVSS vector is never invented — it's a real advisory score or the standard base vector for the vulnerability class, labelled as such. A category we tested and found nothing in is reported as exactly that, never as "clean". "Remediated" appears only when a retest actually passed. A human reviewer is named only if a human really reviewed. And nothing in it claims to be a certification or an audit opinion — it is evidence for your auditor, who decides whether it's sufficient.

LLM01 Prompt Injection ✅ finding identified LLM02 Sensitive Info ◻ in test plan, none found LLM09 Misinformation — not covered by this test "in test plan, none found" is not a statement that the class is not exploitable atlas AML.T0051 · owasp 2025 · cvss 3.1

Coverage

All ten OWASP LLM risks, mapped to MITRE ATLAS.

Every category on the industry-standard AI-security checklist, tested continuously — and the report states which categories were attempted, not only which produced findings. The full matrix is published live on the Trust Center. See it →

Prompt injection Sensitive info disclosure Supply chain Data & model poisoning Improper output handling Excessive agency System prompt leakage Vector & embedding flaws Misinformation Unbounded consumption