AI App Third-Party Data Sharing Through SDKs and Analytics

Most people using an AI chatbot assume the conversation is a closed loop: type a message, get a reply, done. That assumption is wrong, and the gap between what users think happens and what actually happens is the subject of this piece: a typical AI app runs on a dozen or more third-party code libraries, and several of them start sending data off the device before the user has made a single choice about consent.

This piece walks through the building blocks (SDKs), the moment consent gets bypassed, what real chatbots have been caught sending, and the rules now trying to catch up to all of it.

How a typical AI app's SDK stack is built

An SDK, short for software development kit, is pre-built code a developer drops into an app to get some feature working without writing it from scratch. Need crash reports? There's an SDK for that. Need to track how many users tap a button? Same thing. Need social-media or search-engine login? Same thing again.

A typical AI app's SDK stack covers analytics, ad attribution, crash monitoring, social login, customer support chat widgets, and push notifications. Most mobile apps carry somewhere between 10 and 30 of these third-party SDKs running at once, and each one processes personal data on its own terms, answering to its own vendor rather than to the app's developer. People get it wrong when they picture an app as one piece of software built by one company: an SDK behaves less like a component and more like a guest who moved into the house and started making its own phone calls on its own line. The developer controls what the app itself does. What the guest does on its own connection, to its own servers, is a separate matter, and often the developer doesn't fully know either. The developer controls what the app itself does, but what the guest does on its own connection, to its own servers, is a separate matter that often the developer doesn't fully know either, and this is the default condition of how these apps get built. It's the default condition of how these apps get built.

The consent gap: how SDK data leaves the device before the user touches anything

The timing breaks down when SDKs generally initialize the moment an app starts up, before any consent banner has rendered and before the user has clicked anything. SDKs generally initialize the moment an app starts up, before any consent banner has rendered and before the user has clicked anything. That creates something close to a race condition: the SDK calls its own startup method, pulls device identifiers, and sends them to its vendor's servers, and only afterward does the consent pop-up show up on screen.

SecurePrivacy's 2026 analysis of this problem included a concrete illustration out of one jurisdiction, where regulators captured network traffic and found an analytics SDK transmitting device identifiers a full 340 milliseconds before the user ever saw the consent screen. That's more than enough time, even though it isn't long by human standards, for a packet to leave the device and land on a server somewhere else. Regulators have started calling this pattern "privacy theater": the banner shows up, the user taps accept or reject, and the app logs that interaction as proof of compliance, even though the transmission already happened before the user had any say in it. The consent record exists. The consent itself never did.

What AI chatbots send to third parties during normal sessions

A 2026 study covering 20 AI chatbots found that 17 share data with at least one third party, and the large majority embed third-party trackers spanning ad networks, analytics platforms, social media plugins, and error-monitoring tools. That's the baseline. The specifics get worse from there.

Three of the chatbots studied, Genspark, SeaArt, and ChatOn, were found transmitting the full plaintext of user conversations to Microsoft Clarity, a session-replay analytics service, during ordinary authenticated sessions. Not metadata. Not a summary. The actual text the user typed. Fifteen of the twenty chatbots exposed conversation URLs or identifiers to third-party ad and analytics endpoints, tying a specific conversation to an ad-tracking profile somewhere outside the app. Claude and Mistral both ran support-chat widgets that fired the moment the page loaded, sending the user's email address and name to Intercom before the user had clicked anything.

Session-replay tools deserve a closer look, because "replay" undersells what they actually do. Session-replay tools are designed to capture user interactions across a page, and when masking isn't configured correctly, sensitive input fields can be recorded alongside every mouse movement, click, and scroll. When that masking fails, the resulting data is stored in a form that is readable to those with access to the recorded sessions. That's the mechanism, not a worst-case scenario dreamed up for effect.

Separate research from Surfshark, covering the ten most popular AI chatbots, found that 30% share user data with third parties for targeted advertising, measurement, or data-broker purposes. On average, these chatbots collected 11 out of the 35 data categories Apple tracks in its App Store privacy labels. Incogni's 2025 ranking put numbers on individual platforms: Google's Gemini collected 22 separate data types, including precise location, while ChatGPT collected 10, spanning contact info, user content, device identifiers, usage data, and diagnostics. Gemini collecting more than double what ChatGPT does reflects a different design philosophy about what the product needs to know. It's a different design philosophy about what the product needs to know.

The downstream data chain: why knowing the SDK vendor is not enough

Knowing which SDK an app uses only answers half the question. Once an ad network or data broker receives information through that SDK, it doesn't stop there. It gets resold and redistributed to ad exchanges, demand-side platforms, and other brokers further down a chain the original app developer never built and, in most cases, can't fully see or audit.

Call this fourth-party data exposure. It sits one or two steps removed from the SDK vendor the developer actually chose, and from the user's vantage point it's close to invisible. The FTC's enforcement actions against Gravy Analytics and Venntel show where that chain can end up: location data pulled from third-party suppliers and ad exchanges, without verifiable user consent, sold in ways that exposed deeply personal circumstances about the people it tracked. The FTC took enforcement action against both companies over these practices.

X-Mode, now operating as Outlogic, is the cleanest illustration of how this works mechanically. The company embedded its SDK into popular apps to harvest precise location data from users who had no idea their movements were being logged. The app itself wasn't a data broker. Its SDK was quietly feeding one, one layer removed from anything the app's own privacy policy described.

DeepSeek as a case study in what happens when multiple failure modes stack

DeepSeek is worth studying because it shows several of these problems layered on top of each other, rather than any single failure occurring in isolation. Its own privacy policy indicates that user inputs, including personal and commercially sensitive information, may be retained and used to train its models. What security researchers found sits in uncomfortable tension with the policy's stated limitations, making the technical findings more damning, not less.

NowSecure's analysis found DeepSeek sending sensitive user data with no encryption at all in places, relying on outdated 3DES encryption with hardcoded keys elsewhere, and deliberately turning off iOS's App Transport Security, a setting Apple built specifically to stop this kind of unencrypted transmission. SecurityScorecard's STRIKE team separately found undisclosed connections to ByteDance, TikTok's parent company, and other analysis found data being routed to servers outside the app's disclosed infrastructure. Then, in January 2025, a publicly accessible DeepSeek database was found exposing over a million sensitive records, including chat logs and API keys, to anyone who came across it.

Any one of these findings alone would be a serious problem for an app of this scale. Stacked together, they describe a system where the written policy, the technical implementation, and the operational security all failed at roughly the same time, with no single point where a user could have caught the problem before it reached them.

When SDKs become attack vectors, not just data-sharing channels

Up to this point, the problem has been about where data goes. It can also be about who gets into the app. OWASP's 2024 Mobile Top 10, its first update since 2016, lists Inadequate Supply Chain Security among the most critical risks facing mobile apps, pointing directly at third-party SDKs as a primary way malicious code, backdoors, and unauthorized backend access get into apps users otherwise trust. SDK-based attacks rose 40% in 2025. Without visibility into what an SDK does at runtime, a compromised one can sit inside a trusted app indefinitely, and nobody notices until something else goes wrong first.

A case from 2026 makes the mechanism concrete. Microsoft's security researchers published an advisory on an intent-redirection flaw in EngageSDK, a push-notification library built into Android apps with a combined install base above 50 million, more than 30 million of those installs coming from third-party cryptocurrency wallets. The flaw let a malicious app sitting on the same device slip past Android's sandbox protections, forge intents the SDK would mistake for trusted internal messages, and pull out private app data, authentication tokens, and wallet credentials. A push-notification tool became the door. Nobody builds threat models around push notifications, and that is why this one worked.

Something similar happens more quietly through feature updates. When an AI feature gets bolted onto an existing app after launch, it can introduce new data flows and new third-party processing without triggering a fresh security review. An app that passed a clean audit last year has no guarantee of still operating within the same rules today, since the audit tested a version of the app that, in some structural sense, no longer exists.

The Flo Health case and what it shows about third-party data sharing in practice for sensitive apps

Flo Health runs a period and reproductive health tracking app that had, as of November 2024, more than 380 million downloads and over 70 million monthly active users. It was sued for sharing users' sensitive health data with Google and Meta without their consent, and for describing its own data practices in ways that misled the people relying on it.

Flo settled with Google. Together they paid a combined $56 million. Meta chose not to settle, went to trial instead, and a jury found the company liable in 2025.

This case matters for AI apps specifically for reasons that have less to do with period tracking and more to do with the category of information at stake. AI companion apps and mental health chatbots sit in the same sensitivity range: users hand over personal, health-adjacent, emotionally loaded information on the assumption that it stays between them and the app. Flo is what happens when that assumption turns out to be wrong, and what it costs once regulators and a jury get involved. Nobody using a period tracker in its early years thought they were generating evidence for a 2025 verdict. That's the lesson AI chatbot users should sit with.

The disclosure gap between AI platforms' statements and their apps' actual data transmissions

None of this would be as troubling if disclosures kept pace with what the apps actually do. They don't, as NowSecure's 2025 audit of more than 23,300 iOS app packages found that 35% failed to disclose the data they were collecting, 42% were missing their primary privacy manifest, and 97%, nearly all of them, were missing the required privacy manifests for their third-party SDKs specifically. NowSecure's 2025 audit of more than 23,300 iOS app packages found that 35% failed to disclose the data they were collecting, 42% were missing their primary privacy manifest, and 97%, nearly all of them, were missing the required privacy manifests for their third-party SDKs specifically. On Android, roughly 10% of apps in the Google Play Store don't post a data safety section.

The 2026 chatbot study mentioned earlier compared actual network traffic directly against what each company's privacy policy claimed, and found real gaps between the two. Some of the disclosure language is at least honest about its own vagueness: Microsoft states it may collect information from data brokers, Claude's policy lists datasets obtained through commercial agreements with third parties as a source of personal information, and multiple platforms across the industry share data with broadly defined "affiliates" without ever naming who those affiliates are. A policy that admits it can't fully account for its own data sources is an admission that the chain described in the fourth-party section above has gotten too long for the company at the top of it to track. It's an admission that the chain described in the fourth-party section above has gotten too long for the company at the top of it to track.

Platform rules and regulations beginning to close the gap

Some of this is starting to get harder to hide. Apple's Guideline 5.1.2(i), which took effect November 13, 2025, requires developers to clearly disclose whenever personal data will be shared with third parties, including third-party AI, and to get explicit permission before that sharing happens. It's the first time Apple has named third-party AI as its own category requiring specific disclosure and consent, rather than folding it into general privacy-policy boilerplate. Any app sending user data out to an external AI service now has to clear that bar, on top of whatever else its privacy policy already says.

Google has its own version of this taking shape through the Firebase AI Logic SDK: when AI monitoring is turned on in the Firebase console for the Agent Platform Gemini API, prompts and generated output tied to that session get logged in ways developers, and potentially reviewers, can inspect.

Neither rule closes the gap on its own. What they do is put a name and a deadline on a problem that, until recently, lived almost entirely in network traffic nobody outside a security lab was watching. Whether that's enough depends on how strictly platforms enforce their own new rules, and on how many SDK vendors quietly keep doing what they were already doing, just with better-worded policies wrapped around it. Given the incentives on that side of the chain, betting on strict enforcement over quiet continuation feels like the wrong side of the wager.