Security & reliability

Experiential Labs serves an OpenAI-compatible /v1 gateway in front of your chosen model providers. This page describes how we isolate your data, keep the service available, and keep it fast. We state only what is true of the running system today; capabilities still in design are called out as such.

Data isolation

Every organization's data is scoped to that organization and enforced at the database layer on every API request, not just in the UI. Access requires membership in the organization. Model access is deny-by-default: an API key can reach a model only through a grant you have explicitly created. We do not serve one customer's optimized configuration, or a substantially identical derivative, to another customer.

Credential handling

Provider keys you connect (bring-your-own-key) and telemetry-provider credentials are stored server-side behind privileged database routines and are never returned to a browser. Provider-internal identifiers (sandbox, deployment, and vendor handles) are treated as server-internal and excluded from public API responses. Platform secrets live in the deployment environment and are never reconstructed onto developer machines.

Request-time controls

Authentication failures return a uniform 401 with no information about why a key was rejected. The serving hot path is content-free: the gateway streams responses and records usage metadata, never prompt or response bodies, with three enumerated exceptions that each carry their own retention window — organization-level opt-in prompt capture (30 days), Responses API continuations needed to honor previous_response_id (24 hours), and batch input/output files (until shortly after the job’s 24-hour expiry). A bounded in-memory idempotency window may replay an identical response for a repeated Idempotency-Key on the same worker; it is never persisted and is gone on pod restart. Admission runs through a single reservation checkpoint that fails closed: per-scope monthly and recurring budgets, tokens-per-minute limits, and a guard against dispatching a request whose price is unknown. We continuously exercise cross-tenant isolation, secret non-leakage, prompt non-retention, injection resistance, and behavior under load and provider faults as part of our test suite.

Availability

Each service runs multiple replicas behind a network load balancer and an ingress tier, so the loss of a single pod or node is absorbed without customer impact. Deploys are health-gated and roll one service at a time, so a rollout never drops an app to zero healthy instances; the streaming data-plane worker specifically must pass a readiness check that includes a live database ping before it takes traffic, and it reclaims and settles work interrupted by a pod restart. Production changes are applied only through a manual, human-watched release that verifies a signed-in surface, not merely a health endpoint.

Being candid about scope: the platform today runs in a single cloud region with a single primary database, so it is resilient to component-level failure but not yet to the loss of an entire region. Region-level and multi-cloud redundancy, database point-in-time recovery and standby failover, and horizontal autoscaling are designed and sequenced, not yet provisioned. We will describe them here as facts once they run in production, never before.

How the platform stays fast

Low latency is engineered, and we measure before we optimize. On the serving hot path we reduced database round-trips from roughly seven to two by serving authorization and the model catalog from tightly-invalidated in-memory caches, backed by a reservation-time database check so a revoked grant still takes effect immediately, and by moving usage accounting off the response's critical path so only the spend reservation is synchronous. Connections between the edge and the worker are kept warm to avoid a handshake per request.

The largest remaining factor is physical distance: when the serving cluster and the database sit in different regions, every database round-trip pays roughly 100 ms of wire time. Co-locating them in the same region collapses that to a few milliseconds per round-trip, a 30–50× reduction on database-bound work, with no change to application behavior. This is the single biggest step toward one-millisecond-class overhead, and it is why we invest in keeping compute and data in the same place.

Reporting a vulnerability

If you believe you have found a security issue, please contact security@experientiallabs.ai. We welcome coordinated disclosure and will work with you on a fix and timeline.