We help organizations build resilience — so our own platform must lead by example. Here is how we protect your data and maintain the security of the Avsentia platform.
Avsentia does not store customer BC/DR plans by default. Plans generated through Dave are session-only — when your session ends, the output is not retained on our servers. This is a deliberate architectural choice that dramatically reduces your data exposure risk. Offsite storage is available as an explicit, paid opt-in for organizations that need it.
How we keep every tenant's data, credentials, and automated actions strictly isolated from every other tenant's.
Tenant-specific message-bus topics and storage path prefixes ensure one tenant's data can never be read from or written into another tenant's channel or storage location.
Each tenant's third-party secrets (SIEM/BCDR API keys, etc.) are stored in a separate, encrypted vault path. An agent can only request the credentials of the tenant it is acting on behalf of.
Every action-triggering event carries a tenant identifier that automated response agents are hard-coded to honor, so a playbook for one client can only act on that client's own assets with that client's own credentials.
Clients with the highest security/regulatory requirements (e.g., government, healthcare) can be provisioned a fully dedicated, separate infrastructure stack for maximum physical and logical isolation.
Platform self-protection: tenant, billing, and account management functions are architecturally separate from the data plane where agent processing occurs. Client-side components have no network path to platform management systems, so a compromised client environment cannot be used to attack core platform services. Core processing agents hold no standing credentials — they request short-lived, task-scoped credentials for each authorized action.
No service trusts any other service or network segment by default.
| Segment | Hosts | Access Policy |
|---|---|---|
| Ingestion / Perimeter | External-facing threat-intel ingestion and APIs | Outbound-only to the internet; zero inbound access except via a hardened jump host/VPN |
| Core Processing | The real-time correlation engine, message queue, and policy engine | No direct internet access; accepts traffic only from the Ingestion segment and the isolated Management network |
| Customer Data | Customer-specific operational data and asset/alert context | Fully isolated; communicates only with Core Processing over dedicated, encrypted, access-controlled links |
All service-to-service traffic requires mutual TLS (mTLS) with certificate-based identity verification, management access is routed through a dedicated bastion/VPN with mandatory MFA, and every segment is subject to mandatory flow-log and service-log monitoring for unauthorized-access detection. This design is substantially implemented; it has not yet been independently penetration-tested or formally certified (e.g., SOC 2) — see the compliance status below.
Trust Services Criteria implementation status
Access Control
MFA enforced for all admins; user TOTP enrollment available
System Operations
Sentry + Vercel + Supabase audit logs; IRP documented
Change Management
PR-required GitHub workflow; branch protection enabled
Vendor Management
All vendors SOC 2 Type II certified; reports on file
Confidentiality
No persistent BC/DR plan storage by default; AES-256 at rest
Availability
99.9% SLA target; RPO < 1hr, RTO < 4hr
Privacy
Privacy Policy published; CCPA/GDPR data subject rights process in place
Formal SOC 2 Type I audit is planned. Enterprise customers may request our security documentation package by contacting security@avsentia.com.
All data is encrypted in transit and at rest using industry-standard algorithms.
| Data Type | Method | Details |
|---|---|---|
| Data in Transit | TLS 1.2+ | Enforced by Vercel edge network on all connections |
| Data at Rest | AES-256 | Supabase/PostgreSQL managed encryption |
| Passwords | bcrypt | Never stored in plaintext; hashed via Supabase Auth |
| API Secrets | Env vault | All secrets stored in Vercel encrypted environment variables — never in source code |
| Session Tokens | JWT (HS256) | Short-lived tokens with automatic expiry and rotation |
Layered access controls enforce least-privilege access across the entire platform.
Every vendor with access to our infrastructure or customer data holds a current SOC 2 Type II certification.
We welcome security researchers who responsibly disclose vulnerabilities in the Avsentia platform. If you believe you have found a security issue, please report it to us privately before public disclosure.
Please do not access customer data, disrupt production services, or publicly disclose findings before coordinating with us. We commit to no legal action against good-faith researchers.
Security Team
security@avsentia.comEnterprise customers may request our full security documentation package, SOC 2 reports from our vendors, and a security questionnaire response.