Security & data governance
Spancache is built for teams that handle regulated and sensitive data. The core principle is data minimization: by default we store only the numbers you need to understand an agent run — never the conversation itself. This page describes how your traces are handled, isolated, and protected, so a security or compliance reviewer can sign off and a developer knows exactly what leaves their stack.
Metadata-first by default
By default Spancache stores only metadata about each span and trace:
- cost, token counts (including cache), latency and time-to-first-token
- model and provider, tool name, span kind, status and error
- trace structure, outcomes, and timing
No prompt text and no response text is stored. None of it ever needs to leave your environment. This default is safe for regulated and confidential workloads — and it is also all the analytics need. Every chart, cost rollup, and detection in Spancache runs entirely on metadata.
Content capture is opt-in
Some teams want to read the actual conversation on a specific trace while debugging. Content capture — storing prompts and responses alongside the metadata — is an explicit opt-in, chosen during onboarding and set per source. A source you do not opt in stays metadata-only. You decide, per application, whether the conversation is ever captured at all. See sending-traces for how to set the capture level.
Ingest-time secret redaction
Anything you do choose to capture — both span content and agent-event logs — is scrubbed for secrets
at ingest, before it is written to storage. Spancache detects and replaces common credential shapes
with [REDACTED]:
- API keys — OpenAI (
sk-…), Anthropic (sk-ant-…) - AWS access keys (
AKIA…) - Bearer and HTTP-auth tokens
- JSON Web Tokens (JWTs)
- GitHub and Slack tokens
- PEM-encoded private keys
Redaction happens on the ingest path, so opt-in content cannot carry credentials into the store in the first place. The scrub applies uniformly whether a secret appears in a captured prompt, a captured response, or an agent-event log line.
Tenant isolation
Each customer’s data lives in its own isolated store, keyed by your per-tenant ingest token. Every span you send is routed to your tenant and written only there. Every query runs scoped to your tenant and reads only your data. There is no shared table across customers and no cross-tenant access path — one tenant cannot see, query, or reach another tenant’s traces.
Transport & authentication
- TLS everywhere. Ingest (
https://ingest.spancache.ai/v1/traces), the console (https://app.spancache.ai), the workspace (https://api.spancache.ai), and all internal hops run over TLS. - Console is login-gated. Access to
app.spancache.airequires an authenticated session. - Ingest is token-authenticated. Traces are accepted only with a valid per-tenant token presented
as
Authorization: Bearer <token>. You can rotate the token at any time from the workspace, which immediately invalidates the old one. - Keep the token secret. Store it in a secret manager or environment variable — never commit it to source control.
Standards-based, no proprietary agent
Ingestion is pure OpenTelemetry (OTLP/HTTP). There is no closed-source SDK running inside your stack that a reviewer has to audit or trust — you send standard OTel traces from tooling you already control. For a security review, this means the data path is an open standard end to end, and you can see and shape exactly what is emitted before it ever reaches us. See sending-traces.
Deployment options
Spancache runs as a multi-tenant SaaS by default. For enterprises that require data to remain in their own cloud account, BYOC (bring-your-own-cloud) deployment is available.
Your responsibilities
- Protect your ingest token — treat it as a credential; keep it in a secret manager and rotate it if it is ever exposed.
- Choose your capture level deliberately — metadata-only or content, per source.
- Default to metadata-only for regulated data — it is safe for sensitive workloads and powers every feature.