Security Architecture
ozDNA is a layered platform: AI gateway, model router, prompt registry, RAG, cost engine, and observability — operated by Findbelow Ventures. Every external request enters through authenticated gateway boundaries before reaching inference or retrieval subsystems.
- Perimeter: HTTPS-only public endpoints; invite-only API keys during private beta
- Gateway: Auth, rate limits, and audit hooks before workflow execution
- Isolation: Environment-separated sandbox (api.sandbox.ozdna.com) and production (api.ozdna.com)
- Least privilege: Scoped API keys; no anonymous inference on paid workflows
- Vertical boundaries: Mode-specific prompts and corpora (academic, legal, financial)
Encryption at Rest
Customer data at rest inherits encryption from underlying cloud providers. ozDNA does not store raw API keys in plaintext.
| Asset | Approach | Status |
|---|---|---|
| API keys (stored) | Salted hashes only; plaintext shown once at creation | Live |
| Database | Provider-native encryption (managed Postgres roadmap) | In Progress |
| Object / vector storage | Provider-managed encryption for RAG corpora | Roadmap |
| Backups | Encrypted backup volumes per provider policy | Planned |
Encryption in Transit
All customer-facing traffic requires TLS. Internal provider connections use HTTPS to upstream LLM and embedding APIs.
- Web & docs: TLS 1.2+ on ozdna.com (Netlify CDN)
- Platform API: HTTPS enforced on api.ozdna.com and sandbox endpoints
- Provider calls: TLS to OpenAI and routed inference providers
- Webhooks: HMAC-SHA256 signatures on outbound callbacks (X-OzDNA-Signature)
Secrets Management
Secrets never ship in client-side code, public repositories, or static marketing assets.
- Environment-scoped configuration for provider keys and database credentials
- Separate secrets per sandbox and production environments
- Rotation supported for API keys via dashboard (roadmap) and manual revoke today
- CI/CD injects secrets at deploy time — not baked into container images
API Authentication
All platform endpoints require a valid Bearer token. Unauthenticated requests receive 401 before reaching inference logic.
| Mechanism | Detail | Status |
|---|---|---|
| Bearer tokens | Authorization: Bearer ozdna_sk_* | Live |
| Key prefixes | ozdna_sk_test_ / ozdna_sk_live_ | Live |
| Revocation | Immediate invalidation on key delete | Live |
| SSO / SAML | Dashboard and enterprise identity | Planned |
See API documentation for integration details.
Rate Limiting
Rate limits protect platform stability and enforce plan quotas at the gateway layer.
- Per-key request quotas enforced before workflow dispatch
- 429 responses with retry guidance when limits exceeded
- 402 when billing quota exhausted
- Configurable limits per organization — enterprise roadmap
DDoS Protection
Public surfaces inherit DDoS mitigation from CDN and hosting providers.
- Marketing & docs: Netlify CDN edge protection and automatic TLS
- API gateway: Provider-level network filtering on deployment target (Fly.io / Railway / AWS roadmap)
- Application layer: Rate limiting and auth as first-line abuse controls
- WAF: Dedicated Web Application Firewall — Planned for production API
Logging
Structured logs capture security-relevant events without storing unnecessary payload content.
- X-Request-Id on every API response for trace correlation
- Authentication success/failure, rate-limit hits, and quota events logged
- Prompt hash and model ID per inference — not full prompt text in default logs
- RAG ingest, retrieve, and eval events with org scope
- Exportable audit logs for enterprise — In Progress
Audit logging details: Trust Center — Audit Logging
Monitoring
Platform health and anomaly detection cover availability, latency, and error rates.
| Signal | Scope | Status |
|---|---|---|
| Health checks | GET /health, gateway status | Live |
| Error rates | 4xx/5xx by endpoint and org | Live |
| Latency & cost | Per-workflow metrics dashboard | In Progress |
| Public status page | Platform availability | Live |
| On-call paging | 24/7 for enterprise tier | Planned |
Backups
Backup and recovery procedures align with disaster recovery targets documented in the Trust Center.
- Automated database backups on managed Postgres migration — Roadmap
- Point-in-time recovery target: RPO < 1 hour (enterprise roadmap)
- Quarterly restore drills — Planned
- Configuration and prompt registry versioning via git-backed prompt store
DR objectives: Trust Center — Disaster Recovery
Vulnerability Disclosure
We welcome good-faith security reports from researchers, customers, and the community.
- Contact: security@ozdna.com (placeholder — monitored by Findbelow Ventures security contact)
- Machine-readable: /.well-known/security.txt (RFC 9116)
- Scope: ozdna.com, api.ozdna.com, api.sandbox.ozdna.com, and ozDNA platform services
- Out of scope: Third-party providers (OpenAI, Netlify), social engineering, physical attacks
- Response: Acknowledgment within 3 business days; critical issues triaged within 24 hours
Responsible Disclosure Policy
To protect ozDNA customers, we ask reporters to follow coordinated disclosure.
- Report vulnerabilities privately to security@ozdna.com with reproduction steps and impact assessment.
- Allow reasonable time for remediation before public disclosure — typically 90 days, sooner for critical issues once patched.
- Do not access, modify, or exfiltrate customer data beyond what is necessary to demonstrate the issue.
- Do not perform denial-of-service, spam, or social engineering against ozDNA staff or customers.
- Do not test against production customer workloads without written authorization.
We commit to:
- Acknowledge receipt of your report
- Provide status updates at reasonable intervals
- Notify you when the issue is resolved
- Credit researchers on our acknowledgments page (with your consent)
This policy does not authorize testing that violates applicable law. If you are unsure whether your research is permitted, contact us before proceeding.
Security contact
Report vulnerabilities, request a security review, or ask about our controls.