Security

Trace Flow proxies LLM API traffic, which means we sit on the path of some of the most sensitive content your application handles: prompts, completions, tool calls, and structured outputs. This page describes the security controls we apply to that data and where your responsibilities begin. It is not legal language; for that, see our Privacy Policy.

You remain responsible for what you send through the proxy. The controls below reduce blast radius and stop common categories of sensitive data from being persisted, but they are not a substitute for treating prompt content as sensitive in your own systems.

Request and response bodies stored in Cloudflare R2 are encrypted with AES-256-GCM. Each organization gets a distinct encryption key derived with HKDF-SHA-256 from a root key held only in Cloudflare Worker secrets. The root key is never exposed to the dashboard, the database, or any logging surface.

Each ciphertext is bound to its owning organization and storage location: a body cannot be decrypted outside the context it was written in. Rotating the root encryption key requires keeping the previous root available until older body objects expire or are re-encrypted.

Every proxy, API, and dashboard route is served over HTTPS with TLS terminated at the Cloudflare edge. There is no plaintext fallback. Traffic between our workers and downstream providers (OpenAI, Anthropic, Google, Groq, OpenRouter) is also HTTPS.

Before bodies are written to R2 or enqueued for the OTel pipeline, the proxy runs pattern-based redaction over the persisted copy. The client's response stream is not modified — your application receives the original, unredacted response. Redaction only affects what we keep.

The current ruleset targets common categories of sensitive data, including:

• Email addresses and phone numbers
• US Social Security numbers and Luhn-valid payment card numbers
• IP addresses
• Bearer tokens and credential-like fields in structured payloads

Redaction applies to request bodies, response bodies, streaming message data, structured input messages, response metadata, and error payloads. Pattern matching is best-effort and is not a substitute for keeping sensitive data out of prompts where possible. Use the body-storage opt-out below for requests you know contain regulated content.

For requests that you know contain sensitive content, set the header X-Trace-Flow-Omit-Body: true. The proxy will skip R2 storage entirely for that request. Usage metadata (model, token counts, latency, cost, provider) is still recorded so dashboards and billing continue to work, but no request or response content is persisted.

The collector discovers and parses supported coding-agent stores locally. A fresh desktop install begins paused, and no agent facts are uploaded until the user selects Start syncing. The normal analytics path uploads typed facts and redacted excerpts, not raw transcripts.

Collector Credentials are separate from gateway API keys. The normal desktop and CLI paths store them in the operating system keychain. Agent Ingest authenticates the credential, enforces organization ownership, and re-redacts free-text excerpts before queueing facts.

Data is scoped to the owning organization at every layer:

• R2 encryption keys are derived per-organization. A ciphertext from one org cannot be decrypted under another.
• Convex queries and mutations enforce organization membership before returning or mutating data.
• Tinybird queries from the dashboard use short-lived (10-minute) JWTs signed by Convex, scoped per user with fixed_params.api_keys and fixed_params.org_id so a user only sees their organization's data. The Tinybird admin token never leaves the Convex environment.

User identity is handled by Auth0. Sessions are managed through the Auth0 Next.js SDK and Convex enforces an authenticated identity on protected queries and mutations.

Proxy ingest is authenticated with opaque API keys passed in the X-Trace-Flow-Api-Key header. Keys are scoped to a single organization and are revocable from the dashboard.

The X-Trace-Flow-Api-Key header is stripped from the request before it is forwarded upstream. Your provider API keys (Authorization, x-api-key) pass through to authenticate with the upstream LLM provider and are not written to Trace Flow's application database, analytics tables, or stored request and response bodies.

Body retention is tier-based: Hobby and Pro plans have different access windows. When Raw API is asked for a body that falls outside the caller's current retention window, it returns HTTP 410 with Bodies expired under current retention policy, regardless of whether the underlying R2 object is still present.

Account deletion windows and your rights to export or delete data are documented in the Privacy Policy.

We rely on the following providers to operate the Service. Each handles a distinct slice of your data.

• Cloudflare—Workers runtime, R2 (encrypted body storage), KV, Queues.Trust
• Tinybird—Usage analytics and trace metrics (ClickHouse).Trust
• Convex—Application database, auth integration, JWT signing.Trust
• Auth0—User authentication and session management.Trust
• Sentry—Performance monitoring, error tracking, and masked website session replay.Trust

If you believe you have found a security issue in Trace Flow, please email security@trace-flow.dev with a description, reproduction steps, and any relevant request IDs. We'll acknowledge receipt, investigate, and keep you informed as we work toward a fix. Please do not publicly disclose the issue until we have had a reasonable opportunity to address it.