Security

How AdaptCX secures your tenant end-to-end. This is the customer-facing security posture — for internal engineering detail, use the internal engineering portal.

Identity

MFA is on by default. Every account enrolls a TOTP authenticator at first login and receives recovery codes. Password-only logins are not permitted for anything other than the initial enrollment.

SSO is supported for enterprise IdPs — Azure AD, Okta, Google Workspace, or any OIDC-compliant provider. When SSO is enabled, invited users get an SSO-only account (password login is disabled for their record). Configure in Tenant Admin → SSO.

JWT sessions are short-lived (~1 hour) and refresh transparently while the user is active. Sessions are revocable — a super_admin can force-logout any user from Tenant Admin → Users → session controls.

Anomaly detection watches for brute-force, impossible-travel, and session-anomaly patterns. Suspicious sessions trigger a re-authentication challenge.

Roles + access

AdaptCX ships with a role model that covers most organizations out of the box:

• super_admin — platform administration (creating other admins, tenant-level settings). Rare, held by a small number of accounts per tenant.
• tenant_admin — user management, integrations, billing, branding for the tenant.
• bot_admin — build and manage bots, flows, KBs.
• assist_admin — configure agent-assist workflows (assist customers only).
• supervisor — supervise live agents, review conversations, adjust queue routing.
• agent — handle live conversations in the Agent Desktop.
• analyst — read analytics + reports, no write access.
• viewer — read-only access to bots and conversations.

Roles are assigned per user in Tenant Admin → Users. A user can hold multiple roles. Permissions are additive.

Custom roles (organizations that need a permission mix outside these defaults) can be created by a super_admin — see Users & Roles.

Data protection

Encryption in transit

• External traffic — TLS 1.2+ on every public endpoint. Certificates are Google-managed.
• Internal traffic — strict mTLS between all backend services via Anthos Service Mesh. Every service-to-service call is cryptographically authenticated with a SPIFFE identity.
• Database traffic — TLS to the database, with server certificate verification (verify-full).

Encryption at rest

Multiple layers, deepest first:

1. CMEK (Customer-Managed Encryption Keys) — every storage layer (Postgres, Redis, GCS, KMS) is encrypted with keys in a per-customer Cloud KMS key ring. Keys are rotated on schedule per your compliance requirements.
2. Application-layer PII encryption — sensitive columns (email, phone number, transcript excerpts, DLP-flagged content) are encrypted BEFORE being written to the database, with a KMS-derived envelope key. Even a database dump doesn't reveal the plaintext.
3. WORM audit logs — audit log rows carry a database-level trigger that blocks deletes below the framework retention floor (default 2190 days). Compliance auditors can verify no evidence has been removed.

PII redaction

Before storing conversation transcripts or logs, AdaptCX runs Google Cloud DLP to detect and redact PII (SSN, credit card, health info, personal identifiers). The redacted transcript is what's stored; the original message is never persisted after redaction.

• Redaction is configurable per tenant — you can opt in to broader detectors (financial data, health data) if your industry requires it.
• Redaction happens synchronously on every message before it hits the database.

If DLP misses a PII pattern (which does happen with novel input formats), the term used in incident-response docs is "unredacted" — the data is in the database but shouldn't be. That triggers a review + retroactive redaction workflow.

Tenant isolation

Your tenant's data is invisible to every other tenant. Enforced at multiple layers:

• Database-level — every row is stamped with tenant_id; every query filters on it.
• Auth-level — JWTs carry the user's tenant_id; middleware pins the request to that tenant.
• Encryption-level — PII is encrypted with a per-tenant key. Even a leaked ciphertext can't be decrypted from another tenant's session.
• Mesh-level — even internal service-to-service traffic is authenticated with SPIFFE identities; there's no "internal" bypass.
• Cluster-level (dedicated tier) — dedicated tenants run in their own GCP project with their own database instance.

Cross-tenant reads require an explicit code path — there isn't one in the platform.

Availability

• Every tenant runs in a regional GKE Autopilot cluster spread across 3 zones. Zone outages are transparent — traffic re-routes to healthy zones automatically.
• Region outages are handled per your SLA tier:
  • Standard tier — regional; a full region outage means recovery when the region does (typically hours, publicly documented incidents).
  • Regional DR tier — a warm standby cluster in a second region. Failover RTO ~15–60 minutes; RPO measured in seconds via Cloud SQL replication.
  • Multi-region tier — active-active across two regions with latency-based routing. Failover is transparent.
• Automated backups — daily Postgres backups plus point-in-time recovery within the retention window (default 7 days). Backup restoration is a support-ticket operation.

Audit logging

Every security-relevant action is logged to audit_logs — a WORM (write-once, read-many) table with a database trigger that blocks deletes below the framework floor.

Logged events:

• Every login (success + failure), MFA challenge, SSO redirect
• Every permission-denied response (with the requested resource + user)
• Every user/role/permission change
• Every integration credential change
• Every export or bulk operation
• Every super_admin action platform-wide

Retention: minimum 2190 days (6 years), can be extended per your compliance framework.

Export: audit logs are exportable to your SIEM via the audit-log REST endpoint. Format is JSON; each record includes actor, resource, timestamp, source IP, and full request metadata.

Security controls in place

The full list of controls AdaptCX enforces on every tenant. Use this as reference when evaluating fit for your organization's security requirements:

Identity & access

• MFA enrolled on every account (TOTP + recovery codes)
• SSO via any OIDC provider (Azure AD, Okta, Google Workspace)
• Short-lived JWT sessions (~1 hour) with silent refresh
• Session-revocation controls for super_admin (force-logout)
• Anomaly detection: brute-force, impossible-travel, session-anomaly triggers re-authentication
• IP reputation checks on login (MaxMind, IPinfo, IPQualityScore)
• RBAC with granular permissions, additive across roles
• Custom role support beyond the default set

Encryption

• TLS 1.2+ on every external endpoint, managed certificates
• Strict mTLS between all backend services (Anthos Service Mesh + SPIFFE identities)
• Database TLS with verify-full server-certificate check
• CMEK (customer-managed encryption keys) on Postgres, Redis, GCS, KMS — per-customer key ring
• Application-layer PII encryption for sensitive columns via KMS-derived envelope keys
• Envelope-encrypted at rest even in database dumps

PII protection

• Google Cloud DLP runs synchronously on every message before persistence
• Redaction is per-tenant configurable — opt in to broader detectors (financial, health)
• Retroactive redaction workflow when a PII pattern is missed (unredacted)

Tenant isolation

• tenant_id filter enforced on every query at the ORM layer
• Per-tenant KMS envelope keys — cross-tenant ciphertext is unreadable
• JWT-bound tenant identity — no "act as another tenant" code path
• Mesh-level SPIFFE identity — internal traffic is authenticated
• Dedicated-project tier available for customers requiring physical isolation

Audit & retention

• Every login, MFA challenge, permission-denied, integration change, admin action logged to audit_logs
• WORM (write-once, read-many) trigger blocks deletion below the retention floor
• Minimum retention: 2190 days (6 years); extensible per your requirements
• SIEM export via the audit-log REST endpoint (JSON, includes actor, resource, timestamp, source IP)
• Long-term archival to Cloud Storage

Data protection

• Automated daily Postgres backups + point-in-time recovery
• Voice recordings on retention-locked buckets (WORM at the storage layer)
• Configurable message-history retention per tenant (default 90 days)
• Tenant-admin data-purge tooling for right-to-erasure requests

Network

• All internal services run inside a private VPC
• Cloud SQL / AlloyDB accessible only via private IP
• Only the API gateway (and voice endpoint, if enabled) are internet-facing
• Cloud Armor WAF on public endpoints (OWASP CRS, rate limiting, geo controls)
• Per-tenant IP allowlist available for the admin portal

Content safety

• Model Armor (adversarial-prompt defense) — opt-in per tenant
• Conversation fraud detection (prompt injection, social engineering, PII leakage patterns)
• Per-node integration scoping — bots can only reach integrations the tenant has explicitly wired

Availability

• Regional GKE Autopilot clusters spread across 3 zones (zone loss is transparent)
• Regional DR tier: warm standby in a second region, RTO ~15–60 min
• Multi-region tier: active-active with latency-based routing, transparent failover

Incident response

If you suspect a security incident:

• Data exposure suspected — contact your AdaptCX support channel immediately. Do not delete pods, logs, or export artifacts before the security team has state.
• Suspicious login patterns — the Tenant Admin's Security dashboard shows recent anomaly events. Individual accounts can be force-logged-out from Users → session controls.
• Content flagged incorrectly — some conversations may need retroactive redaction if DLP missed a PII pattern. Flag the conversation via the Agent Desktop's compliance tools; the retroactive redaction job runs on the flagged transcript.

Every security-impacting incident results in a written postmortem that your AdaptCX contact will share on request.

Related

• Users & Roles — full permission model + custom role creation.
• Integrations — how third-party credentials are stored + rotated.
• Architecture — the technical arrangement that makes the isolation above possible.