Enterprise AI Security: How Skopx Isolates Data Across Teams and Tenants

When you give an AI platform access to your company's email, Slack, databases, and project management tools, you are trusting it with your most sensitive business data. That trust requires an architecture where data isolation is not an afterthought but a foundational design principle.

This article describes how Skopx ensures that your data never leaks across users, teams, or organizations.

The Threat Model

In a multi-tenant AI platform, the attack surface includes:

1. Cross-user data leaks: User A should never see User B's email, even if both are in the same organization.
2. Cross-tenant isolation: Organization A's data must be completely invisible to Organization B, even at the infrastructure level.
3. Prompt injection: A malicious user could craft inputs designed to make the AI reveal data from other contexts.
4. Token exposure: API keys and OAuth tokens stored for integrations must be protected from unauthorized access.
5. Conversation memory leaks: The AI's memory system must not surface memories from one user in another user's conversation.

Architecture: Defense in Depth

Layer 1: Authentication and Authorization

Every API request is authenticated via Supabase Auth with JWT tokens. The middleware extracts the user ID and organization ID before any business logic runs. No anonymous or unauthenticated access is possible to any data endpoint.

Layer 2: Row-Level Security (RLS)

All Supabase tables use PostgreSQL Row-Level Security policies. The conversations table, for example, has this policy:

Conversations are filtered by user_id at the database level. Even if application code has a bug that forgets to filter by user, the database will not return unauthorized rows.

Layer 3: Source Ownership Tracking

When users connect data sources (databases, integrations), the system tracks ownership:

• Each connected source is tagged with the user ID who connected it.
• The query engine validates source ownership before executing any query.
• A user cannot query a database they did not connect, even if they know the connection ID.

This was identified and fixed during a security audit in February 2026. The original implementation used a global singleton that stored all users' connections in a shared Map without ownership checks.

Layer 4: Token Encryption

All OAuth tokens and API keys are encrypted with AES-256-CBC before storage. The encryption uses a random salt per token (not a static salt), making rainbow table attacks infeasible. The encryption key is stored in environment variables, not in the codebase.

Legacy tokens that were encrypted with the old static-salt format are automatically detected and re-encrypted on access.

Layer 5: Memory Isolation

The conversation memory system stores and retrieves memories per user ID. The memory search function includes user_id as a mandatory filter. Cross-user memory access is prevented at both the application and database levels.

What We Do Not Do

Transparency about limitations is as important as listing protections:

• We do not store your raw data. Skopx queries your databases and tools in real-time. We do not maintain a copy of your data.
• We do not train models on your data. Your conversations and business data are never used to train or fine-tune AI models.
• We do not share data with third parties. Your API keys are forwarded to the respective services (Anthropic, Composio) only for the purpose of executing your requests.

Compliance

Skopx is SOC2 Type II certified, GDPR compliant, and CCPA compliant. We conduct annual penetration testing and maintain a responsible disclosure program for security researchers.

Reporting Vulnerabilities

If you discover a security vulnerability, please report it to security@skopx.com. We respond to all reports within 48 hours.