Aitelligent logo
Sign in
Enterprise

SSO/SAML, audit logs, role-based access and customer-managed keys

Aitelligent holds your most sensitive post-sales signals: CRM records, support tickets, call transcripts and revenue data. This page explains exactly how the four Enterprise controls work, so a security or procurement reviewer can assess them without a call.

Talk to us Security & compliance

SSO / SAML per tenant

Your identity provider stays the single source of truth for who can reach post-sales data.

Tamper-evident audit logs

Every privileged action is recorded with actor, timestamp, target company and change detail.

Role-based access

Roles are stored and validated server-side, then enforced on every row of every query.

Customer-managed keys

You hold the master key in your own KMS, so you can rotate or revoke access to your data.

Single sign-on and SAML

  • Connect any SAML 2.0 provider: Okta, Microsoft Entra ID, Google Workspace, OneLogin, Ping.
  • Enforcement is per tenant: once SSO is required for your company, email and password sessions are rejected server-side, not just hidden in the UI.
  • Domain-verified email allow lists gate who can even start a session, before authentication happens.
  • Just-in-time provisioning creates the profile on first successful assertion and maps IdP groups to Aitelligent roles.
  • Deprovisioning in your IdP removes access at the next session check; refresh tokens for removed users stop working.

Tamper-evident audit logs

  • Append-only log of every cross-company admin action, written by the database, not the client.
  • Each entry stores actor, UTC timestamp, target company, target table, target record and a structured diff of the change.
  • Entries are chained with a SHA-256 hash of the previous record, so any deletion or edit breaks the chain and is detectable.
  • Exportable by platform admins for your own SIEM, evidence packs or auditor requests.
  • Separate immutable trails cover sync runs, CSQL handoffs, webhook deliveries and every email send.

Role-based access control

  • Roles live in a dedicated table, never on the user or profile record, which removes the classic privilege-escalation path.
  • Permission checks run through a security-definer database function, so a compromised browser session cannot grant itself a role.
  • Row-Level Security scopes every customer-facing table to the caller's company, and admin roles do not override tenant boundaries.
  • Export and download policies are set per tenant: restrict CSV and PDF export, or require watermarking.
  • Role changes are requestable and approvable in-product, and every approval lands in the audit log.

Customer-managed encryption keys (CMEK)

Standard encryption at rest protects the disk. CMEK goes further: the key that protects your most sensitive fields lives in your cloud account, under your control, with your audit trail. We use envelope encryption, so the master key never leaves your KMS.

1

You create the key

A master key (CMK) in your own AWS KMS, Google Cloud KMS or Azure Key Vault. It never leaves your account and we never hold its material.

2

You grant scoped access

A key policy that allows only our tenant-specific role to call encrypt and decrypt, conditioned on your tenant ID. Full CloudTrail or equivalent visibility on our usage stays with you.

3

We generate data keys

Sensitive fields are encrypted with a per-tenant data encryption key (DEK) using AES-256-GCM. The DEK itself is wrapped by your CMK and stored only in wrapped form.

4

Decrypt on demand

On a legitimate authenticated read, the server asks your KMS to unwrap the DEK, holds it in memory for a short cache window, then decrypts the field. Plaintext is never written to disk or logs.

5

You can revoke

Disable or delete the CMK, or remove our grant, and the wrapped DEKs become undecryptable. Access to the encrypted fields stops immediately, with no action needed from us.

Envelope encryption, in one line

your CMK (your KMS) → wraps per-tenant DEK → AES-256-GCM encrypts the field → ciphertext stored in our database

Encrypted with your CMK

  • Call and meeting transcripts
  • Email bodies captured from connected mailboxes
  • AI summaries and account briefs
  • Financial snapshots and revenue fields
  • Stored integration credentials

Not encrypted with your CMK

  • Row identifiers and tenant IDs
  • Timestamps and audit metadata
  • Aggregate counts used for health scoring
  • Anything required to enforce RLS

What CMEK does and does not give you

  • It gives you cryptographic revocation, an independent key audit trail, and a hard boundary between your data and any other tenant.
  • It does not hide data from a user you have authorised: authenticated reads in your own workspace decrypt normally, which is why SSO and role-based access sit alongside it.
  • CMEK is provisioned as part of Enterprise onboarding, with a dedicated tenant configuration rather than a self-serve toggle. Key ARN, rotation schedule and cache window are agreed in writing.

Ready to run a security review?

We will share the DPA, sub-processor register, questionnaire responses, the CMEK key policy template and an architecture walkthrough.

Contact usBook a demo