Security
Tenant isolation, hash-chained audit, envelope encryption with crypto-shredding, signed webhooks, RBAC, rate limiting and incident response. This page documents what is in production today, what is in pilot, and what is on the roadmap — without marketing claims we cannot back.
01 · Architecture & isolation
Each customer firm is provisioned as a logically isolated tenant identified by firm_id. Storage, audit log, workflow definitions and API keys are namespaced per tenant. No queries cross tenant boundaries by construction — the data access layer requires an authenticated firm_id on every call.
Storage backend: SQLite per firm with WAL mode (managed cloud default) or PostgreSQL per firm (VPC / on-prem deployment). Multi-tenant shared databases are not used.
API gateway enforces tenant scoping on the URL: every resource endpoint is shaped /api/v1/<resource>/{firm_id}/... and the API key's bound firm_id must match. Cross-tenant access returns 403 unconditionally.
02 · Authentication & authorization
API keys are minted per tenant at provisioning. Keys are hashed (SHA-256) at rest; the raw token is displayed exactly once at issuance and never again. Owner-role keys can be rotated and revoked from the admin console; revocation propagates within one request cycle.
Roles: owner, admin, operator, viewer. Mutation and admin endpoints enforce role guards at the router layer. An automated drift-guard test fails the build if any write endpoint is exposed without an RBAC check.
SSO: SAML 2.0 and OIDC stubs are implemented and tested. Per-IdP wiring (Okta, Azure AD, Google Workspace) is part of enterprise onboarding — see /integrations for current status.
03 · Audit log
Every state-changing call writes an entry to the per-tenant audit log. Each entry includes a SHA-256 hash of its payload plus the hash of the previous entry, forming a chain. Tampering with a historical entry breaks the chain and is detectable by re-verifying the head hash.
Payloads are wrapped in an audit envelope encrypted with a per-tenant Key Encryption Key (KEK). Destroying the KEK renders the payloads permanently unreadable — the chain remains verifiable but the contents become opaque. This is our GDPR Article 17 ("right to erasure") implementation path for audit data.
Retention: configurable per tenant (default 7 years). Export to S3 / object storage available on enterprise deployments.
04 · Cryptography
| Layer | Today | Status |
|---|---|---|
| Transport | TLS 1.3 enforced (managed cloud) | live |
| Audit envelope | AES-256-GCM with per-tenant KEK | live |
| Database at rest | Volume encryption (managed cloud); SQLCipher available for self-hosted | live |
| Secrets storage | Environment variables + .gitignored .env; production secrets via Render / AWS Secrets Manager | live |
| Webhook signing | HMAC-SHA256 on outbound webhooks; replay window 5 min | live |
| Customer-managed KEK (BYOK) | KMS integration for enterprise tenants | on engagement |
05 · Rate limiting & abuse
Public endpoints (payments webhook, chat hub) and tenant-scoped APIs each have independent token-bucket rate limiters. Limits are configurable per tier; defaults: 60 req/min for chat, 120 req/min for payments. SLO histograms emit p50/p95/p99 per route to the metrics endpoint.
Onboarding pipeline is protected by an additional per-IP rate limit (5 requests / minute) to discourage scripted abuse of the engagement form.
06 · Observability
Structured JSON logs on every request (request id, tenant id, route, latency, status). Latency histograms exposed at /metrics (Prometheus-compatible). Public health endpoint at /status returns build SHA + uptime without exposing internals.
Customer-facing audit explorer at /admin/audit per tenant; chain verification is one click.
07 · Incident response
We are a small team. Incident response today means: a single on-call rotation, paged via email + WhatsApp Business, with documented runbooks for rollback, key revocation, and tenant freeze. Target acknowledgement: 1 hour business hours, 4 hours off-hours.
Enterprise engagements include an explicit IR SLA written into the SOW, and an option for joint runbook review with the customer's own security team before go-live.
08 · Coordinated vulnerability disclosure
Report findings to security@sonodadynamics.com with a clear reproduction and proposed impact. We commit to:
PGP key on request. We do not currently run a paid bounty program.
09 · What this page is not
We are not SOC 2 certified today. We do not claim ISO 27001, HIPAA, FedRAMP, or PCI compliance. The controls listed above are real and shipped; formal third-party audit is on the roadmap — see /compliance.
If your procurement team requires certifications we don't yet hold, talk to us — engagement-tier customers receive a written controls attestation and a roadmap commitment letter as part of the SOW.