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 using the A2A protocol, authenticated by governance contracts and encrypted end-to-end.
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	Governance & Audit	Chat & Tools	View Only
Owner	✅	✅	✅	✅	✅	✅	✅
Admin	❌	❌	✅	✅	❌	✅	✅
Security	❌	❌	❌	❌	✅	✅	✅
Member	❌	❌	❌	❌	❌	✅	✅
Viewer	❌	❌	❌	❌	❌	❌	✅

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.

Contract-Based Authentication (A2A)

Workspace Bridges enable cross-workspace communication using the A2A protocol (Agent-to-Agent, JSON-RPC 2.0 over HTTP). Communication is secured through a four-layer cryptographic enforcement model:

1. HKDF Key Derivation

Each organization has one master secret stored in GCP Secret Manager. Per-contract keys are derived mathematically using HKDF-SHA256:

contractKey = HKDF-SHA256(orgMasterSecret, "contract:{contractId}:{version}")

No per-contract secrets are stored. Key derivation is instantaneous and scales to unlimited contracts. Revoking a contract invalidates its derived key. Bumping the contract version generates a new key.

2. HMAC Request Signing

Every A2A request is signed with the derived contract key:

1. The control plane looks up the active contract for the source→target direction and verifies the requested action is in allowedActions.
2. It generates a contractToken: HMAC-SHA256(secret, contractId:sortedAllowedActions) — a cryptographic fingerprint of the contract's terms.
3. It signs the full request: HMAC-SHA256(secret, taskId:timestamp:contractId:action) — binding the specific action and contract ID into the signature.
4. The signature, contract ID, contract token, and timestamp are forwarded to the target pod.
5. The target pod re-derives the contract token from its own local RT_CONTRACTS manifest using timingSafeEqual comparison.
6. Requests with invalid signatures, expired timestamps (>5 minute window), unknown contract IDs, mismatched contract tokens, or unpermitted actions are rejected at the pod before any processing occurs.

3. Pod-Side Enforcement Gate

The target workspace pod enforces contracts independently — it does not trust the control plane's action-check alone. The five-stage gate runs on every bridge receive:

Stage	Check	Error Code
1	HMAC + timestamp ≤ 5 min	401
2	X-Contract-Action header matches the HMAC-signed action (defaults to message_send for backward compatibility)	401
3	contractId in local manifest	CONTRACT_NOT_FOUND
4	contractToken = HMAC(contractId:sortedAllowedActions) (timingSafeEqual)	CONTRACT_TOKEN_INVALID
5	action ∈ manifest allowedActions	ACTION_NOT_PERMITTED

This makes enforcement self-reinforcing: even a compromised or misconfigured control plane cannot grant permissions that weren't written into the RT_CONTRACTS manifest on the pod. Tampering with allowedActions in transit is detected at stage 4 before stage 5 is reached.

Strict Transport Action Whitelist

Only five protocol-level actions are auto-allowed for active contracts — they do not need to appear in allowedActions:

message · delegate · message_send · tasks_get · tasks_cancel

All intent operations (discover, query:query_bigquery, tool:read_file, capability:risk.calculateVar, aggregate, etc.) must be explicitly listed in the contract's allowedActions. There is no wildcard bypass — an unlisted intent operation is rejected at stage 5.

Wake-on-Request RBAC

When a bridge request targets a sleeping workspace (scaled to zero), the sender's pod must scale the target pod before delivery. This requires the workspace pod's Kubernetes service account to have get and patch permissions on apps/v1/deployments in the target pod's namespace. Without these permissions, the wake proxy cannot scale the peer and the request fails.

4. End-to-End Encryption (AES-256-GCM)

Message payloads are encrypted before leaving the sender using the same HKDF-derived contract key:

• Algorithm: AES-256-GCM with a random 12-byte IV per message (NIST recommended)
• Scope: Only the two workspaces holding an active governance contract can decrypt message content
• What can't read the payload: The wake proxy, ingress controller, Kubernetes cluster operators, log aggregators, and monitoring tools — they all see encrypted ciphertext

:::tip Defense in Depth TLS protects against external network attackers. AES-256-GCM end-to-end encryption protects against internal infrastructure access — even a compromised cluster component cannot read cross-workspace message content. :::

This model provides four cryptographic guarantees from a single key derivation:

Property	Mechanism	What It Proves
Authentication	HMAC-SHA256 on request + timingSafeEqual token check	The sender holds a valid, active contract and no fields were tampered with in transit
Action integrity	contractToken = HMAC of contractId:sortedAllowedActions	The exact action set hasn't been modified — attempted privilege escalation fails at the pod
Confidentiality	AES-256-GCM on payload	Only the two contracted parties can read the content
Message integrity	GCM authentication tag	The payload has not been tampered with

Governance Engine

The governance engine continuously monitors workspace topology and contract health:

• Idle bridges — Detects bridges without active contracts. These are treated as neutral — a bridge without a contract is completely inert and permits zero data flow
• Topology cycles — Identifies circular communication paths that could circumvent access controls
• Unreachable workspaces — Flags completely isolated workspaces for review
• Single points of failure — Warns when removing one workspace would disconnect the network
• Expiring contracts — Alerts before contracts expire so they can be renewed or revoked
• Governed workflow visualization — Overlay predefined operational workflows on the topology to show which contracts govern each hop, per-workflow health scores, and governance gaps
• AI Alignment Reviews — Framework-specific compliance analysis (HIPAA, SOC 2, FINRA, custom) with enriched context including bridge governance status, contract escalation targets, and bridge-to-contract mapping
• Intent Compilation Engine — Compiled operations carry HMAC-SHA256 signatures, nonce-based replay prevention, and produce cryptographic execution proofs for audit-grade traceability

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.