What the logs showed
Each of these came out of S3 access-log metadata alone, in environments where every existing dashboard reported normal. Verticals only. No named customers, no identifying detail.
A second AWS account with working delete rights on production fraud verdicts
15,853 successful deletions and 309TB read across eight buckets by an assumed role from an account outside the primary estate. A CI role named for the dev environment was reading 44GB of production decision models.
How it surfaced. The requester ARN on each request carried an account ID that was not in the primary estate, and the operation field recorded DELETE with a 200 response. The dev-to-prod finding came from the role name string sitting against a production bucket prefix on the same requests.
Why it was invisible. Both roles were authorized. IAM answers whether access is permitted, not whether it has ever happened before.
Payment keys as plaintext objects, one role reading all of them
82 key objects identifiable from their names alone, every one of them reachable by a single internal role.
How it surfaced. Object key strings only. No object was opened and no content was classified. Aggregating successful GETs by requester ARN showed one role touching the full set.
Why it was invisible. Scanning tools sample object contents. A filename is not content, and a low-frequency object set is what a sample walks past.
An AI agent sweeping seven accounts in 23 seconds
A coding agent with an MCP server, running under an admin SSO role, with read-only and consent flags both disabled. The guardrail state was recorded in the user agent on every request.
How it surfaced. The user-agent field carried the MCP client identifier and its configuration flags. Correlating timestamps across seven account log streams put the whole sweep inside a 23-second window.
Why it was invisible. The SSO role was legitimate and the requests succeeded. Nothing failed, so nothing alerted.
Paid security tooling denied across the estate
Roughly 19,600 denied reads across 342 buckets for one vendor, and 5,900 failed inventory calls across 1,700 buckets for another. Coverage gaps invisible from either console.
How it surfaced. 403 response codes aggregated by requester ARN. The vendors’ own roles were the requesters, and the denials were consistent rather than occasional.
Why it was invisible. A security tool reports on what it can read. Neither console showed the buckets it could not reach.
EOL SDK with an active CVE, 214 days undetected
An end-of-life SDK version with a published CVE was reaching sensitive buckets continuously. Visible in the user-agent field of every request it made.
How it surfaced. The user-agent string on every request carries the SDK name and version. Mapping that version against published advisories is a lookup, not an inference.
Why it was invisible. Nothing in the request failed. The SDK worked exactly as intended, which is why no operational signal fired.
Four dead ETL pipelines, 7 to 23 days silent
None were instrumented, so every job-level signal reported success while downstream consumers served stale data.
How it surfaced. Absence rather than presence. Write cadence per prefix showed PUT operations stopping while reads against the same prefix continued.
Why it was invisible. The orchestrator reported success because the jobs completed. Completion and output are different events.
Cold partitions scanned on every query, and storage class drift
A set of partitions with no recent writes were still included in regular table scans, adding measurable scan overhead. Storage class distribution had drifted away from actual access patterns across the same estate.
How it surfaced. GET and LIST operations per partition prefix, set against the last write timestamp for the same prefix. Storage class came from S3 Inventory.
Why it was invisible. The query engine reports what it scanned, not what it needed to.
Figures are from production access logs. Verticals are stated at a level that does not identify the organization.
What we checked and cleared
The method that finds also clears. This is what makes the critical findings credible.
Want this report
for your own logs?
Scoped read-only role, 30-day lookback, results in 48 hours.