Data Use Policy
Effective: March 4, 2026
How Your Data Flows Through BrainstormRouter
BrainstormRouter is a BYOK (Bring Your Own Key) AI gateway. Understanding what happens to your data at each stage is important.
Request Lifecycle
1. Ingress
Your request arrives at the BrainstormRouter API over HTTPS (TLS 1.2+).
The gateway authenticates your br_live_ key, checks rate limits
and budget constraints, and determines the routing strategy.
2. Routing
The router selects the optimal provider and model based on Thompson sampling scores, complexity assessment, cost-quality frontiers, and your configuration. Your request content is read to assess complexity but is not stored at this stage.
3. Provider Call
The request is forwarded to your chosen AI provider using your own API key (stored encrypted in the Virtual Key Vault). BrainstormRouter acts as a transparent proxy — the provider sees your key and bills you directly.
4. Response
The provider’s response is streamed back to you. Metadata (model, tokens, latency, estimated cost, validity score) is recorded for your usage dashboard.
5. Caching (Optional)
If semantic caching is enabled, a hash of the request is stored in Redis with the response. Subsequent similar requests may be served from cache, reducing latency and provider costs. Cache entries expire automatically.
Data Categories
| Category | Stored | Encrypted | Retention |
|---|---|---|---|
| Account (name, email) | Yes | At rest | Until account deletion |
| Provider API keys | Yes | Application-level + at rest | Until you delete them |
| Gateway API keys | Hashed only | At rest | Until revoked |
| Request content | Cache only | At rest | Cache TTL (minutes to hours) |
| Usage metadata | Yes | At rest | 90 days |
| Memory (if enabled) | Yes | At rest | Until you clear it |
What We Never Do
- We never train models on your data
- We never sell or share your data with third parties
- We never access your provider accounts beyond routing requests
- We never store your provider API keys in plaintext after initial encryption
- We never log request/response content to persistent storage (except cache)
Tenant Isolation
All data is scoped to your tenant. Row-level security (RLS) in PostgreSQL ensures that one tenant cannot access another’s data. Provider keys, usage records, memory, and configuration are fully isolated.
Semantic Cache
When enabled, the semantic cache uses pgvector embeddings (OpenAI text-embedding-3-small)
to detect similar requests. The cache operates with a 0.9 cosine similarity threshold
— only near-identical requests hit cache.
- Storage: PostgreSQL (pgvector) + in-memory LRU
- TTL: Configurable per tenant, default varies by model
- Eviction: LRU eviction when cache size exceeds limits
- Model-agnostic: Cache lookups ignore the specific model, matching on semantic content. An
autorequest can serve a cachedgpt-4oresponse if semantically identical.
Memory Retention
The Relational Memory Manager stores memories in 4 blocks:
- Human: User preferences and corrections
- System: Configuration, constraints, and rules
- Project: Goals, decisions, and context
- General: Shared knowledge and facts
Memories are session-isolated by default. Nightly synthesis compacts memories into durable knowledge (configurable). All memory operations are logged to the audit trail. You can view, search, and delete memories through the dashboard or MCP tools.
PII Scanning
The streaming firewall scans request content for personally identifiable information (PII) before forwarding to providers. Detection includes email addresses, phone numbers, credit card numbers, SSNs, and other patterns. When PII is detected, the request is blocked or redacted based on your tenant configuration.
Data Deletion
You can delete individual provider keys and API keys through the dashboard at any time. For full account deletion, contact hello@brainstormrouter.com. All associated data will be permanently removed within 30 days.