Back to all stories
Operational Chaos
🔴 Real Incident

Your Voice Agent Is Building a Database Nobody Owns

Sears Home Services deployed AI chat and voice agents. They generated 3.7 million customer records — into three buckets with no password and no encryption

2026-03-20·6 min read·By Supervaize Team
Your Voice Agent Is Building a Database Nobody Owns

Your Voice Agent Is Building a Database Nobody Owns

🔴 REAL INCIDENT: Sears Home Services / Transformco — 3.7M AI agent records exposed in unsecured storage (February 3 – March 17, 2026)


What Happened

On February 3, 2026, security researcher Jeremiah Fowler ran the kind of routine Shodan sweep that turns up someone's misconfigured infrastructure most weeks. This time it turned up three cloud storage buckets with no authentication and no encryption, holding roughly 3.7 million records generated by AI customer service agents — the large majority of them belonging to Sears Home Services.

The contents were not metadata. They were the conversations themselves.

Nearly 1.4 million audio recordings of customer phone calls. More than 54,000 complete chat logs. Over 2.1 million text files containing scheduling conversations. Another 200,000-plus spreadsheet logs tying it together. The records spanned 2024 through 2026 and included customer names, phone numbers, home addresses, the appliances in those homes, and the dates and times when a technician would be arriving at them.

The transcripts and audio referenced two systems by name: "Samantha" and "KAIros." These were the agents — the friendly voice that called to confirm your dryer repair window, the chat widget that rescheduled your appointment. Every interaction they handled had been captured, transcribed, recorded, and written to storage that anyone on the internet could list and download.

Fowler sent a responsible disclosure notice to Transformco, Sears Home Services' parent company. The buckets were made inaccessible the following day. His technical write-up was published on March 17, 2026.

There was no attacker in this story. There was no breach, in the sense of anyone breaking anything. There was an AI deployment that generated an enormous corpus of sensitive personal data as a byproduct of doing its job, and an organization that had no process which recognized that corpus as something requiring protection.


The Technical Breakdown

The misconfiguration is the least interesting part. Unsecured buckets are a solved problem with well-known controls. What is worth studying is why this particular data landed in one.

Conversational agents manufacture regulated data at industrial scale. A human call center generates call recordings too — but it generates them through a procurement process. Someone buys a recording platform, someone signs a DPA, someone configures a retention policy, someone answers a question about where the recordings live because a compliance officer asked. The data arrives inside a governance frame because the system that produces it was purchased as a system that produces regulated data.

An AI voice agent arrives as an efficiency project. The business case is about deflection rates and cost per contact. The transcripts and audio are implementation detail — logs, essentially, in the mental model of the team deploying it. And logs, in most organizations, go wherever logs go: object storage, cheap tier, nobody's explicit responsibility.

So the same material that would have been a tightly-governed asset under the old architecture became operational exhaust under the new one. The data did not change. The frame around it disappeared.

Debug retention became permanent retention. The composition of the exposure — audio and transcripts and structured spreadsheet logs of the same interactions, spanning two years — is the signature of retention set during a pilot and never revisited. When you are tuning an agent, you keep everything, because you need to hear what went wrong. That setting is correct for six weeks of evaluation and catastrophic for twenty-four months of production. Nothing in a typical deployment forces anyone to revisit it, and the storage is cheap enough that cost never raises the alarm.

Agent output sat outside the CRM boundary. The customer records themselves almost certainly lived in a properly secured system. But the agents wrote their conversational output to a separate store, provisioned by whoever stood up the integration. Every access control, audit trail, and retention rule attached to the customer database applied to the structured record of the appointment — and not to the recording of the customer giving their address out loud.

This is the inverse of the Blind Agent Problem: there, the agent couldn't see data it needed. Here, the agent produced data the organization couldn't see.

Voice makes the sensitivity worse, not better. A structured field holds "address." An audio recording holds the address, the customer's voice, whoever else was in the room, and whatever they mentioned while the line was open. Voice agents capture far more than the form fields they populate, which makes their output categorically more sensitive than the record it produces — and the biometric status of voiceprints under several privacy regimes turns that from an embarrassment into a regulatory exposure.


The Broader Pattern

Enterprises are currently measuring AI deployments on one axis — did it reduce handling cost, did it deflect tickets, did it shorten the queue — while those deployments quietly change the organization's data footprint.

Every conversational agent is also a collection system. It records, transcribes, stores, and usually retains indefinitely by default. In a year, a mid-sized service business can accumulate a volume of customer voice data that would have required a deliberate, board-visible program to build intentionally. Nobody at Sears Home Services decided to construct a 1.4-million-recording voice archive. It accumulated because the agents were working.

The 2026 research on enterprise agent failures keeps landing on the same structural point: governance is applied to the agent's decisions and almost never to the agent's outputs and artifacts. Teams review what the agent is allowed to do. Very few review what the agent leaves behind.

This is also why the incident is properly classed as operational rather than purely as a security lapse. Nothing was compromised by an adversary. The failure was in deployment process — no data classification step, no retention policy, no owner assigned to the artifact store, no periodic review that would have caught a bucket that had been public since the pilot. A security control was missing because no operational process ever asked for one.

And the detection path is worth noting: the exposure was found by an outside researcher doing untargeted scanning, not by any internal control. It had been reachable long enough to accumulate two years of records. The response, once notified, was fast and correct — locked down within a day. The gap was entirely in the twenty-four months before anyone looked.


How It Could Have Been Prevented

  • Classify agent output as regulated data before the agent goes live. Transcripts, recordings, and conversation logs inherit the sensitivity of the conversation, not the sensitivity of a log file. Run the same classification exercise you would run for a new CRM field, at deployment time, and route the output into storage that already carries the right controls.
  • Set a retention policy with an expiry date on day one — and make the pilot setting expire automatically. Verbose capture for tuning is legitimate. Make it a time-boxed configuration that reverts, rather than a default that persists until someone remembers it exists.
  • Assign a named owner to every artifact store an agent writes to. Unsecured buckets survive because they belong to nobody. If the deployment checklist requires an owner for each destination the agent writes to, the destination gets reviewed. If it doesn't, the destination gets forgotten.
  • Separate what the agent needs from what the agent captures. The scheduling workflow requires the appointment, the address, and the appliance. It does not require a permanent audio copy of the customer saying those things. Store the minimum the business process needs and discard the rest on a fixed clock.
  • Include agent-generated stores in external attack surface scanning. Fowler found this with Shodan. So could the organization. Any storage endpoint provisioned as part of an AI integration belongs in the same continuous external scan as everything else, and most are not, because they were created outside the normal infrastructure pipeline.
  • Audit voice agents specifically against biometric data rules. Voiceprints carry heightened obligations in several jurisdictions. An agent deployment that captures customer audio at scale is a privacy program question, not just an infrastructure question, and it should reach the privacy team before it reaches production.

The Lesson

Most AI risk conversations are about what the agent will do — will it take an action it shouldn't, will it give bad advice, will it be manipulated into something harmful. Those are real, and we have written about all of them.

This incident is about something less dramatic and considerably more common: what the agent accumulates.

An agent that never once misbehaves, that handles every interaction correctly, that hits every efficiency target in its business case, will still change the shape of your data estate simply by operating. It will produce more records, in more sensitive formats, at higher volume, in places your existing governance was never pointed at. It does this silently, successfully, and continuously.

Sears Home Services did not have an AI failure. The agents worked. Samantha and KAIros booked appointments, confirmed windows, and handled millions of customer interactions. The failure was that the organization deployed a system that manufactures regulated personal data at industrial scale and never updated a single process to account for it.

Two years later, a stranger with a search engine found all of it.

List every destination your AI agents write to — transcripts, recordings, evaluation traces, conversation logs, the debug bucket someone made during the pilot. For each one: who owns it, what is the retention period, when was it last reviewed, and is it reachable from the internet right now? If you cannot answer those four questions for every destination on the list, the list is longer than you think.


Sources

  • ExpressVPN — Jeremiah Fowler, "3.7M AI Chat Logs and Calls Exposed in Sears-Linked Data Leak," March 17, 2026
  • DataBreaches.net — "Sears Exposed AI Chatbot Phone Calls and Text Chats to Anyone on the Web," March 17, 2026
  • SC Media — "Misconfigured AI bot databases leak millions of Sears Home Services customer records," March 2026
  • Security Magazine — "3.7M Records Exposed, Many Belonging to Sears Home Services," March 2026
  • Cybernews — "AI chatbot leaks millions of call recordings and chat logs," March 2026