Trust & security

What we do with your data, and what we don’t.

apsera.ai is operated by a small team out of California. We connect AI coworkers to systems (Salesforce, GitHub, Jira, Confluence, Slack, your data warehouse) that contain customer data, so this page exists to be specific about where that data lives, who can see it, and how to get it out.

Where your data lives

Connected systems (Salesforce, GitHub, etc.) hold their own data on their own infrastructure. We store an OAuth refresh token per integration (encrypted at rest in Supabase) so we can call those APIs on your behalf — we don’t mirror their data into our database.

What gets sent to the LLM

Each task your AI coworker runs goes through a single LLM call (Anthropic Claude). What we send:

• The task title and description you typed.
• The system prompt for that worker (their role, tools, your Salesforce profile if applicable).
• Top-N relevant chunks from your knowledge base (~5 chunks per task, only when needed).
• Tool call results from this conversation (e.g. the SOQL query result they just ran).
• Conversation history within the same task (so they can answer follow-ups).

What is never sent to the LLM:

• Your OAuth tokens or any other credential.
• Knowledge-base chunks unrelated to the task.
• Tasks belonging to other workers in your org (each worker has their own conversation).
• Anything from another customer’s org.

Anthropic’s zero-data-retention API is configurable; if you’re on a plan that requires it, email [email protected]and we’ll switch your org over.

What gets logged

Every action a worker takes is recorded in the activity_log table for audit:

• Tool name and input arguments (e.g. sf_update_record with the field map).
• Tool result: a one-line summary plus the structured response.
• Timestamp, worker, task, org.
• For Salesforce updates: the prior values of the fields being changed (so you can undo).

You can browse this on the activity logpage; apsera staff can see it via our admin console only when you’ve opened a support ticket.

Render and Supabase keep their own infrastructure logs (HTTP requests, DB queries) per their standard policies. We don’t pipe customer data into a third-party log aggregator (Datadog, Sentry, etc.) — anything we’d want to debug lives in activity_log.

Subprocessors

We use the following third-party services to run the platform. Each one processes some customer data on our behalf; the table below is the canonical list.

We’ll give 30 days’ notice via email before adding any new subprocessor that processes customer data.

Multi-tenant isolation

Every customer is a separate org. All customer-data tables in our database have row-level security policies enforcing org_id = current_org_id(); even our application code cannot read another org’s rows through the standard client. Service-role queries (admin console, OAuth callbacks) bypass RLS but are scoped via org_id in code and reviewed on every change.

Deletion + data export

Self-serve disconnect: from the Apps page you can disconnect any integration at any time — we revoke the OAuth grant and delete the stored token immediately.

Account closure: email [email protected]from your account email. Within 7 business days we’ll soft-delete the org (it disappears from your view immediately) and within 30 days we’ll hard-delete every row, embedding, and uploaded file. Backups age out within 14 days after that.

Data export:we’ll provide a JSON dump of your org’s rows on request. Knowledge-base files are returned in their original format.

Reporting a security issue

Email [email protected]with details. We’ll acknowledge within one business day. If you can demonstrate a real exploit we’re glad to hear from you — we don’t have a formal bug-bounty program yet but we treat researchers well.

Last updated: 2026-05-05.