Security and Privacy

Aliveo AI is built with security and privacy as foundational principles, ensuring that customer data is protected at every layer of the architecture. Our approach includes strict data isolation, encryption, identity controls, and continuous monitoring to maintain enterprise-grade security.

Compliance Posture

SOC 2 Type II controls cover access management, change management, data handling, vendor risk, and incident response.
Privacy-by-default: customer data is only ever used to operate the service for that customer. We do not train shared models on customer data.
Customer-specific compliance addenda (GDPR, HIPAA, regional residency) are available for enterprise plans—reach out to your Aliveo contact.

Architecture and Network Isolation

Our platform defaults to a multi-tenant model but can also run single-tenant on request:

Multi-Tenant (Default): Customers share a common VPC with logically isolated subnets (front-end APIs, application services, databases) enforced by strict NACLs and security groups. This delivers lower cost, faster onboarding, and centralized updates.
Single-Tenant: Each customer gets its own VPC with separate subnets for front-end APIs, application services, and databases. Dedicated resources provide stronger isolation, no “noisy neighbors,” and full control over network policies—ideal for strict compliance or custom configurations.

Storage and Encryption at Rest

Persistent data resides in individual database instances or object storage buckets dedicated to each tenant. Ephemeral storage, such as cache volumes, also exists only within the customer’s VPC. All storage resources are encrypted using customer-managed keys (CMKs) via a Key Management Service (KMS), ensuring that data, backups, and snapshots remain encrypted. Key rotation is handled by the customer’s KMS policy, and Aliveo AI’s monitoring tools verify active key usage.

Encryption In Transit

External client-to-API communication uses HTTPS with a minimum of TLS 1.2, while internal service-to-service traffic is routed through a service mesh enforcing mutual TLS (mTLS). API gateways, ingress proxies, and database drivers are configured to require encrypted connections. If customers opt for private connectivity, network-layer encryption (IPSec or MACSec) provides an additional layer of protection.

Processing Layer and Access Controls

Compute workloads run in clusters, with each customer assigned a dedicated namespace or separate cluster. Container images undergo vulnerability scanning before deployment, and secrets are injected via a cloud provider’s encrypted secrets management service. Authenticated APIs enforce tenant-scoped requests using JSON Web Tokens (JWTs), ensuring that data operations are limited to the correct customer. IAM roles and service accounts follow the principle of least privilege: developers cannot access production data, operators cannot modify encryption settings, and auditors have read-only log access.

Identity, Authentication, and Authorization

Authentication and authorization protect both the platform UI and its APIs.

Email + password with strength requirements and breached-password rejection.
TOTP-based two-factor authentication (2FA) for any user from their personal account settings.
SSO/SAML for enterprise customers—identity provider becomes the source of truth for membership.

Organization-wide 2FA enforcement

Primary account holders can require 2FA for every member of the team. Once enforced, users who haven’t yet enabled TOTP are routed to a Setup 2FA Required screen on their next login and cannot access the app until enrollment is complete.

Step-up authentication for sensitive actions

Even after you’ve signed in, some actions require a fresh email one-time code to proceed. These include:

Inviting, enabling, or disabling team members.
Toggling 2FA enforcement.
Changing Slack permissions (e.g. allowing non-Aliveo users to call the bot).

This is a defense-in-depth measure: if a session token is somehow compromised, the attacker still can’t escalate without access to the user’s email.

Roles

Aliveo currently models two user roles:

Primary — administrators who can manage integrations, context, team members, and security settings.
Secondary — invited teammates who use the platform with scoped access.

Internal employee accounts (@aliveo.ai) are hidden from customer admin views unless the primary user is themselves an Aliveo employee.

Audit logging

Sensitive admin operations (user invitations, enable/disable, 2FA enforcement changes, integration grants and revocations) are logged with actor, target, and timestamp. Logs are accessible via your Aliveo contact for compliance review.

Data Lifecycle and Retention

Connected ad-platform data is fetched via OAuth; only temporary access tokens are stored, never user passwords.
Custom data (CSV, Sheets) is stored in your tenant’s encrypted buckets and can be deleted on demand.
Chats and workflow runs are retained per the customer’s configured retention policy (default 24 months).
On account closure, customer data is purged from production storage within 30 days; cold backups are purged on the standard backup retention rollover.

Observability and Incident Response

Aliveo monitors agent runs and platform health in real time:

Structured tracing captures every planning, code-execution, and tool-call step (see Evaluations and Observability).
Anomaly detection alerts on schema drift, null spikes, and elevated error rates.
A documented incident-response runbook covers detection, containment, customer notification, and post-mortem reporting.

Customers who require additional contractual notification timelines or dedicated escalation paths can configure them via their enterprise agreement.

For the user-facing security controls (2FA, OTP reauth, disable/enable, SSO), see User Management.