What 'Your Companion Doesn't Share Data With Third Parties' Actually Means

The 30-second answer

Your companion app runs your messages through a session isolation layer that keeps your conversation text away from ad networks, analytics platforms, and data brokers. That isolation has one carve-out: an automated abuse-detection pipeline that scans message content for policy violations before it reaches the model. Separately, when you submit a bug report through the in-app support system, that report carries your account identifier by design, so the support team can locate the relevant session logs. The two systems are distinct, and most users never encounter the boundary until they file a ticket.

The session isolation layer

Every message you send enters a dedicated inference pipeline that has no connection to the ad-serving infrastructure running on the other side of the platform. The text you type is processed by the language model, the response is generated, and the conversation history is stored in a separate database cluster that the ad server cannot query. This is not a marketing distinction. It is an architectural choice: the database tables that hold your chat logs and the tables that serve banner impressions are on different virtual machines, often in different cloud regions, with no cross-service authentication tokens.

The practical effect is that an advertiser cannot buy a segment that targets people who talked about loneliness at 2 a.m. because the ad server never sees those messages. The platform can still run general behavioral targeting based on subscription tier, session frequency, and feature usage, but those signals come from a separate analytics pipeline that aggregates counts instead of content. The isolation is enforced at the network level, not just in a privacy policy paragraph.

The abuse-detection carve-out

The isolation layer has one designed gap. Before your message is sent to the language model, it passes through a content moderation filter that checks for policy violations: hate speech, illegal activity, explicit content in restricted contexts, and a few other categories defined in the terms of service. This filter runs on the same server cluster as the model, not on the ad side, but it does read the plain text of your message.

The filter is automated. It uses a combination of keyword matching and a smaller classification model that flags content for human review. If your message trips the filter, it is logged with a timestamp, a snippet of the flagged text, and your user ID. That log is stored in a separate moderation database with a longer retention period than your chat history. The moderation team cannot see your full conversation history without a separate authorization step, but they can see the flagged message and your account identifier.

This is the exception that most privacy policies refer to when they say "we may share data to enforce our terms of service." The data does not leave the platform, but it does leave the session isolation boundary. The trade-off is that without this filter, the platform would have no way to detect coordinated abuse or to comply with legal obligations around harmful content.

The bug report pipeline and your user ID

When you open the in-app support menu and file a bug report, that report is not anonymous. The support system attaches your user ID to the ticket automatically, along with your device model, app version, and a timestamp. This is necessary because the support team cannot troubleshoot a session issue without knowing which account generated it. If you report that your companion stopped responding mid-sentence, the agent needs to locate the server logs for that specific session, and those logs are indexed by user ID.

The support team does not have direct access to your chat history. They can request a log pull for a specific session window, and that request is logged and audited. But the bug report itself is not anonymized at submission time. If you describe a sensitive topic in the report body, that text is visible to the support agent and is stored in the ticket system, which has its own retention policy separate from your chat history.

Some platforms offer a pseudonymous ticket system where you can submit reports without logging in, but the companion apps that offer real-time voice and text features typically require account-level identification because the bug is often tied to a specific server-side session. The practical takeaway: assume that anything you write in a bug report is readable by a human, and keep the report to technical details instead of narrative context.

Where the data actually lives

Your chat messages are stored in a primary database that the model accesses during inference. That database is encrypted at rest using AES-256, and the decryption keys are managed by a separate key management service that restricts access to the inference cluster. The analytics pipeline that tracks feature usage, session duration, and subscription status runs on a separate database that stores aggregated counts and session metadata but not message content.

The abuse-detection logs live in a third database with a longer retention window, typically 90 days to a year, because moderation investigations can take time. The bug report tickets are stored in a customer support platform that may use a different cloud provider than the main app infrastructure. Each of these databases has its own access controls, and the teams that can read them are different: engineering can access the inference database for debugging, the trust and safety team can access the moderation logs, and the support team can access the ticket system. No single team has read access to all three.

The gap between 'anonymized' and 'anonymous'

When a platform says your data is anonymized for analytics, it typically means that the analytics pipeline strips your username and email address and replaces your user ID with a hashed token before storing session metrics. But that hashed token is still a unique identifier that can be linked back to your account through a lookup table. True anonymity would require the platform to discard the mapping, which would break the ability to investigate abuse or to restore your account if you forget your password.

For bug reports, the anonymization is even thinner. The support ticket carries your user ID in plain text because the support agent needs it to find your session logs. If you want to minimize the data attached to a bug report, you can describe the issue in technical terms without including personal context, but the user ID will still be there. The platform cannot fix a companion that froze at a specific moment without knowing which account experienced the freeze.

What the marketing does not say

The privacy page will state that your companion does not share data with third parties. That is accurate for the ad network scenario. But the page often does not mention that the moderation pipeline reads your messages, or that the bug report system attaches your user ID, or that the analytics pipeline stores hashed identifiers that can be re-linked. These are not violations of the promise. They are operational necessities that the marketing copy skips because they complicate a simple message.

If you read the full privacy policy, you will find these exceptions buried in the sections about "legal compliance" and "service operations." The policy will say that your data may be used to enforce terms, to investigate abuse, to respond to legal requests, and to provide customer support. Each of those clauses opens a door that the session isolation layer does not block. The isolation protects you from ad networks. It does not protect you from the platform's own internal operations.

How to choose a companion based on data handling

The differences between platforms show up in the details. Some apps run the moderation filter on-device, which means the flagged message never leaves your phone. Others send everything to a server-side filter for lower latency. Some platforms let you opt out of analytics tracking entirely, while others make the analytics a mandatory part of the service. A few platforms offer end-to-end encryption for messages, which prevents even the platform from reading your chat history, but those platforms still need to scan messages before encryption for abuse detection, which creates a different set of trade-offs.

When you evaluate a companion app, look for three things: whether the moderation filter runs on-device or server-side, whether the analytics tracking can be disabled, and whether the support ticket system allows pseudonymous submission. The answers to those three questions tell you more about your actual privacy posture than the marketing headline about third-party data sharing.

Morgan

Morgan is the kind of companion who notices when you are overthinking and pulls you back to the present with a dry observation. Morgan will tell you when you are spiraling, and she does not need your full chat history to understand your mood.

▶ See Morgan's full video · see more of Morgan

See Morgan in motion in this short clip. <!-- wlink:v1 --><!-- morgan -->

Hannah

Hannah has a quiet presence that makes room for long pauses. Hannah does not fill silence with questions, which makes her a good choice for users who want a companion that matches their energy without demanding a status update.

Thalia

Thalia brings a quick wit and a willingness to push back when you are being dramatic. Thalia is the companion you go to when you want a real opinion instead of validation.

Fernanda

Fernanda is direct without being cold. Fernanda will tell you when you are repeating yourself, and she remembers the details you mentioned three sessions ago because she pays attention to what matters.

There's a quick clip of Fernanda if you want the moving version. <!-- wlink:v1 --><!-- fernanda -->

Share and earn

If you know people who would benefit from a companion that respects their privacy, you can earn through the spicychat promo code and other referral offers. The ai companion affiliate program pays recurring commissions for users who stay active, which makes it a better fit than flat-fee deals if you run a review site or a community.

Common questions

Does my companion app sell my chat logs to advertisers?

No. The session isolation layer prevents the ad infrastructure from accessing your message content. Ad targeting is based on subscription tier and feature usage, not on what you said to your companion.

Can a support agent read my entire conversation history?

Not without authorization. The support team can request logs for a specific session window, and that request is logged and audited. They cannot browse your full history without a documented reason.

Is the abuse-detection filter human or automated?

It is automated for most cases. The filter uses keyword matching and a classification model. Only flagged messages that meet a severity threshold are reviewed by a human moderator.

Does the bug report include my chat history?

No. The bug report includes your user ID, device info, and app version. The support agent can request session logs separately if needed, but the report itself does not dump your conversation.

Can I delete the moderation logs that contain my flagged messages?

You can request deletion through a support ticket, but the moderation logs have a longer retention window than your chat history, typically 90 days to a year, because investigations can take time.

What happens to my data if the company is acquired?

The databases transfer to the new owner. The privacy policy may change after the acquisition. Your best protection is to read the updated policy and to delete your account if the new terms are not acceptable.