What actual data access revealed
These findings came from real production data-access telemetry. The organizations are anonymized, but the activity, timelines, and figures are real.
An external AWS account had working delete access to production data
15,853 successful deletions and 309 TB read across eight buckets came from an assumed role in an AWS account outside the primary estate. A CI role named for the dev environment was reading 44 GB of production decision models on the same requests.
The requester ARN on each request carried an account ID outside the primary estate, with DELETE operations returning a 200 response. The dev-to-prod exposure came from the role name string sitting against a production bucket prefix on the same requests.
Both roles were authorized. IAM answers whether access is permitted, not whether it has ever happened before.
An AI-enabled workload swept seven AWS accounts in 23 seconds
A coding-agent client, identifiable from its request signature, operated under an SSO admin role and reached seven AWS accounts it had no prior access history with, all inside a 23-second window — far faster than a human operator moving between consoles.
The client's request signature identified it as an agentic tool, correlated against a role that normally carries SSO/admin privileges. Timestamps across seven separate account log streams placed the entire sweep inside 23 seconds, and none of the accounts touched had prior access history for that identity.
The SSO role was legitimate and every request succeeded. Nothing failed or violated a policy, so nothing alerted — the anomaly was the speed and the breadth, not the permission.
Security tools were silently missing parts of the data estate
Roughly 19,600 denied reads across 342 buckets for one security vendor, and 5,900 failed inventory calls across 1,700 buckets for another — coverage gaps invisible from either vendor's own console.
403 responses grouped by requester identity and affected resources. The vendors' own roles were the requesters, and the denials were consistent rather than occasional.
Security products naturally report what they can inspect, not necessarily everything they failed to reach.
An end-of-life SDK with an active CVE remained in production for 214 days
An end-of-life SDK version with a published CVE was reaching sensitive buckets continuously for 214 days, visible in the user-agent field of every request it made.
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.
Nothing in the request failed. The SDK worked exactly as intended, which is why no operational signal fired.
Four ETL pipelines stopped producing data while every job still reported success
None were instrumented, so every job-level signal reported success while downstream consumers kept reading stale data.
Expected write cadence disappeared while downstream reads continued.
Job completion does not prove expected data output occurred.
Figures are from production access telemetry. Verticals are stated at a level that does not identify the organization.
Not every anomaly is a threat.
Behavioral detection is useful only if it can distinguish meaningful changes from legitimate activity. Trailox provides the evidence needed to investigate both.
The same telemetry that surfaces suspicious behavior also provides the context to clear legitimate activity quickly.
Want this report
for your own logs?
Scoped read-only role, 30-day lookback, results in 48 hours.