Security Overview

One identity provider is the authority for authentication and organization membership. Every service validates bearer tokens against the provider's published key set using cached keys and local cryptography; identity (subject, organization, roles) is extracted from token claims and attached to the request context. No long-lived service credentials are issued; short-lived bearer tokens replace them.

Organization administrators can require multi-factor authentication and passkeys through the identity console. Session configuration — password rules, MFA enforcement, SSO federation — is customer-editable end to end.

Customer workloads run inside hardware-virtualized microVMs, with per-tenant durable volumes as their filesystem. VM-to-VM isolation is a hypervisor-level boundary; host access is restricted to a single privileged orchestration daemon. Product services have no host-level access to the hypervisor device nodes, storage administration interfaces, or jail directories — they interact with the compute substrate only through a narrow, policy-checked API.

In-guest telemetry is collected over an isolated host-to-guest channel; the guest does not reach the host network by default.

All external and inter-service traffic uses TLS 1.3, terminated by a first-party reverse proxy running a web application firewall; certificates are issued automatically using DNS-01 challenges. Operational secrets are held encrypted at rest in the platform inventory and delivered to each service through an ephemeral credential loader, so application processes read them from process-private memory rather than from files on disk.

Dataset-level encryption at rest is supported for durable customer volumes; the encryption posture of each volume is visible on its billing record.

The host firewall denies by default and allows inbound traffic on a per-service basis; services listen only where their declared role requires. Single-node deployments keep inter-service traffic on loopback; multi-node deployments route inter-service traffic over a private overlay network with the same allowlist model. Customer-facing ingress is TLS-terminated at the reverse proxy before reaching any product service.

Every service emits structured logs, traces, and metrics into a central observability store. Administrative actions taken on the host — including deploys — emit spans correlated to the same trace identifier as the service calls they trigger, so post-incident inspection reads as a single narrative.

Detection thresholds and alert routes run on the founder dashboard. Security-incident artifacts are retained separately from normal operational TTLs — see the Data Retention policy.

Access to the host and to production data is restricted to named founders, authenticating with hardware security keys. Administrative actions taken on the host are audit-logged and fed into the same observability pipeline as service traces.

We welcome security research. Report findings to the security mailbox below, or via our published /.well-known/security.txt. Good-faith research conducted in line with the disclose.io core terms is covered by a safe-harbor commitment: we will not pursue legal action, and will work with you on coordinated disclosure. Do not exfiltrate customer data; do not degrade service for other customers; respect the 90-day coordinated-disclosure norm unless we agree on a different timeline.

Material changes take effect 30 days after they are announced by email to the administrators on each affected organization. The effective date at the top of this page is the date the current version took effect. Prior versions of all policies live at /policy/changelog, and every change is recorded there in commit-addressable form.

Policy identifier: security.

Questions and requests under this policy go to security@anveio.com. Security reports go to security@anveio.com and take precedence over routine policy correspondence. GDPR data-protection correspondence may be directed to dpo@anveio.com; abuse reports to abuse@anveio.com.