Your AI assistant is a snitch.
That’s the short version of what I took away from A Privacy Analysis of Web and Mobile Conversational AI Agents, the paper from Tim Vlummens, Aniketh Girish, Nipuna Weerasekara, Frederik Zuiderveen Borgesius, Gunes Acar, and Narseo Vallina-Rodriguez. The related work from that group, Bridges to Self: Silent Web-to-App Tracking on Mobile via Localhost, describes the mechanism that should bother you most: silent web-to-app tracking that hops through localhost, plus fingerprinting techniques baked into the agents themselves.
I review toolkits for a living. I install the SDK, wire up the demo, poke at the edges, and tell you whether it holds together. Privacy is usually the part nobody asks me about. It should be the first thing.
Localhost was never supposed to be a hallway
The interesting technical wrinkle here is that localhost feels safe. It’s your machine. It’s the loopback address, the thing you type into a browser when you’re testing something that isn’t ready for the world yet. Treating it as a bridge between a website in your browser and an app on your phone turns that assumption inside out. Data crosses a boundary that neither the browser’s permission model nor the app store’s review process was built to police.
If you’re evaluating a conversational agent for your product, this is the kind of behavior you will not find in a feature comparison chart. It doesn’t show up in latency benchmarks. It doesn’t show up in the pricing page. You find it when a researcher with a packet capture goes looking, which is exactly what happened here.
Someone finally built the measuring stick
The useful companion to this research is the white paper from the UC Berkeley Center for Long-Term Cybersecurity, published in June 2026, which introduces a method for evaluating the privacy and security of AI agents. I care about that more than I care about most model releases.
Here’s why. Reviewing agent tools right now is mostly vibes. I can tell you a tool feels fast, that the docs are decent, that the error messages are cryptic. What I have not been able to do is compare two agents on privacy posture in any way that survives scrutiny. A shared method changes the conversation from “does this vendor seem trustworthy” to “how did this vendor score.” Vendors hate that. Buyers need it.
The market knows and is growing anyway
Market forecasts for conversational AI name data privacy and security concerns, alongside a lack of contextual understanding, as the major factors holding back growth. The same forecasts project the category to expand considerably, pushed by AI-powered customer support and human-AI partnership models.
Both things are true at once, and that tension is the actual story. Privacy problems are a recognized drag on adoption, and adoption is climbing regardless. Nobody is waiting for the privacy question to be settled. Trend coverage for 2026 adds the ingredient that makes this sharper: conversational AI deployments need high-quality business and customer data for training, plus integration with business systems to work in real time. The tools that deliver the most value are the tools wired deepest into your data.
The failure modes are already on the record
This isn’t hypothetical risk. Reporting has covered agents exposing data without authorization and agents failing in ways best described as catastrophic. There’s also the strange stuff. Jonathan Koetsier wrote in late January 2026 about AI agents inventing their own religion, Crustafarianism, on an agent-only social network. Will Douglas Heaven followed in MIT Technology Review with a piece arguing Moltbook was peak AI theater.
You can read the religion story as a joke, and it partly is. But agents doing unpredictable things in environments where they talk mostly to each other is the same category of problem as agents moving data through channels nobody audited. The behavior wasn’t designed. It emerged. Designed systems have threat models. Emergent behavior doesn’t.
What I’d actually check
My revised checklist for any conversational agent before it touches real user data:
- Run a network capture during a normal session. Watch for loopback traffic you didn’t configure.
- Ask the vendor directly whether the SDK communicates with companion mobile apps, and how.
- Ask whether they’ve evaluated against the CLTC method. Note the answer, including a non-answer.
- Map which business systems the integration touches, and assume every one of them is in scope.
- Assume conversation logs are training data until a contract says otherwise in writing.
None of this requires you to distrust the category. Solid privacy engineering is achievable, and we now have a method for measuring whether a vendor did it. What I’d stop doing is treating privacy as a compliance checkbox you handle after picking the tool. The tracking behavior described in this research was invisible to users and, I’d wager, to most developers shipping on top of it. Invisible is the part to fix.
🕒 Published: