security
your data, and what we actually do with it.
your research data deserves the same rigor you bring to your science. here's how we protect it at every layer — and what backs the answers it produces: every result names the tool, parameters and run that produced it.
how trust is enforced
trust is derived, never taken on faith.
- credentials
Identity resolves from the validated Clerk session or API key — never a raw, client-forgeable header.
- tenants
Row-level security policies scope your research data to your tenant at the database level.
- record
signed-in runs from the web app, the terminal, curl or MCP leave a tamper-evident record you can check, and so does a guest chat, from the browser tab it is open in, while the guest session lasts.
edit a row and the chain breaks at the verifier. it detects modification; it does not prevent it, and it is not access control.
security overview
defense in depth, across every layer of the stack.
- encryption in transit
all data transmitted between your browser and our servers is encrypted in transit — API traffic, file uploads, and streaming results included.
- encryption at rest
research data, job results, and user credentials are encrypted at rest. database backups are encrypted with separate key management.
- infrastructure security
hosted on Vercel and Supabase; their infrastructure attestations are separate from Ivy Biosciences' own compliance readiness. serverless GPU compute runs on Modal.com with isolated container execution per job.
- access controls
role-based access control via Clerk authentication. API routes are protected with middleware validation. sandbox environments enforce per-user isolation.
- monitoring & logging
real-time security monitoring with audit logging on authenticated API access. anomaly detection for unusual access patterns. CSP headers enforced at build time.
- dependency management
automated vulnerability scanning for all dependencies. security patches applied within 48 hours for critical CVEs.
data handling practices
how we store, isolate, and — when you ask — delete it.
- tenant isolation
all research data is isolated per organization. row-level security policies in Supabase enforce strict tenant boundaries at the database level.
- job result handling
computation results are stored in encrypted object storage and served through signed, time-limited access URLs.
- LLM prompt routing
for PHI- or IP-sensitive prompts, guest LLM requests route only to endpoints that do not retain prompts (zero data retention, or ZDR), with provider data collection denied. signed-in OpenRouter requests deny provider data collection but are not restricted to ZDR endpoints. these provider-routing controls do not cover research data stored in the platform or establish HIPAA compliance. see /help/compliance for the current HIPAA status.
- data deletion
users can delete their research data at any time through the platform. an erasure request deletes your data store by store; the hash-chained audit logs are kept for now, pending a ruling on erasure and record retention, and the erasure report lists every store kept and why.
- sandbox isolation
each sandbox session runs in an isolated container with no shared filesystem. containers are destroyed after use with no persistent state between sessions.
responsible disclosure
found something? tell us first.
send vulnerability reports to [email protected] (a PGP key is available on request for encrypted reports). include a detailed description of the vulnerability, steps to reproduce, and any proof-of-concept code. we ask that you avoid publicly disclosing the issue until we've had a chance to investigate and deploy a fix.
- receipt
acknowledgment: within 48 hours
we confirm receipt of your report and assign a tracking identifier.
- triage
investigation: within 7 days
our team reproduces and assesses the severity of the reported issue.
- fix
critical resolution: within 30 days
critical and high-severity vulnerabilities are patched and deployed.
- disclose
disclosure: after fix deployed
coordinated disclosure with public acknowledgment (with your permission).
- ivybiosciences.com web application
- public API endpoints (/api/*)
- authentication and authorization flows
- sandbox and compute isolation boundaries
- data leakage between user accounts
- cross-site scripting (XSS) and injection attacks
- denial of service (DoS/DDoS) attacks
- social engineering or phishing
- third-party services (Clerk, Supabase, Modal.com)
- issues requiring physical access
- automated scanning without prior approval
- rate limiting or brute force on login (use Clerk's protections)
compliance & certifications
the certifications named here are our providers'.
for compliance frameworks, data processing agreements and regulatory readiness — or a security review for your organization — start with the compliance page, or talk to us.