Compliance
Sphyr is built from the ground up with privacy-by-design principles. Here is how we handle your data, protect your agents, and keep you in control.
GDPR Compliance
Sphyr provides a full GDPR data scrub endpoint at /v1/users/:id. When a data subject requests erasure, an operator can invoke this endpoint to permanently delete all personally identifiable information associated with that user from the D1 database and KV stores. The operation is irreversible and returns a confirmation with a UTC timestamp.
The GDPR scrub endpoint is admin-gated — it requires a valid X-Admin-Key header and is protected by the IP allowlist enforced at the worker level. End users cannot self-invoke deletion; all deletion requests must be routed through your designated data controller.
We do not store email addresses in plaintext in any operational table. Email-derived values (where used for lookup) are stored as hashed identifiers, limiting the blast radius of any data exposure incident.
Data Handling Practices
Our guiding principle is minimal collection with aggressive purging. We collect only the data required to enforce security policies and provide billing transparency.
- check_circle No raw URLs stored. Target URLs are hashed using SHA-256 before being written to forensic logs. The original URL is never persisted.
- check_circle Configurable purge windows. Diagnostic rationale data purges after 30 days by default (
raw_purge_at). Hashed URL logs are retained for 180 days for audit trail continuity. - check_circle No plaintext IP addresses in forensic logs. IP addresses used for session binding are processed in-memory and are not written to the long-term forensic store.
- check_circle Privacy-by-design architecture. Data minimization is enforced at the schema level. Fields that could contain PII are either hashed, omitted, or subject to automatic purge timers — not left to operator configuration.
Responsible Disclosure
We welcome responsible security research on Sphyr. If you discover a vulnerability, please report it through our coordinated disclosure process before any public disclosure. We commit to acknowledging reports within 48 hours and providing a remediation timeline within 7 days for confirmed critical issues.
Active probing of the production gateway — including fuzzing, brute-force, or automated scanning that generates substantial load — requires prior written approval from the Sphyr security team. Refer to Section 8 of the Terms of Service for the full acceptable use policy governing security testing.
Full disclosure guidelines, contact information, and the scope of our vulnerability disclosure program are documented in our security policy:
open_in_new View SECURITY.md on GitHubPlatform Security
Sphyr runs on Cloudflare Workers — a platform with strong isolation guarantees by design.
No Persistent Processes
Cloudflare Workers infrastructure runs your code on-demand with no persistent server processes. There is no long-running daemon to compromise between requests.
V8 Isolate Model
Each request runs in its own V8 isolate — a sandboxed JavaScript execution context with no shared memory between requests or tenants. Secrets are not accessible across request boundaries.
Edge-First Architecture
Policies are enforced in under 10ms from 300+ global Cloudflare locations. Security decisions happen close to the agent, not after a round-trip to a central server.
Secret Management
All secrets (HMAC keys, Stripe keys, admin key) are stored via Cloudflare Workers Secrets — never in source code or wrangler.toml. Secrets are injected at runtime and are never logged.
For full legal details, see our Terms of Service and Privacy Policy.