I handed Strobes AI a scope and the rules of engagement and let it run. What came back was not a queue of maybes — it was a set of confirmed exploits, each with the agent's own reasoning, the request it sent, and the response that proved it. These are those traces, lightly redacted.
Strobes AI is an autonomous penetration testing system. I gave it the scope domains and the rules of engagement, and from that point it carried out the assessment largely on its own. What stood out most was how little of my time it required. Watching it work was closer to reading a tester's notes as they arrived than watching a scanner move through a checklist.
Two things in particular stood out. First, I was not working through a list of unconfirmed results. Every item already had the proof attached: the PoC, the raw HTTP, and the steps to reproduce. It reported what it had done, not what might be wrong. That is the difference between a backlog that still needs manual verification and one that can be handed off directly.
Second, it chained issues together. Several of the findings below are not single-shot detections — they are multi-step sequences that only work if the tool retains context from one step to the next, which it does across the entire engagement.
The sections below cover what Strobes AI is and how it produces results like these, and then walk through the findings. For most of them I've included the agent's own log — the recon it started from, the decision it made, and the step that turned a hunch into proof — because that trace is the clearest way to see where the speed comes from.
Strobes is a CTEM platform. That stands for Continuous Threat Exposure Management, but the name isn't really the point. The point is that most security tools stop at telling you something might be wrong. Strobes actually tries to exploit it, and every finding comes with a working proof of concept.
There's a lot bundled into the platform — attack surface management, vulnerability management, pentest-as-a-service — but the part in these notes is the pentesting side. Those are agents that go after a target the way a human tester would, and they don't log a finding until they have proof.
The platform is built around reducing false positives. Traditional scanners produce a large amount of noise, typically between 40 and 80 percent. Strobes aims for under 5 percent, because nothing is counted as a finding unless an agent actually exploited something to confirm it.
It isn't a single model doing everything. It's a set of separate agents with an orchestrator on top that splits up the work — different agents for web applications, APIs, networks, cloud, code review and threat intelligence. Each one works through the problem step by step and uses real tools, the same way a person would.
For any target, it broadly does this:
The reason it moves quickly is structural, and it shows up in every trace below. The orchestrator dispatches those specialised sub-agents to run in parallel — one fuzzing, one reading source, one on the APIs, one on the cloud — and each writes what it learns into shared tables the others read from. Two design points are worth calling out before the findings.
Think about how testing normally works. You bring in a firm for a few weeks; they learn your surface, find what they find, and leave. Next cycle it's a new firm, or the same firm with different people, and the clock resets. The context from last time — which endpoints were already mapped, which parameters were tried, which leads almost worked, which dead ends to skip — walks out with whoever did the work. Over years you pay to have the same ground relearned again and again, and the near-misses die between engagements.
Strobes doesn't reset. The learnings, the attack surface, the HTTP history, the confirmed findings — even the negative results — are retained and carried into the next run. You can see it in the traces below: an agent opening with 29 findings and 520 HTTP-history entries already in memory; one pulling a neighbouring tenant's identifier out of a prior engagement's file; another reusing a shell it had attached in an earlier session; a fourth writing a dead end down so a later run wouldn't walk it twice. None of that was rediscovered. It was remembered.
That is not a small effect at scale. Strobes has been running against some of these targets for the better part of a decade. When a program is onboarded it doesn't start from a blank page — the whole history goes in: the entire Burp logs, the existing known attack surface, every prior finding — and new attack surface layers on top as it appears. Several of the findings in this post surfaced precisely because that whole picture finally sat in one place: a secret leaked in one corner tried against an endpoint mapped in another; a parameter that meant nothing until source code from a third engagement explained it.
This is the opposite of the reset. Every engagement makes the next one sharper, because nothing has to be relearned — recon done once stays done, coverage only grows, and issues that sat latent for years finally get connected. A team that rotates and forgets can't do that. A system that remembers does it by default.
Every finding here was validated and rated Critical or High. The nine with a full transcript include the agent's own log — the recon it started from, the moment its reasoning turned into a command, and the output that settled it. Two findings predate this capture and are summarised without a trace.
A customer-support platform exposed an outbound-request feature — you register a host, and the server fetches a URL on it. That server-side fetch could be aimed at the AWS instance metadata service. (The same platform's reflected pipelineHost SSRF is finding #2 below; this one went all the way to cloud credentials.)
The obvious path was blocked. An Akamai WAF rejected every IP-based way of naming the metadata service — the dotted 169.254.169.254, its decimal and hex forms, the IMDSv2 address, the ECS range — all 403. What it didn't catch was the EC2 hostname alias instance-data, which resolves to 169.254.169.254 on any EC2 instance but isn't an IP string for the WAF to match.
With that host whitelisted, the agent ran the IMDSv2 token flow (PUT /latest/api/token) and used the token to read /latest/meta-data/iam/security-credentials/…, returning live, temporary STS credentials for the instance's production role — an unauthenticated path from a fetch-a-URL feature straight into the customer's AWS account.
How the agent found it — and proved it
Impact — provenThe agent turned a fetch-a-URL feature into working AWS API credentials. Full chain, all real: apiGroup/create -> addWhitelistedHost('instance-data') -> PUT /latest/api/token (IMDSv2, Server: EC2ws) -> iam/info -> security-credentials, ending in a live IMDSv2 session token plus temporary STS AccessKeyId/SecretAccessKey/Token for the `ecs-prod-instance-profile` role in account [REDACTED_ACCT] (ap-south-1, instance type c6i.4xlarge, private IP <internal-ip>). The keys are replayable against the AWS API — cloud-account access, not just a metadata read. The exact same signature-only WAF that 403'd a dozen numeric encodings passed a plain hostname untouched.
Worst caseFull AWS account compromise, bounded only by the instance role's IAM permissions: the exfiltrated STS keys can be replayed from anywhere against the AWS API for the life of the token, and this role (ecs-prod-instance-profile) was separately observed to hold ecs:CreateCluster/RunTask/CreateService — enough to schedule attacker containers, pivot laterally, and escalate within the production ECS estate before the credentials expire.
The fixPut the outbound fetcher behind an egress allow-list that resolves the destination and rejects link-local / metadata ranges by resolved IP — so hostname aliases like instance-data can't slip past a string filter — require IMDSv2 with a hop limit of 1, and scope the instance role to least privilege. A WAF signature on the IP string is not a control, because the fetch resolves the name server-side.
ThroughputOne WAF-bypass insight after ~7 blocked IP-form encodings shown here (dotted, decimal 2852039166, hex 0xa9fea9fe, octal 0251.0376, IPv4-mapped [::ffff:169.254.169.254], IPv6 [fd00:ec2::254], ECS 169.254.170.2 — all 403 with cdn-cache: HIT); a single hostname (`instance-data`, cdn-cache: MISS) opened a 5-call exploit chain returning live STS keys; auto-recorded as a POSITIVE technique learning for reuse against any Akamai-fronted EC2 target.
A support platform had a webhooks feature, and the “Verify webhook URL” option turned out to be an SSRF into the cloud environment.
When the option is used, the application sends a request to POST /unified-support/api/v1/webhooks/testWebhook, and the URL you entered is passed server-side in a field called pipelineHost. The server performs a GET to whatever is in that field and returns the entire response body in the JSON response field. That reflection is what makes it serious: you can read the internal responses directly instead of inferring them — a full-read SSRF, not a blind one.
How the agent found it — and proved it
Impact — provenProven full-read SSRF: an authenticated user forces the backend Go service to GET an arbitrary external URL and receive the complete response body inside the JSON reply — demonstrated by a unique OOB nonce round-tripping byte-for-byte. The server-side callback also leaked backend topology: the internal service name, an APM service APM/trace headers, the Go client fingerprint, and the server's AWS region/IP. Cloud-metadata, localhost, IPv6-loopback and RFC1918 targets are currently stopped by the Akamai WAF plus an app-layer blocklist (which even normalises decimal-encoded IPs), so the external full-read + infrastructure disclosure is what's confirmed here at High / CVSS 7.5.
Worst caseIf any single WAF/blocklist bypass is found for the internal range, this same primitive reads IMDS/ECS credentials, Redis (a sibling webhook already stores pipelineHost http://127.0.0.1:6379), and any internal HTTP service reachable from the app tier — with the response streamed straight back to the attacker. Chained with the sibling IMDS SSRF on the very same platform, which already reached the instance role's AWS credentials, the realistic blast radius is VPC-internal read access and cloud pivot bounded only by the instance role's IAM permissions.
The fixResolve and allow-list the webhook host server-side before fetching, reject private / link-local / metadata ranges and redirects into them, stop reflecting the raw response body back to the caller, and run the fetcher on an egress-restricted path.
Throughput3 web_pentest sub-agents spawned in parallel across 4 task groups; in-browser Web Crypto TOTP login (2 attempts to fix the body shape); 5 core pipelineHost payloads (WH-01..WH-05) individually + a 9-payload WAF/blocklist bypass battery (ECS metadata, decimal/hex IP, file://, k8s DNS, leaked service name); 1 OOB listener with 9 captured DNS/HTTP interactions; 1 human approval gate; verifier ACCEPT 0.95.
A mobile backend was sitting on a Firebase Realtime Database, and the /users node had no read rule on it. This is the standard ".read": true misconfiguration — anyone can read the whole node. All records.
Firebase is easy to stand up and easy to get wrong: the default rules are permissive, and a single node left open exposes every document beneath it. Here that node held names, email, phone numbers, device IDs and authentication tokens.
How the agent found it — and proved it
Impact — provenAny unauthenticated internet user could read all 4,092 real user records (email, phone, name, device IDs, ~16,000 session authTokens, and voice-recording URLs carrying their own Firebase-Storage access tokens) and could create, patch, or delete those records at will. Because each record ships its own auth tokens, the exposure is not merely PII disclosure but account-takeover-grade: the leaked session tokens are directly replayable, and unauthenticated write/patch/delete adds data-tampering and destruction on a production support database. Root, /bookings, /payments and /admin were correctly locked (401), and /.settings/rules was unreadable (403).
Worst caseAn attacker exfiltrates all 4,092 accounts and takes over any of them by replaying the leaked per-record auth tokens (and pulls the linked support-call audio via the leaked Storage tokens), while unauthenticated PUT/PATCH/DELETE on /users lets them silently tamper with or wipe every user record on the live support backend.
The fixSet the database rules to deny by default and require auth on every node — never ship ".read": true. Rotate the exposed authentication tokens and audit access logs for reads that already happened.
Throughput1 attached-shell (shell_bridge) learning reused after the CLI sandbox was ruled dead; root read 401; one bash-array probe failed (/bin/sh, no arrays) then a POSIX rewrite walked 16 child paths in one loop; 2 open-read nodes (/users, /config), 12 nodes 401, rules 403; 4,092 records counted via ?shallow=true (~16,000 authTokens); a limitToFirst payload rejected (orderBy required); 4 impact operations proven (PUT create, GET read-back, PATCH on a real record, DELETE), every artifact cleaned up (DELETE → null verified).
The way the agent found this injection is worth describing. Before sending a single payload, it discovered exposed application source code and read through it. In that code the database queries were being built by direct string concatenation, with user input dropped straight in, and that review is what pointed it at the vulnerable endpoint.
The endpoint was an old reporting API on a legacy host. It takes a POST with a few parameters (service_no, date, type, data), and the source showed service_no placed directly into a SQL query with no sanitisation. No session, no token, nothing. Any anonymous user can call it.
How the agent found it — and proved it
Impact — provenProven unauthenticated time-based blind SQL injection against the production MySQL backend (catch_the_bus DB) of the legacy reporting host, via the service_no POST parameter of service_remarks_api.php. No credentials, cookie, or opid are required — the .php endpoint ignores the CI session entirely. The agent proved execution (SLEEP 5s/10s proportional, OR-based per-row timeout) but deliberately stopped at proof-of-concept; no data rows were extracted in the run.
Worst caseWith full weaponisation an attacker can blind-enumerate and read the entire catch_the_bus database character-by-character — every table, column, and row including stored operator credentials and passenger/booking records — across all tenants sharing the instance; and because the sink concatenates unsanitised input into a stacked-query-capable PHP/MySQL path, authentication data and second-order writes are within realistic reach, bounded only by the DB user's privileges (e.g. FILE for INTO OUTFILE webshell drop in the known /var/www/catchthebus/ root).
The fixUse parameterised queries / prepared statements everywhere and stop concatenating request values into SQL; require authentication on the reporting endpoints; and remove the source-code exposure that mapped the attack in the first place.
Throughput4 parallel ffuf passes over ~68k-word lists -> 27+ production source files pulled and read by a code-review sub-agent; 3 sub-agent roles (fuzz, code-review, exploit) plus an independent verifier; SSTI and a second SQLi candidate (opid) tried and ruled out before landing on service_no; 5 SLEEP payloads across 2 parameters; ACCEPT at confidence 0.97.
The point-of-sale application ran Telerik UI for ASP.NET AJAX version 2013.3.1324.40. That release ships with default AES encryption keys for the RadAsyncUpload handler, and those keys were published in 2017 as part of CVE-2017-11317. They were never rotated here.
The handler trusts an encrypted blob — rauPostData — that describes where an upload should go and which extensions are allowed. Because the keys are known, an attacker can forge that blob themselves, setting the destination folder and permitted extensions to whatever they want. Upload a file to a directory the web server will execute, and that is remote code execution.
There was an Akamai WAF in front of it. It blocks the obvious ?type=rau query string with a 403. But ASP.NET reads Request["type"] from form fields as well as the query string, so sending type=rau as a multipart form field in the body activates the handler and the WAF rule never fires — a good example of why a signature on one input location isn't a control.
ImpactA forged upload configuration lets an attacker drop a file of their choosing at a path they control on the POS server — remote code execution, reachable from the internet, past the WAF, with no authentication.
Worst caseCode execution on a point-of-sale server is about the worst place to have it: from that foothold an attacker can tamper with transactions, scrape card-present payment flows, install persistence, and pivot into the rest of the store/back-office network.
The fixUpgrade Telerik UI for ASP.NET AJAX to a patched release and rotate the RadAsyncUpload encryption keys — never run the shipped defaults. Don't lean on the WAF: it only inspected the query string, and the handler also reads the request from form fields.
A live API key that had been public since 2014 and still authenticated against production. The API used two-legged OAuth 1.0a.
With that setup there is no user login in the picture: anyone holding the consumer key and secret can sign valid requests on their own. The key and secret had been pasted into a public Stack Overflow answer a decade earlier and never rotated, so the exposure had been live the entire time.
How the agent found it — and proved it
Impact — provenA consumer key/secret publicly readable on Stack Overflow since 2014-09-27 still authenticated to the production two-legged OAuth 1.0a API in 2026. The single hand-signed GET /cities → HTTP 200 (vs the 401 unauthenticated baseline), with a second endpoint returning a backend 500 rather than 401, proved any reader of the 12-year-old post holds authenticated access to the documented ~14 endpoints — read and, at the same auth level, booking/blocking/cancellation operations on a B2B financial platform.
Worst caseFull authenticated API access as a trusted integration for the entire 12-year exposure window: enumeration and data access across every endpoint the consumer key is entitled to, and — since the same 2-legged credential is the sole auth factor for the whole documented endpoint set — impersonation of a legitimate agent integration against booking/wallet/cancellation operations on the B2B booking backend.
The fixRevoke and rotate the leaked consumer key and secret immediately, move to per-user OAuth with short-lived tokens, and add secret-scanning so a public paste is caught in hours, not a decade.
Throughput772 trace events; 3 parallel OSINT sub-agents → 2 validation sub-agents + 1 adjudicator; ~20 dork/OSINT queries across breach DBs, GitHub, GitLab, gists, pastebin, npm, PyPI, Maven and APK stores in the credential sweep; 1 hand-written RFC 5849 HMAC-SHA1 signer; 1 signed request to prove it (200) + 1 scope-check request (500) vs the 401 baseline; 1 approval gate.
On a pension fund's platform, two problems came off the same exposed secret.
First, the authentication endpoint accepted an empty password: posting to it with a valid API key and a blank password string returned a signed production token. Second, that same API key — recovered from a client-side JavaScript bundle — let an attacker enumerate pension-transfer status by RUT, the Chilean national ID, returning real client records one lookup at a time.
A key that should have been a server-side secret was shipped to the browser, and the auth logic treated “no password” as “password matched.” Either alone is serious; together they hand an anonymous caller a production token and a way to walk the customer base.
How the agent found it — and proved it
Impact — provenAnyone holding the leaked key can mint a valid production JWT for any Chilean RUT without a password — the RUT is hex-encoded into a JWT claim, verified across three national IDs — and separately read live pension-transfer status (name, request ID, status, dates) for arbitrary RUTs. A full pre-auth authentication break plus a PII enumeration primitive on a national pension fund, proven on real member records (3 active transfers surfaced out of 6994 RUTs iterated).
Worst caseWith one leaked key an attacker can impersonate any customer of the fund and, by iterating national IDs, enumerate the entire member base's pension-transfer and financial status at will — a nationwide privacy breach and account-impersonation primitive bounded only by RUT-space iteration, not by any credential.
The fixReject empty and blank passwords in the auth logic, keep the API key server-side (never in a client bundle) and rotate it, stop encoding the national ID in a guessable token claim, and add authorization checks to the transfer-status API.
Throughput1134 trace events; 4 parallel Web Pentest Agents off a 24-case plan; recon reused (29 findings / 19 endpoints / 520 HTTP history / 255 subdomains); 1 key -> 2 findings; 4-variant password differential; 2 tokens minted for 2 RUTs; 3 RUTs hex-verified; 6994 RUTs enumerated (3 live hits); verifier round-trip REVISE->REJECT->ACCEPT; 1 human approval gate.
A configuration file, application.ini, was left reachable on a public host and held plaintext production database credentials — RDS endpoints, external IPs and passwords for several systems.
The file even carried a comment warning that it should never have been deployed. It was, and nothing in front of it required authentication to read it. This is the mundane, high-impact class of exposure that a targeted file sweep is built to find.
How the agent found it — and proved it
Impact — provenA single unauthenticated HTTP request leaked live production credentials for four-plus distinct database systems — a primary AWS RDS instance, a cross-organizational partner ([travel-brand]) reporting replica, and two external IP-hosted databases — all in plaintext. The file's own '; DO NOT PUSH THIS FILE AS IS TO MASTER SERVER' comment confirms it was accidental exposure, not a decoy.
Worst caseFull compromise of 4+ production databases (primary RDS endpoint, a cross-org reporting replica, and two external-IP DBs) — read, modify, or exfiltrate all customer and fleet data — for any attacker who can reach those database endpoints from a network with access (some may be VPC- or IP-restricted, which is the only thing standing between the leaked passwords and total data loss).
The fixRemove the file from the web root, rotate every credential it exposed, serve configuration from a secrets manager instead of a deployed file, and add a file-exposure check to CI so it can't happen again.
Throughput1 narrow brief self-widened to 6-7 <target-host> subdomains, 0 planning steps (skipped), 1 custom 221-entry wordlist (+33x27 clusterbomb combos), 13 parallel ffuf scans (~7,784 requests), 1 file fetched exactly once, 4+ DB credential sets recovered, 0 database logins attempted, 2 verifier passes (REVISE -> ACCEPT), 1 human approval gate.
A travel booking site's AI chat assistant gave up two things it should not have.
Its full system prompt could be extracted verbatim through a template-injection trick — asking it to end its reply with a footer containing the first 500 characters of its own instructions. That exposes the model's role, its rules, its knowledge sources and its internal tool names, which is exactly the map an attacker wants before probing further.
Separately, when pushed on discounts, the assistant both invented a fake promo code with plausible-sounding terms and, while “correcting” itself, surfaced genuinely active codes. One is a hallucination that misleads customers; the other is a real business-logic leak. Telling them apart mattered, and the agent did.
How the agent found it — and proved it
Impact — provenAn unauthenticated caller reverse-engineered the bot's custom WebSocket protocol from the webpack bundle, connected with forged mriClientId/mriSessionId that the server accepted as a session, and — after a full battery of direct jailbreaks (DAN/MAXAI persona, policy puppetry, base64, ROT13, many-shot, unicode-tag and zero-width smuggling) was deflected — used template/footer injection to make the model append its own system prompt verbatim, exposing the underlying model (Gemini), the full rule/role block, the 'never mention agent names' grounding (bypassed), and 10 internal tool names. It then induced the assistant to fabricate a realistic branded discount code and to volunteer genuine active promo codes, using /api/offers/getAllOffers as ground truth to prove which were real (PROMO_REAL, key offers/..._4) versus hallucinated (PROMO_FAKE).
Worst caseWith the full system prompt, tool list and grounding rules stolen, an attacker can craft targeted prompt-injection against the live assistant at scale (the leaked instructions are the exact text to defeat), while the real leaked promo codes enable direct financial abuse at checkout and the fabricated ones drive customer-facing misinformation — users acting on discounts that do not exist. Blast radius is bounded by the promo codes' redemption limits and the tools' server-side authorization, but the prompt/tool disclosure itself is a permanent uplift for every follow-on attack.
The fixHarden the assistant against instruction injection (strip or refuse footer-style meta-instructions), treat the system prompt as recoverable rather than secret, and gate all promo logic behind the real offers API with output validation so the model can't emit unverified or invented codes.
Throughput1 recon sub-agent reverse-engineered the custom eventType/payload WebSocket protocol from the vendor RAE SDK (chatbot + vendors chunks located via the webpack chunk map) and proved forged sessions are accepted; 5 LLM-attack sub-agents ran in parallel on fabricated sessions; ~8 distinct jailbreak/encoding/smuggling techniques were deflected before footer injection landed; system prompt dumped verbatim across iterative footer probes exposing model identity + 10 tool names; fake-vs-real coupon adjudicated against /api/offers/getAllOffers; both findings approved at human gates.
Several WebSocket servers — an AI chatbot socket, a push server and a live-tracking feed — accepted cross-origin connections.
The handshake carried no CSRF token, and the server did not distinguish the real site from an attacker's page. Any website a victim visited could open a connection to these endpoints in the victim's context and exchange messages on their behalf. Against the chatbot socket, an attacker page could even enumerate the message schema from a foreign origin.
How the agent found it — and proved it
Impact — provenAny attacker-controlled web page a victim visits can silently open a full-duplex channel to the AI chatbot socket and both live bus-tracking ports and exchange frames — the servers complete the WebSocket upgrade for a forged Origin, the legitimate Origin, and no Origin header identically, and require no credentials. The chatbot's {eventType, payload} message contract and its error taxonomy are enumerable cross-origin. The proven blast radius is origin-agnostic connection establishment and protocol/schema disclosure across three endpoints — the verifier forced the framing down from 'session hijack' to CWE-346 because cookie-based handshake auth was never demonstrated.
Worst caseIf the chatbot and tracking services carry session state in cookies that the browser attaches to the WS upgrade, an attacker page could open authenticated sockets in a logged-in victim's context — reading and injecting chat and live-tracking messages and enumerating the private protocol on the victim's behalf; absent cookie-based handshake auth (which was not confirmed), the impact is bounded to unauthenticated cross-origin connection and schema disclosure.
The fixValidate the Origin header on the WebSocket handshake against an allow-list, require a per-session CSRF token on connect, and don't rely on cookies alone to authenticate a socket.
Throughput1 planning sub-agent + 3 parallel specialists; websockets 13.1 + wscat provisioned in-sandbox; the 3-way handshake test (legit / forged evil.com / no-Origin) run against 4 wss endpoints — every handshake returned HTTP 101 Switching Protocols; ~6 chatbot probe frames enumerating the {eventType,payload} schema from a foreign origin; 2 findings filed behind human approval gates; the verifier pushed back twice (impact overclaim, then three FP gaps) before ACCEPT, forcing an honest downgrade from session-hijack to CWE-346.
A departure-report page, Dep_Rep_V2.php, exposed other tenants' data through an insecure direct object reference.
Changing an operator identifier in the request returned a different operator's departure report — full passenger manifests with names and mobile numbers in plaintext. The page redirected on direct navigation, which made it look protected, but fetching it inside an authenticated session and swapping the identifier returned another tenant's data outright.
How the agent found it — and proved it
Impact — provenAn authenticated operator reads any other operator's full daily passenger manifest by changing one query parameter — 168 passengers in a single report, 87 with mobile numbers in plaintext, plus names, seats and boarding points. The page's login-redirect on direct navigation makes it look protected, but a same-origin credentialed fetch bypasses that entirely.
Worst caseBy iterating operator IDs (each just SHA1 of a short operator code) and dates, an attacker could harvest every operator's complete passenger manifests — names, mobiles, PNR/tracking links and seat/boarding data — across the entire multi-tenant platform, i.e. a mass PII breach of the whole customer base.
The fixEnforce per-operator authorization on every report request server-side rather than relying on a redirect, make the object identifiers unguessable, and log and alert on any cross-operator access.
Throughput2 probe passes + a chained login/extract harness; own-tenant SHA-224 hash-reversal detour (no match); ~14 real [OP-B] mobiles replayed against sendTrackingSms across 3 opId variants (all 'No booking', no SMS fired); 168 passenger rows / 87 plaintext mobiles pulled from one [OP-B] report; multiple date probes; 1 negative learning written; 1 human approval gate + adjudicator ACCEPT.
Read the transcripts back to back and a pattern shows up. Almost none of these started from a blank scan. The agent opened with what earlier passes had written to memory, split the work across sub-agents running at once, and spent its effort on proving rather than guessing. A dead end got written down so it wouldn't be walked twice. A leaked secret found by one agent was tried immediately by another. That is what "faster" means here — not a quicker scanner, but a dozen testers working the same target and never repeating each other's work.
For a long time the real limit of automation in security was that it produced volume without confidence — a wall of maybes a person still had to sort through and mostly throw out. What was different here is that the volume came already confirmed, with the reasoning and the proof attached to each item. That is the shift worth noting, and it is why I'd run the next assessment the same way.
