Security

Security is foundational to Roundtable's architecture. Every workspace runs in its own isolated pod, all communication is encrypted, and access is controlled through organization-level authentication and role-based authorization.

This page explains how Roundtable protects your data at every layer.

Pod-per-Workspace Isolation

Every workspace runs in a dedicated Kubernetes pod on the cluster. This is not a shared container or a virtual partition — it's a real, isolated compute environment.

Isolation Layer	What's Isolated
Compute	Each pod has its own CPU and memory allocation (250m–1000m CPU, 512Mi–2Gi RAM).
Filesystem	Each pod has its own ephemeral storage. Files in one workspace cannot be accessed from another.
Network	Pods are network-isolated by default. Cross-workspace communication is only possible through Bridges, which use HMAC-signed messages.
Database	Workspace data (conversations, tool state, metadata) is logically isolated per workspace in the backing database.
Process	Code execution and shell commands run inside the workspace pod. A crash or runaway process in one workspace has no effect on others.

info

This is stronger isolation than most SaaS AI platforms, which typically run multiple tenants in the same process or container. Roundtable's pod-per-workspace model is closer to infrastructure-level isolation.

Encryption

In Transit

All network traffic is encrypted with TLS 1.2+:

• Browser → Roundtable API: HTTPS enforced via HSTS.
• Roundtable API → AI providers: HTTPS for all provider API calls.
• Inter-service communication: TLS within the cluster.
• WebSocket connections (for real-time chat): WSS (WebSocket Secure).

At Rest

Sensitive data stored at rest is encrypted using AES-256-GCM:

• API keys — Provider API keys (OpenAI, Anthropic, etc.) and data connection credentials are encrypted before being stored in the database.
• Service account credentials — Vertex AI service account JSON is encrypted at rest.
• Connection secrets — Snowflake passwords, Databricks tokens, and other connection credentials are encrypted.

tip

Roundtable never stores provider API keys in plaintext. Keys are encrypted on write and decrypted only at runtime when making API calls to the provider.

Customer-Managed Encryption Keys (CMEK)

Enterprise customers can provide their own encryption keys for data at rest, ensuring that Foxtrot Communications cannot access your encrypted data without your key.

CMEK is available on the Enterprise plan. Contact us to set it up.

Authentication

Roundtable uses Firebase Authentication with Google Sign-In as the identity provider.

How It Works

1. Users authenticate via Google Sign-In (OAuth 2.0).
2. Firebase issues a JWT (JSON Web Token) upon successful authentication.
3. The JWT is sent as a Bearer token in the Authorization header for all API requests.
4. The Roundtable API validates the token on every request — verifying the signature, expiration, and issuer.

Token Lifecycle

• Tokens are short-lived and automatically refreshed by the Firebase SDK.
• Expired tokens are rejected with a 401 Unauthorized response.
• There are no long-lived API keys for user authentication — all access goes through Firebase tokens.

warning

Never share or expose your Firebase JWT. It grants full access to your Roundtable account for the duration of its validity. If you suspect a token has been compromised, sign out of all sessions.

Authorization

Authentication tells Roundtable who you are. Authorization determines what you can do.

Organization Membership

• Users must be a member of an organization to access its workspaces.
• Organization membership is managed by org owners and admins.
• Users who are not members of an organization receive 403 Forbidden responses when attempting to access its resources.

Role-Based Access Control

Every member has a role that controls their permissions:

Role	Manage Org	Manage Billing	Manage Workspaces	Manage Members	Chat & Tools
Owner	✅	✅	✅	✅	✅
Admin	❌	❌	✅	✅	✅
Member	❌	❌	❌	❌	✅

Authorization checks are enforced at the API layer. Even if a user has a valid token, requests that exceed their role's permissions are rejected.

Security Headers

Roundtable's API and web application set the following security headers on all responses:

Header	Value	Purpose
Strict-Transport-Security	max-age=31536000; includeSubDomains	Enforces HTTPS for all connections. Browsers remember to never use HTTP.
Content-Security-Policy	Restrictive policy	Prevents XSS, code injection, and unauthorized resource loading.
X-Content-Type-Options	nosniff	Prevents browsers from MIME-type sniffing responses.
X-Frame-Options	DENY	Prevents Roundtable from being embedded in iframes (clickjacking protection).
X-XSS-Protection	1; mode=block	Enables browser-level XSS filtering (legacy browsers).
Referrer-Policy	strict-origin-when-cross-origin	Limits referrer information sent to external sites.

HMAC-Signed Inter-Service Communication

Workspace Bridges enable cross-workspace communication — one workspace's AI can send messages or delegate tasks to another workspace. To prevent spoofing and tampering, all bridge messages are signed using HMAC-SHA256.

How It Works

1. The sending workspace generates an HMAC signature over the message payload using a shared secret.
2. The signature is included in the message header.
3. The receiving workspace verifies the signature before processing the message.
4. If the signature is invalid or missing, the message is rejected.

This ensures that:

• Messages cannot be forged by unauthorized services.
• Message content cannot be tampered with in transit.
• Only workspaces with valid bridge configurations can communicate.

Webhook Signature Verification

Roundtable uses Stripe for payment processing. Incoming Stripe webhooks are verified using Stripe's signature verification to ensure they are legitimate:

• Every incoming webhook includes a Stripe-Signature header.
• The Roundtable API verifies this signature against the webhook signing secret before processing the event.
• Unverified webhooks are rejected with a 400 Bad Request response.

This prevents attackers from sending fake billing events to the API.

Data Residency

All Roundtable infrastructure runs on Google Cloud Platform (GCP) in the us-central1 region (Council Bluffs, Iowa, USA).

This includes:

• GKE cluster — All workspace pods run in us-central1.
• Cloud SQL — The primary database is hosted in us-central1.
• Cloud Storage — File uploads and backups are stored in us-central1.

info

If you have data residency requirements outside of us-central1, contact us about Enterprise options for regional deployments.

Compliance

SOC 2

Roundtable is working toward SOC 2 Type II certification. This is currently in progress, and we expect to complete the audit in a future cycle.

:::info Coming soon SOC 2 Type II certification is on our roadmap. If you need a SOC 2 report for procurement or vendor review, contact us and we'll share our current security posture documentation and controls. :::

GDPR

Roundtable processes data in accordance with GDPR requirements for EU users. We offer Data Processing Agreements (DPAs) for Enterprise customers.

Additional Compliance

Enterprise customers can request:

• Custom DPAs — Data Processing Agreements tailored to your requirements.
• Security questionnaire responses — We're happy to complete your vendor security review.
• Penetration test reports — Available under NDA for Enterprise customers.

Contact us for compliance-related inquiries.