Security
How we protect your keys, traffic, and cached data.
Last updated: June 4, 2026
Encryption
All traffic uses TLS 1.2+. Provider keys in the vault are encrypted at rest with AES-256-GCM (random nonce per write). We store ciphertext and key-id metadata — never plaintext. Keys are decrypted in memory only to call your model provider. Prune API keys are stored as HMAC-SHA256 hashes (peppered), not reversible secrets.
What we can and cannot promise
A managed proxy must decrypt your provider key to call OpenAI/Anthropic on your behalf — that is how drop-in base URLs work. What we prevent is the common failure mode: keys sitting in GitHub, Cursor-generated code, or unlimited spend. We do not claim zero-knowledge, HSM by default, or SOC 2 certification today; see docs/KEY_AND_DATA_SECURITY.md for the hardening roadmap.
Prune Shield
Per-key rate limits, daily spend caps, model allowlists, IP allowlists, and anomaly detection. Shield fails closed: a rejected request is blocked before any upstream LLM call. Rejections include X-Prune-Shield-Code for your UI.
PII & upstream calls
Optional PII tokenization replaces sensitive entities with reversible placeholders before the request leaves Prune for the model provider — the upstream never sees raw emails, phones, or names when the feature is enabled.
Network & headers
Production API uses CORS allowlists, TrustedHostMiddleware, security headers (HSTS, X-Frame-Options DENY, nosniff), and per-key rate limiting. Process logs scrub common API key shapes.
Cache & session privacy
Cache keys are derived from hashed payloads (PII scrub default-on). Semantic cache is tenant-scoped. Optional session context is stored with a 24-hour TTL — not forever.
Reporting
Report vulnerabilities to security@withprune.com. We aim to acknowledge reports within 48 hours.
Questions? Contact hello@withprune.com