Data Posture

Spendline, Inc. · Last updated: July 28, 2026

Spendline is a proxy in the path of your AI traffic. That position comes with an obligation to be precise about data handling, so this page is written against the code, not against marketing copy. It states exactly what we retain, what we strip, what we forward, and what we encrypt.

The short version: zero prompt retention, metadata only. Your prompts and your model's responses pass through Spendline in memory and are never written to disk. What we keep is the accounting: tokens, cost, latency, and attribution.

What we never store

Prompt text. The content of your messages is never persisted.
Model responses. Completions, including streamed responses, are delivered to you and not retained.
System prompts. Read in memory only, for token estimation.
Attachments and file content. Passed through, never written.

Request content exists inside Spendline only for the lifetime of the request. That is long enough to count tokens, apply your budget and policy rules, and forward it. When the response is delivered, the content is gone.

What we retain: the ledger

Every call writes one append-only ledger row containing operational metadata only:

Usage & cost

Token counts (including cached and reasoning breakdowns), computed cost, model, provider, latency, and the provider's own usage counters. Numbers, not content.

Attribution

The labels you send: customer, agent, workflow, step, and tags. This is what lets every dollar be attributed to the right owner at month close.

Outcome metadata

Status codes, error types, block reasons, and timestamps. These describe what happened to the request, never what was in it.

One fingerprint

A truncated one-way SHA-256 hash of the prompt, used to detect duplicate calls that waste spend. It is 16 hex characters and cannot be reversed into content.

The ledger is append-only: rows are never edited or deleted, and corrections are recorded as new adjustment rows. Every row is isolated to your tenant.

What we strip

Before your request is forwarded, Spendline removes its own credentials. The Spendline API key headers your application sends us never reach your model provider. Your provider receives your request authenticated with your provider key, nothing more.

What we forward

Your request body is forwarded unchanged to the provider you chose. The one exception is a cross-provider reroute you have explicitly configured, where the request is translated format-to-format in memory. Forwarding happens over TLS. Your provider key is used solely to authenticate the request with your provider.

What we encrypt

Provider keys

Stored provider keys are encrypted at rest with AES-256-GCM, a unique random IV per key, and a master key held outside the database. Only the last four characters are ever displayed.

Spendline keys & passwords

Spendline API keys and user passwords are bcrypt-hashed. We cannot recover a raw key after it is issued, which is why it is shown exactly once.

In transit

TLS 1.2+ on every hop, from your application to Spendline and from Spendline to your provider. Unencrypted connections are not accepted.

At rest

Ledger and account data are encrypted at rest in our database infrastructure using AES-256.

Why this posture

Spendline's job is financial: attribution, budgets, and a defensible month close. All of that is computable from metadata. Storing your content would add risk without adding a single capability, so we don't.

Verify it yourself

Every claim on this page corresponds to a specific code path in the proxy. If your security team wants to validate any of it, whether that is the ledger schema, how keys are encrypted, or how headers are stripped before forwarding, contact us at fida@spendline.ai and we will walk them through it directly.

See also our Security and Privacy pages.