Security-first by design.

SchneeAI is built for teams that need to operate AI features the same way they operate the rest of their product: with explicit controls, structured records, and reviewable decisions. This page describes the controls and practices we ship today.

Access control

Every request to SchneeAI carries a service, tenant, and user identity. The platform uses that identity to enforce access decisions — who can call which model, view which logs, edit which prompts, and change which policies. Administrative operations require elevated roles; routine reads are scoped to the caller’s tenant.

Tenant isolation

Usage, prompts, logs, and controls are separated by tenant, service, and environment. A request from one tenant does not surface in another tenant’s views, and cross-tenant access is refused by default rather than granted and then filtered.

Audit logging

Requests, prompt changes, policy updates, and operational actions produce structured audit records. Each record carries the actor, the target, the action, and a timestamp — so reviewers can reconstruct what happened, when, and by whom.

Configurable data controls

• Data retention — configure how long usage and metadata are kept.
• PII handling — support safer handling of sensitive user data through configurable policies.
• Vault — raw prompt and output content is stored separately from operational metadata, with its own retention and access controls.
• Human approval flows — add review steps for high-risk AI workflows.

Encryption

Data is encrypted in transit using TLS. At rest, SchneeAI applies application-layer controls on top of the underlying storage encryption for sensitive artifacts such as raw prompts and outputs.

Incident process

When something goes wrong — a misrouted request, a budget overshoot, a prompt rollback — the audit trail and structured usage make it possible to find the source quickly. Incident responders can scope by service, tenant, user, and time range, and export the relevant records.

Responsible AI

SchneeAI is built to support responsible AI practices: observable behavior, configurable safety events, human review where it matters, and retention controls that let teams limit what they keep. We treat responsible AI as an operating discipline, not a marketing claim.

Architecture

Every chat completion flows through the same path. Your backend authenticates with a Bearer JWT; the Gateway verifies, routes, scans, calls the provider, encrypts the raw exchange into the Vault, records structured usage and audit, and returns the response.

                [Your Service Backend]
                          |
                          | HTTPS + Bearer JWT (Hydra RS256, JWKS)
                          v
   +---------------------------------------------------------------+
   |                     SchneeAI Platform                         |
   |                                                               |
   |   +---------------+     +----------------+                    |
   |   |  AI Gateway   |---->| Auth / JWKS    |  (Ory Hydra)       |
   |   |  (Go + Gin)   |     +----------------+                    |
   |   +---------------+       |                                   |
   |          |                v                                   |
   |          |       +----------------+                           |
   |          |------>| Routing Policy |  (model / budget / PII)   |
   |          |       +----------------+                           |
   |          |                |                                   |
   |          |                v                                   |
   |          |       +----------------+      +---------------+    |
   |          |------>| LiteLLM Proxy  |----->| Provider APIs |    |
   |          |       +----------------+      | (OpenAI,      |    |
   |          |                |              |  Anthropic,   |    |
   |          |                |              |  Google, ...) |    |
   |          |                |              +---------------+    |
   |          v                v                                   |
   |   +---------------+   +----------------+   +---------------+  |
   |   |  Postgres     |   | Vault (encrypt)|   | Audit Log     |  |
   |   | (metadata,    |   | (AES-256       |   | (append-only, |  |
   |   |  usage,       |   |  at rest;      |   |  Postgres)    |  |
   |   |  budget)      |   |  app-layer     |   |               |  |
   |   |               |   |  envelope on   |   |               |  |
   |   |               |   |  roadmap)      |   |               |  |
   |   +---------------+   +----------------+   +---------------+  |
   |          |                                                     |
   |          v                                                     |
   |   +---------------+   +----------------+                       |
   |   | Redis (cache) |   | OTel Collector |  (traces + metrics)  |
   |   +---------------+   +----------------+                       |
   +---------------------------------------------------------------+

The Vault is the only place raw prompt and output content lives, and it is encrypted at rest (AES-256). Operational metadata in Postgres references the Vault by ID but does not contain the raw exchange.

Encryption details

Data residency

• Primary region: single region during the design-partner stage. Multi-region replication is on the roadmap, triggered by customer requirement.
• Provider egress: when SchneeAI calls an upstream LLM provider, the prompt transits to the provider’s region. This is unavoidable — the model runs where the provider runs it. Vault stores the raw exchange inside SchneeAI’s region regardless.
• Backup: encrypted snapshots, same region as primary, 30-day retention.
• No cross-border replication until a customer-driven requirement forces the conversation.

Compliance roadmap

SchneeAI is at design-partner stage. The roadmap below reflects what is shipped today and what is planned. We will not claim a certification we have not earned.

If your procurement team needs an earlier commitment on any of these, email [email protected] — the roadmap is shaped by what customers actually need.

Shared responsibility

SchneeAI manages the platform; you manage your integration. The split, made explicit:

Sub-processors

The current list of sub-processors is published at Sub-processors. We notify design partners 30 days before adding any new sub-processor, and we never add one that changes the data residency story above without explicit notice.

Reporting

Found a security issue? Email [email protected] with details. We respond during business hours and triage reports seriously.