Security Whitepaper
Spendplane security and data handling overview
Current as of April 5, 2026. This document is an implementation-level overview of the controls that are present in the product today. It is intended to help customers understand how Spendplane currently handles routing, privacy screening, provider credentials, and workspace controls.
Architecture scope
Spendplane currently operates as an application-layer AI proxy and workspace control plane. Requests can be routed through a local runner, provider-backed cloud access, and tenant-level routing policy. This document describes the current product behavior as implemented today. It is not a certification packet and it does not describe infrastructure that is not yet shipped.
Data handling
The proxy path is designed to forward requests to upstream model providers while recording operational metadata such as token usage, cost, model selection, and workspace context. Spendplane exposes usage reports, project activity views, and billing summaries built on that metadata. This whitepaper does not claim zero storage across the entire product. It describes where request scrubbing, runtime routing, and usage logging exist today.
Privacy controls
Spendplane includes privacy controls that can detect and redact common sensitive values before egress. Built-in rules cover email addresses, phone numbers, IPv4 addresses, SSNs, credit cards, bearer tokens, API keys, and private keys. Workspaces can also define custom exact-match and regex-based sensitive object rules. Current egress modes include allow, sanitize, block, and local-only.
Secrets handling
Provider credentials can be stored per tenant for supported providers including OpenRouter, Runpod, Salad, and Vast. The product masks stored key previews in the UI and uses tenant-scoped key records to resolve provider access. At the time of writing, this is application-managed provider key storage backed by the product database. It should not be described as an HSM-backed vault.
Workspace controls
Spendplane supports authenticated workspaces, member roles, tenant settings, workspace spend caps, environment records, and routing policy controls. Routing policy can include preferred routing posture, excluded models, deployment mode settings, selected data region, and allowed data regions. These settings are real product controls; however, they should be interpreted as current policy/configuration fields unless a dedicated deployment arrangement has been explicitly provisioned.
Current controls
The following controls are reflected in the current codebase and product surfaces. They describe what the product can do today, not future roadmap commitments.
OpenAI-compatible proxy endpoint for workspace traffic
Local runner configuration and health probing
Tenant-scoped routing preference and model exclusions
Privacy scanning with sanitize, block, and local-only egress modes
Tenant-scoped provider key management for supported providers
Workspace spend caps, member controls, and project-level controls
Usage reporting, billing summaries, and project activity views
Current limitations and non-claims
This section separates shipped controls from claims that would require additional evidence, legal agreements, or infrastructure work.
Security review process
If you need a deeper security review, the next step should be a live walkthrough of your intended deployment shape, routing posture, and data handling requirements. This whitepaper is the current baseline document for that conversation.