Metadata by default
By default we ingest event metadata only: provider, model, feature, token counts, cost, latency, status, and the tags you attach (tenantId, userId, feature, run, agent). That is enough for attribution, margin, and real savings. Raw prompt and output text is never stored unless you explicitly turn capture on, and provider responses only if an owner turns on the shared response cache.
Prompts stay opt-in
Prompt and output capture is off by default and used only for the optional Cost-Validated Savings replay feature. When a workspace owner or admin turns it on, sampled content (the prompt and output, plus the system prompt and earlier turns when the integration sends them) is encrypted with AES-256-GCM before it is stored, carries a 14-day TTL, and a daily job deletes it on expiry. An owner or admin can keep a completed experiment's encrypted cases as a swap test set for up to 90 days to re-check model swaps, and delete it at any time. Once a model swap is live, a weekly check replays 30 recent samples on the original model and keeps only the result, never the content. A shorter prompt trial, started by an owner or admin, replays 30 captured requests on the same model with less conversation history, or with a shorter system prompt that the judge model proposes, and also keeps only the result. A proposed system prompt is encrypted, kept only as long as the trial's evidence, and never applied automatically. On the Pro and Team plans, a weekly topic analysis groups each workload's samples on Google Vertex AI; prompt embeddings are never stored, and topic names are encrypted and cleared when the samples they came from expire. Opt back out and captured samples, test sets, and topic names are deleted immediately, not at the end of the window. Event metadata retention follows your plan (7, 14, 30, or 90 days); an event with a captured sample is kept until the sample expires.
Shared response cache
Off by default. When a workspace owner turns it on, SDK instances can share answers for the exact-cache rules the team marks as shared. The request is never sent to TrAIce: the SDK sends a keyed hash of it, made with a per-workspace secret. TrAIce stores the provider's response encrypted with AES-256-GCM, never serves it after the rule's cache time (24 hours at most), and deletes it within an hour of expiring. Turning the cache off, locking metadata-only mode, or changing the rule deletes the stored responses at once. No published SDK release uses the shared cache yet, so today it stores nothing.
Metadata-only mode
A workspace owner can lock the workspace to metadata only. TrAIce then drops prompts, responses, system prompts, and conversation history as they arrive, removes metadata keys that usually hold text, cuts any metadata value over 256 characters, and refuses prompt sampling and experiments. Turning it on deletes stored samples, experiment evidence, swap test sets, and shared cache responses, and turns the shared cache off. Turning it off needs an owner who signed in recently, and every change is recorded in the workspace.
Never in your request path
The hosted TrAIce service is not a gateway. Usage events are sent after your LLM call returns, so a TrAIce issue cannot slow your calls or take them offline. Rules you turn on run locally inside the TypeScript SDK: exact and semantic caching, spend caps that block calls over budget, evidence-gated model swaps with a gradual rollout, routing, fallback, and retry caps. Once an SDK release supports it, a shared response cache that a workspace owner turns on asks TrAIce for a stored answer before calling your provider, waiting at most 150 ms. Every rule fails open to your provider on any error. Local SDK overhead per tracked call stayed under 1 ms at p99 across our Node.js and Python benchmark matrix. That figure is evidence, not a latency SLO, and excludes provider latency, network delivery, and opt-in checks. See the runtime performance benchmark.
Keys and encryption
Your TrAIce API keys are stored as SHA-256 hashes; the raw key is never persisted, and only a short prefix is shown for identification. Provider keys you connect for replay are encrypted at rest with AES-256-GCM, and only a masked identifier is returned to you. Data is encrypted in transit with TLS, and we follow least-privilege access for our subprocessors.
Subprocessors and certification
Our subprocessors and processing terms are listed in the Data Processing Addendum. We are not yet SOC 2 certified, and we would rather say so plainly than dress it up. SOC 2 Type I is on our near-term roadmap, with Type II to follow once we have the observation window behind us. Security is already built into how the product works: not in your request path, prompts off by default, encrypted keys. You can request a written security questionnaire, and we are happy to walk your security team through our controls directly.
Your controls
You can export your account dataset and schedule workspace deletion from Settings, and toggle prompt capture on or off at any time. Full detail on collection, retention, and your rights is in the Privacy Policy.