Introducing Red Loop: continuous, proven testing of your whole attack surface

Today we're launching Red Loop, continuous offensive testing built into Strobes Attack Surface Management. It finds what you own, scans it the same way every time, and sends the results to agents that attack and validate them. Only findings with proof behind them reach your queue.

Below, we walk through how it works: how we find and attribute assets, the techniques the agents use, how each run is planned, and what a finding needs before it gets filed.

Your attack surface is bigger than your domain list

Most attack surface programs begin and end with DNS. You get subdomains, open ports, maybe a TLS report. The places where breaches actually start rarely sit in that list:

• A public GitHub repository a contractor pushed under a personal account, with an internal hostname in its CI config.
• A container image on a public registry that still ships an old framework version and a debug endpoint.
• A staging host that answers on a forgotten cloud IP and has no DNS record at all.
• A SaaS login page on a vendor domain that federates to your identity provider.

Scanners do find things on known assets, and they find a lot of them. Security teams end up with thousands of findings ranked by a severity score that knows nothing about their environment. What teams really need to know is which of these someone could use against them this week. Scanners can't tell you that. Red Loop can.

Why Red Loop runs as a loop

A pipeline runs once and stops: discover, scan, report. A loop treats each pass as input to the next. New assets go to the scanners. Scanner output becomes a ranked queue for the agents. Agent results flow back into the inventory, the coverage map and the next run's plan.

We call the discipline behind this "loop engineering." Most of the work is not the AI. It is the structure around the AI that keeps every pass bounded, scoped and measurable:

• Every run picks up where the last one stopped. Before an agent starts, Red Loop builds its brief from what is already known: in-scope assets, assets nobody has tested yet, findings still open, and what earlier runs tried on each asset.
• Every run writes state back. Agents record what they covered, what they ruled out and what they proved. The next run reads that record and moves on to untested ground instead of repeating the last one.
• Scanners do the bulk work, agents do the thinking. The scanning layer gives the same answer for the same input. Agents spend their budget only where judgment adds something: chaining, context, proof.
• Hard edges. Scope, budget and the evidence bar for a finding are enforced by the platform. A prompt asking the model nicely doesn't count.

The result is a system you can switch on and leave running. Each cycle costs a predictable amount, covers new ground and leaves the backlog a little more honest than it found it.

Deterministic stages do the bulk work. Agents add judgment, and everything they learn goes back into shared state that the next run plans from.

Stage 1: Discovering what you own

Discovery begins with the scope you keep in Strobes Attack Surface Management: organization names, root domains, verified ownership and exclusions. These are the seeds. From them, Red Loop works outward through a series of pivots. The pivots read public records and send no traffic to you. Only the liveness and fingerprint step sends light traffic to the host.

The loop inside discovery matters as much as the outer one. Fingerprinting a live host often reveals new identifiers, such as an analytics ID, a certificate organization or a hostname in a content security policy. Those go back into the root-domain pivots, and the process repeats until a pass turns up nothing new.

How we decide what's yours

A repository that mentions your domain may belong to a fan, a vendor or an attacker. A host on a shared CDN IP belongs to thousands of companies. So every discovered item carries its evidence: which signal linked it to you, where that signal came from and when it was observed. Signals combine into a confidence score, older evidence counts for less, and an item's score can never be higher than its parent's.

Some signals override the score whatever else is true. Shared hosting or CDN addresses, parked pages, privacy-proxy registration as the only link, a registrant that is clearly another organization, and vendor-hosted SaaS all count as hard negatives.

Confidence	What happens
Strong	Added to the inventory as a Strobes asset, tagged as discovered by Red Loop
Partial	Sent to a review list with its evidence, for your team to confirm or dismiss
Weak, or a hard negative	Kept as a candidate only, never tested

Attack and Validate only touch assets that are confirmed or strongly attributed. This keeps agents from testing anything that only looks like yours.

Stage 2: A deterministic baseline

Once an asset is in the inventory, the scanning engines run on it. Each asset type gets the engine that suits it:

Asset	What the scanning layer checks
Hosts and IPs	Liveness, open ports, service and version fingerprints
Web applications	Known vulnerabilities, misconfigurations, exposed panels and files, TLS and header hygiene
Code repositories	Vulnerable dependencies and insecure code patterns
Container images	Vulnerable OS packages and libraries in each layer
Cloud accounts	Configuration against benchmark controls

We keep this layer deterministic on purpose. The same asset scanned twice gives the same result, so a finding can be reproduced, explained and closed. It is also the cheap layer. A known check across ten thousand hosts doesn't need a language model.

The baseline does two jobs for the agents that come after it. Its fingerprints, the products, versions, ports and frameworks seen on each asset, become structured facts that the technique selector matches against. Its findings become leads. A scanner that reports a known CVE on a host has produced a work item: prove it or drop it.

The technique catalog

The agents don't decide from scratch what to try. They work from a catalog of techniques covering all three phases: discovery pivots, attack techniques and validation recipes. Each technique is a short, reviewed document. It is mostly plain-language methodology, wrapped in a small structured shell that the platform can reason about.

The shell answers four questions:

• When does it apply? Conditions on asset facts: asset type, exposed protocols, detected technology, open ports, whether it faces the internet. For validation recipes, conditions on the finding: its source, category or weakness class.
• What counts as proof? The evidence a finding from this technique must carry before it can be filed.
• What looks real but isn't? Known false positives, so they are ruled out before anyone sees them.
• What must never happen? Safety limits specific to the technique, on top of the global ones.

Here is a simplified technique card:

id: attack.client-side.secrets-in-bundles
phase: attack
title: Secrets and hidden routes in JavaScript bundles
applies_when:
  asset_type: [web, api]
  internet_facing: true
severity_floor: medium
instructions: |
  Collect current and historical JS bundles and any source maps.
  Extract routes, API hosts and credential-shaped strings.
  Hand new routes to the unauthenticated-API technique.
proof: |
  A secret counts only after one read-only identity call
  succeeds and shows its scope. Record the call, never the secret.
false_positives: |
  Keys that are public by design, such as browser-scoped map keys
  or publishable payment keys.
safety: |
  A leaked credential is used for the identity call and nothing else.

The attack side of the catalog is organized by what an unauthenticated outside attacker can realistically do:

Category	Examples	Proof required
Known exploited edge CVEs	VPN and firewall appliances, file transfer servers, CI/CD servers	The CVE's own non-destructive check. A version match is never enough.
Exposed files and debug surfaces	Source control folders, environment files, backups, framework debug pages	Sensitive content retrieved, compared against a random-path control
Client-side secrets	Bundles, source maps, default signing keys	A read-only identity call, or a session forged for our own test data
Unauthenticated APIs	API specs, GraphQL, routes recovered from JavaScript, old API versions	Data an anonymous user shouldn't see: a count and one redacted record
Unauthenticated infrastructure	Search clusters, databases, caches, container and orchestration APIs	Read access shown, nothing written
Takeovers	Dangling DNS records, expired domains referenced in DNS or scripts	Proven available without claiming it
Pre-auth flaws	Password-reset poisoning, signup mass assignment, token handling, OAuth redirects	A token or privilege gained for our own test account
Server-side request and parser bugs	URL fetchers, webhooks, document renderers, file uploads	An out-of-band callback from the target, plus an internal read
Injection and client-side execution	SQL, template and command injection, DOM XSS, cache and request-smuggling bugs	A differential result reproduced several times, or execution confirmed in a real browser

The catalog is where the agents start. Each brief also sets aside part of the run for work outside the listed techniques, where the agent follows what the target is actually showing. When that work turns up a repeatable pattern, the agent can propose it as a new technique, and our team reviews it before it joins the catalog.

Building the plan for a run

Every agent run starts with an operation plan, which we call the brief. The platform builds it deterministically at dispatch time from current state, before any model is involved. Given the same inventory, coverage and budget, the plan comes out the same, which makes it testable and easy to audit.

1. Build the queue. The unit of work depends on the phase. Discover works on seeds, Attack on applications and Validate on open findings. Attack deduplicates hosts that serve the same application, so forty identical marketing hosts count as one item.
2. Rank it. Attack puts first the assets that have leads, such as known-exploited or likely-exploited CVEs, exposed admin surfaces or takeover candidates. Then come assets never tested, then newly discovered ones, then high-interest fingerprints such as staging hosts, login portals and edge devices, and finally whatever was covered longest ago. Validate ranks open findings by known exploitation, exploit availability, exploit likelihood, severity, internet exposure and age.
3. Select techniques. For each queue item, the selector compares the item's facts with each technique's conditions. A technique that already ran against that item recently is skipped, so a second run moves to new ground instead of repeating the first.
4. Pack the budget. The remaining techniques are ordered by expected yield and packed by cost into the run's credit budget. A larger budget buys more queue items and deeper techniques per item.
5. Compose the brief. The brief lists each selected technique once, with the queue items it applies to and its proof bar, false-positive notes and safety limits. Only what applies to this run goes in. A shorter, more relevant brief is cheaper, and the agent follows it more closely.

Every coverage row and every finding the agent writes back is tagged with the technique behind it. That is how coverage is measured, per asset and per technique, and how the next plan knows what is left to do.

Attack: from fingerprint to proof

The Attack agent works through its queue in four stages per application. Each stage is cheaper than the one after it and decides what that next stage spends effort on.

• Fingerprint. The agent confirms what is really running and refreshes the asset's facts. A stale fingerprint means the wrong techniques get selected, so this step is never skipped.
• Broad sweep. A quick pass of non-intrusive checks across the application, keeping only medium severity and above.
• Deep checks. The techniques selected in the plan, plus any scanner leads on this asset. Output from one technique becomes input for another. Routes recovered from JavaScript feed the unauthenticated-API technique, and hostnames found in configuration go back to Discover.
• Chaining. Many real breaches start with issues that look minor alone. An open redirect becomes an OAuth token theft, or an exposed panel combined with a vendor default becomes a login. Chaining is where the agent's judgment adds the most.

Safety limits that apply to every technique

• Read-only, unless the agent created the object itself.
• A leaked credential is used for one identity check and nothing more.
• Data exposure is shown as a count plus one redacted record.
• Code execution is shown with arithmetic or an out-of-band marker, never a shell.
• No payloads shaped like denial of service, and no poisoning of shared cache paths.
• Takeovers are proven without being claimed. A dangling record is checked against the provider's own availability check and verification mechanisms. A takeover that can't be proven this way stays a lead.
• When a host matches an implausible share of unrelated checks, it is treated as a likely honeypot and suppressed.

Validate: a verdict for every open finding

Most security backlogs are full of findings nobody has confirmed. The Validate agent takes open findings on in-scope assets, whatever produced them: Strobes scanners, connected third-party tools or earlier agent runs. It re-tests each one with a recipe that matches the finding type.

Finding type	How it is validated
Version-based CVE	Check whether the distribution backported the fix, then run the CVE's non-intrusive check. A banner alone never makes a finding exploitable.
Reflected or stored XSS	Execution confirmed in a real browser in the target's origin
Blind injection	A boolean difference plus repeated timing measurements against a control
Weak scanner match	Re-run with strict matching and a negative control
Missing authentication on an API	Compare the anonymous response with the authenticated one
Broken object-level authorization	Two different test accounts with the same role
Server-side request forgery	An out-of-band callback
Header and TLS hygiene	Closed as not exploitable unless a chain to real impact is shown. Red Loop spends its effort on findings that can do real damage.

Each finding ends in exactly one of three states:

The asymmetry is deliberate. Exploitable needs the harmful outcome reproduced on the asset as deployed today. Not exploitable needs positive disproof. "Couldn't reproduce" is never enough to close a finding. It is inconclusive, with a reason code such as no credential, asset down, blocked or rate limited, so you know exactly what would settle it.

Credentials, chosen narrowly

Some findings can only be checked while logged in. Validate picks the credential whose host or URL matches the finding's asset, prefers the least-privileged match and sends it only to the asset it belongs to. Authorization checks get two distinct accounts with the same role. The agent never sprays every stored credential at an asset. The plan carries references to credentials, never the secrets themselves. When no credential matches, the verdict is inconclusive and the agent asks you for one.

Fix groups

Exploitable findings are grouped by a deterministic key: the patch first, then the CVE, the check template, and finally the weakness class plus a normalized title. The same finding lands in the same group on every run, so groups stay stable and your team can track them to closure.

The evidence gate

The agents don't decide what gets filed. Every finding from Discover, Attack or Validate passes through a gate in the platform before it can become a ticket, and the agent can't talk its way around it.

Three properties make this gate work:

• It looks at the evidence. The reviewer sees the requests, the responses and the technique's own proof standard, and rates the severity that evidence supports. A missing security header submitted as "High" is rejected. A real data exposure submitted as "Critical" that only proves a partial read is filed at the severity it proves.
• It fails closed. If the review can't run, the finding is held and the agent is told to retry. Nothing is filed by default.
• The bar is per technique. A takeover needs proof of availability, a secret needs a successful identity call, and injection needs a reproduced differential. One generic rubric would be too loose for some techniques and too strict for others.

The floor is medium severity, and medium still has to show impact. Banner-only, version-only, header-only and TLS-configuration findings don't pass on their own, however many of them a scanner produces.

Sandboxes, scale and budgets

Agents don't run code on your network or on our application servers. Each agent task gets its own short-lived, isolated sandbox. Its tools, browser sessions and scratch files live there, and the sandbox is torn down when the task ends. Every request an agent sends to a target goes out from that sandbox and stays separate from other tenants.

Because sandboxes are cheap to start, the loop runs many tests at once. A large estate isn't scanned one asset at a time. Red Loop fans work out across many sandboxes in parallel, each owning a slice of the queue, and merges the results into one inventory and one coverage map.

Scale without a ceiling is a liability, so spend is controlled by the platform:

• A workspace budget you set. Red Loop runs against an AI credit budget per workspace and per task. When the budget is reached, work stops. It's a hard stop, so the agents never run past it.
• Prioritized spend. Since the queue is ranked, a small budget goes to the riskiest untested assets first. A bigger budget covers more assets.
• Agent credits go to judgment. Discovery and scanning handle the bulk work, so agents spend credits on reasoning, chaining and proof.

In practice you pick the cadence and the budget. The loop fits as much coverage into that envelope as it can and tells you how far it got.

What lands in your queue

Because of the evidence gate, everything Red Loop puts in front of your team comes with its proof. Speculative issues and recon notes stay in the agents' working notes and never become tickets.

What you see:

• A larger, verified inventory. Domains, plus the repositories, container images, cloud endpoints and unlisted hosts tied to them, each with the evidence that it is yours.
• Findings with proof. Each one carries the request, the response and the reasoning that show the issue is real and reachable.
• Verdicts on your existing backlog. Open findings from every source are marked exploitable or not, so you can deprioritize the noise with a reason behind it.
• Fix groups. Proven issues are grouped by the patch that closes them, so remediation becomes a short list of fixes.
• Coverage you can see. For each asset, which kinds of testing have run, when they ran and what is still untested.

Because all of this lives in Strobes Attack Surface Management, it uses the same assets, owners, SLAs and integrations your team already works with. You don't adopt a separate tool or learn a new triage process.

Turn it on and let it run

Attackers go after whatever is exposed today, whatever your last scan report says. Red Loop combines passive discovery, deterministic scanning and agents bounded by scope, budget and a proof requirement, so your view of the attack surface stays as current as theirs.

Red Loop is available to Strobes Attack Surface Management customers. Book a demo to see it run against your own scope.