Compliance
Sphyr collects only hashed request metadata — never plaintext URLs or IP addresses — and purges diagnostic data within 36 days. Here is how we handle your data, enforce transport-layer policy, and keep your request logs auditable.
What does source-available mean?
Sphyr Agent Guard is published under the Functional Source License 1.1 (FSL-1.1-ALv2). Source-available means the code is publicly readable, runnable, and modifiable — but with one restriction for 2 years.
- Can I read the code? Yes. The full source is on GitHub.
- Can I run it or self-host it? Yes — for internal use, research, or education.
- Can I build a competing SaaS with it? Not for 2 years from the date we publish it.
- After 2 years? The license converts automatically to Apache-2.0 on 2028-04-01 — fully open source, no strings attached.
Full license text: LICENSE · fsl.software
Data Privacy Practices
Sphyr is not a GDPR compliance solution and does not make your application GDPR-compliant. The following describes Sphyr's own data handling practices.
Sphyr provides a data scrub endpoint at /v1/users/:user_id. When a data subject requests erasure, an operator can invoke this endpoint to delete all directly identifying information associated with that user — including the Stripe customer ID link, request rationale fields, and active session data. The operation is irreversible and returns a confirmation with a UTC timestamp.
Pseudonymized financial transaction records (credit ledger entries and payment event records, identified only by an anonymized user ID) are retained as required by applicable financial record-keeping law and for payment dispute resolution. These records do not contain name, email, IP address, or any directly identifying information.
The GDPR scrub endpoint is admin-gated — it requires a valid Authorization: Bearer <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.
GitHub email addresses are stored to support Stripe checkout pre-fill (receipt personalization) and are displayed in the console account view. These are the only plaintext email values we store. All other identifiers that could link to real-world entities (URLs, session origins, caller IPs) are stored as one-way salted SHA-256 hashes.
Sphyr acts as a data controller for account-holder data (GitHub identity, email address, billing records). For request metadata generated by your agents, Sphyr acts as a data processor on your behalf. A Data Processing Agreement (DPA) is available upon request at legal@sphyr.io.
Data Processing Agreement (GDPR Art. 28)
Business customers who process end-user data through Sphyr can request a Data Processing Agreement (DPA) at legal@sphyr.io. The DPA formalises Sphyr's role as a data processor under GDPR Article 28.
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.
- No raw URLs stored. Target URLs are hashed using a salted SHA-256 before being written to forensic logs. The original URL is never persisted.
- Automatic purge windows. Diagnostic rationale data purges within 36 days (typically 30 days, up to 6 days of cron lag) (
raw_purge_at). Hashed URL logs are retained for 180 days for audit trail continuity. - Hashed IP addresses in request logs. Caller IPs in
request_logsare stored asSHA-256(ip + LOG_SALT)— the original IP is never persisted in forensic logs. (Plaintext IPs are retained only on the admin audit log so operators can investigate destructive admin actions.) - 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 aim to acknowledge reports within 3 business days and to provide a remediation timeline within 5 business days of triage 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:
View SECURITY.md on GitHubPlatform Security
Sphyr runs on Cloudflare Workers, which uses a V8 isolate model — each request runs in a sandboxed JavaScript execution context with no shared memory between requests or tenants.
Sphyr does not currently hold SOC 2, ISO 27001, or equivalent third-party security certifications. The source-available codebase is available for review at github.com/Sphyr/agent-guard.
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 inline at the Cloudflare edge — security decisions happen close to the agent, on Cloudflare's globally distributed network. See cloudflare.com/network for current infrastructure details.
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.