← Back to blog
Deep Dive2026-05-30·9 min read·By Nedas Višniauskas

How In-App AI Support Handles Sensitive Data: Privacy by Design

When engineering teams evaluate in-app AI support tools, the question that surfaces late but lands early is: "What data leaves the device?" It's the right question to ask — and the answer determines whether you can actually use the tool in regulated industries, enterprise deployments, or any app where user data compartmentalization matters.

This post walks through how ResolveKit handles sensitive data in the context of in-app AI support — what stays on-device, what gets transmitted, and how operator controls give you governance over the entire flow.

The Privacy Problem with Web-Based Support Widgets

Most support widgets run as web content embedded in your app. When a user opens a chat, they interact with a web session that has its own origin, cookies, and network requests. Every message potentially routes through third-party infrastructure you don't control.

The implications are concrete:

  • User messages may pass through vendor servers for AI inference
  • Session logs can live in vendor dashboards outside your compliance scope
  • Data retention policies are governed by the vendor's terms, not yours
  • If the vendor has a breach, your user data is in their systems

For a consumer app with low regulatory exposure, this might be an acceptable trade-off. For a healthcare app, a fintech product, or anything handling PII under GDPR, CCPA, or HIPAA, it's a blocker.

How Native SDKs Change the Data Ownership Equation

A native SDK runs inside your app process. It has access to the same runtime environment as the rest of your code — no different from your analytics SDK or your crash reporting tool. The data flows are fundamentally different:

On-device context. The AI agent can read session state directly from your app's memory. It doesn't need to ask a remote server what the user's current plan is, what features they have access to, or what their account status looks like. That context is already there.

Inference routing. When the agent needs to call an LLM, it can route through your own API keys and infrastructure. You control where the data goes and how long it's retained. The vendor SDK never sees the conversation content — it only handles the orchestration layer.

No vendor-side session logs. ResolveKit doesn't maintain its own session database. The trace logs and approval records live in your infrastructure, not on ResolveKit's servers. If you're self-hosting, the data never leaves your network.

What ResolveKit Sends Off-Device (and What It Doesn't)

Understanding the data flow requires separating what the SDK does from what your LLM does.

ResolveKit SDK sends:

  • Tool call names and argument structures (for the approval flow)
  • Approval decisions (approve/reject) from the operator
  • Anonymous SDK-level telemetry (opt-in, aggregated, no PII)

ResolveKit SDK does NOT send:

  • User messages or conversation content
  • User identifiers or account information
  • Session context from your app

Your LLM provider receives:

  • Whatever context you pass to the agent — this is your design decision
  • The user's message, rewritten by your prompt instructions

The separation is intentional: ResolveKit handles the tool-calling framework, approval orchestration, and operator controls. The AI inference itself runs on infrastructure you choose and own.

Operator Controls for Sensitive Operations

The approval flow isn't just a safety mechanism for risky actions — it's also a data governance layer. When the agent needs to access or act on sensitive data, operator approval creates a checkpoint where human judgment applies.

Consider a few scenarios:

Account data access. If the agent needs to read a user's subscription status to answer a billing question, that read can require approval. The operator sees exactly what the agent attempted to access and why.

Action scoping. When the agent calls a tool function — say, processing a refund or updating a user's email — the tool arguments pass through the approval layer. The operator sees the specific values, not just the action type.

Audit trail. Every approval decision is logged with a timestamp, operator identity, and full tool call payload. This gives you an immutable record for compliance audits.

Designing Your Privacy Boundary

When you embed ResolveKit, you define the privacy boundary. Here are the decisions that matter most:

1. What context does the agent receive?

The agent only knows what you pass to it. If you pass the user's account ID, plan tier, and session history, that's what the LLM sees. If you pass only anonymous session tokens and feature flags, the agent operates with minimal information.

Design principle: pass the minimum context required for the agent to do its job. You can always pass more — start with less.

2. Which tool functions require approval?

Not all tool functions are equal. A `getFAQArticle` function that just returns static content doesn't need an approval flow. A `processRefund` function absolutely does. Map your tool functions to approval policies based on the sensitivity of the underlying operation.

3. Where does inference run?

ResolveKit supports self-hosted deployment. If you run the backend on your own infrastructure and route inference through your own LLM API, the data plane is entirely under your control. No ResolveKit servers in the path.

If you use the managed tier, inference runs on your chosen LLM provider's infrastructure — not ResolveKit's. The SDK orchestrates the flow; the LLM provider handles the inference.

4. What logs are you keeping?

Trace logs are stored wherever you deploy the ResolveKit backend. If you self-host, you control retention policy, access controls, and deletion timelines. If you need to comply with GDPR's right-to-erasure requirement, you delete the logs from your database — no vendor coordination needed.

A Practical Example: Billing Support in a Fintech App

Let's walk through a concrete scenario.

A user opens your fintech app and asks: "Why was I charged twice this month?"

The agent needs to:

1. Look up the user's transaction history

2. Identify duplicate charges

3. Explain what happened

4. Potentially initiate a refund

Without operator controls, the agent reads transaction data and processes a refund autonomously. With ResolveKit's approval flow:

  • Tool functions that read transaction data require `approval_required` for amounts above a threshold
  • The refund tool function always requires approval
  • The operator sees the full context — user ID, transaction IDs, refund amount — before approving

The operator makes the call. The agent executes only after approval. The trace log records the entire interaction for audit purposes.

This is what "privacy by design" looks like in practice: not a policy document, but a technical mechanism that enforces data governance at the point of action.

Self-Hosting and the Compliance Implications

If your app operates under GDPR, CCPA, HIPAA, or PCI-DSS, data residency and processor status matter. When you self-host ResolveKit:

  • You control the database where trace logs and approval records are stored
  • You choose the LLM provider (and their data processing agreements)
  • You define retention and deletion policies
  • You are the data controller; ResolveKit is software you operate

This is meaningfully different from using a SaaS support tool where the vendor is the data processor by default. The distinction matters for compliance teams doing vendor assessments.

What This Means for Your Evaluation

When you're evaluating in-app AI support tools, the privacy question isn't just "do you encrypt data in transit?" — it's "where does my data flow, who controls it, and can I enforce my own policies?"

Native SDKs with self-hosted backends give you the strongest privacy posture because the data plane is yours to architect. Web widgets route data through vendor infrastructure by design — and that infrastructure is rarely designed for regulated data handling.

ResolveKit is built for teams that need to answer "yes" to the privacy question without rebuilding the wheel. The SDK stays out of the data path. The approval layer gives you control. The backend runs where you decide to run it.

---

Ready to evaluate ResolveKit for an app where data privacy is non-negotiable? See pricing and deployment options or read the SDK documentation to understand the integration architecture.

Ready to build better in-app support?

ResolveKit is an open-source SDK for embedding AI support directly in your mobile app. Self-host or start on managed infrastructure.