Data Sovereignty

MeetLoyd separates control plane data (tenants, agents, teams, policies) from business data (memories, conversations, context graph, audit content). Control plane data lives on MeetLoyd's managed infrastructure. Business data goes wherever you tell us — including your own database or your own key management service.

There are three tiers. You can switch between them at any time, with online migration. No downtime, no re-provisioning.

Tier	Where business data lives	Who can read it	Plans
Standard	MeetLoyd platform DB, AES-256-GCM at rest	MeetLoyd (operationally), customer	All
CMEK	MeetLoyd platform DB, AES-256-GCM with your key	Only you — MeetLoyd has the ciphertext, not the key	All
BYOS	Your PostgreSQL + optional S3/GCS/Azure Blob	Only you — MeetLoyd never touches the data	Growth+

All tiers use TLS 1.3 in transit. All tiers honour the same control-plane audit trail.

What "business data" means

These columns/objects are subject to the data-plane tier:

• memories.content and memories.metadata — what an agent remembers
• messages.content and messages.metadata — conversation transcripts
• entities.name, entities.properties — extracted companies / people / deals in the context graph
• edges.properties — relations in the context graph
• audit_content.requestBody / responseBody — body of every LLM / tool call
• File attachments stored in object storage

These stay on the platform DB regardless of tier (no point encrypting them — they ARE the control plane):

• Tenant, agent, team, policy configuration
• Audit log metadata (who did what, when, against which resource — but not the body)
• Billing and subscription records
• Governance pack settings, OpenFGA tuples

The split exists so that operational telemetry, governance enforcement, and billing keep working even when you take your business data home.

CMEK — Customer-Managed Encryption Keys

CMEK encrypts business data columns with a key that you control. MeetLoyd holds the ciphertext; without your key, the rows are mathematically opaque.

Two key-management options:

1. MeetLoyd-managed master key — Generate a key in MeetLoyd. It's stored in the platform vault, encrypted under our Platform KEK. You see the hex once at generation time for offline backup; we never display it again. You can rotate or revoke at any time.

2. External KMS — Point MeetLoyd at your AWS KMS key, GCP Cloud KMS key, or Azure Key Vault. Runtime authentication uses cross-account federation (AWS AssumeRole / GCP Workload Identity / Azure AD app registration). MeetLoyd never stores your cloud credentials. Revoke MeetLoyd's federation in your IAM and we lose decrypt capability immediately.

What encryption guarantees

Property	What it means
Confidentiality	A snapshot of our DB is unreadable without your key
Authenticity	AES-256-GCM auth tag detects tampering — modified ciphertext fails to decrypt
Forward secrecy on revoke	After you revoke the key, future reads of past data fail. We cannot restore it
Per-record randomness	Each record uses a fresh IV — same plaintext encrypts to different ciphertext

What encryption does NOT guarantee

• Live agent memory — when an agent is actively running against your tenant, the in-memory working set is decrypted in our process so it can be reasoned about. Encryption protects data at rest, not data being actively processed by an agent you authorized.
• Embeddings — the vector embeddings used for semantic search stay cleartext because they're lossy projections you cannot reverse into the original text. If a vendor-side dump reveals embeddings, it does not reveal content — but it is information leakage in the cryptographic sense.
• Audit log metadata — we still log who-did-what-when. Encrypting metadata would break governance enforcement.

BYOS — Bring Your Own Storage

BYOS removes MeetLoyd from the data path entirely for business data. You provide:

• A PostgreSQL connection URL (RDS, Cloud SQL, Azure DB, on-prem — any PG ≥ 14)
• Optionally, an S3 / GCS / Azure Blob endpoint for files

MeetLoyd reads and writes through a storage abstraction. The platform DB keeps only pointers (tenant_id, resource_id, created_at) so audit and billing still function. The content lives entirely on your side.

BYOS includes a circuit breaker — three consecutive connection failures trip a 60-second cooldown where the agent reports "your storage is unreachable" rather than hammering your DB. Schema auto-provisions on first connection.

Growth+

BYOS requires Growth or Enterprise. CMEK is included on every plan, including Starter.

Configure it

The data-plane page lives in your dashboard at Settings → Data Protection.

Generate a MeetLoyd-managed CMEK key

1. Go to Settings → Data Protection.
2. Click Generate Key. A backup modal appears with your key in hex.
3. Copy the key and store it in your password manager or HSM now. This is the only time it's displayed.
4. Check "I have saved this key in a secure location" and close the modal.
5. Click Activate CMEK. New business data is now encrypted with your key.

Migrate existing data into CMEK

After Activate CMEK, only new business data is encrypted. To re-encrypt existing rows:

1. From Settings → Data Protection, scroll to Data Migration.
2. Click Start Migration, select target tier cmek.
3. The migration runs in the background. Progress is shown per table (memories, messages, entities, edges, audit). No downtime.

Configure external KMS

1. Go to Settings → Data Protection.
2. Click Use Your Own Key / KMS (or Switch Provider if a key already exists).
3. Pick the right tab:
   • AWS KMS — paste your KMS Key ARN and region (e.g. arn:aws:kms:us-east-1:123456789012:key/abcd-...).
   • GCP Cloud KMS — paste the full key resource name (projects/.../cryptoKeys/...).
   • Azure Key Vault — paste vaultUrl#keyName (e.g. https://acme.vault.azure.net#meetloyd-master).
4. Click Save Configuration. The configuration persists immediately.
5. If your cloud federation is operational, the status switches to Active. Otherwise it shows Pending federation until the federated identity grant is in place — your business data continues to be readable in the meantime via the platform-managed path, and switches to KMS-protected automatically on activation.

Set up the IAM federation

For external KMS to be active, the customer-side IAM grant must let MeetLoyd's federated identity perform Decrypt / Unwrap operations on your key:

Provider	What to grant	Principal
AWS KMS	kms:Decrypt, kms:Encrypt, kms:GenerateDataKey on the KMS key	MeetLoyd's IAM role ARN (provided by support)
GCP Cloud KMS	cloudkms.cryptoKeyEncrypterDecrypter on the key	MeetLoyd's Workload Identity service account
Azure Key Vault	Key Vault Crypto User role on the key	MeetLoyd's AD app registration (provided by support)

Contact your account team for the exact principal identifiers and a step-by-step grant procedure tailored to your cloud.

Rotate a CMEK key

1. Settings → Data Protection → Rotate Key.
2. The new key is generated and stored. Existing data must be re-encrypted via the Start Migration action before the old key can be safely retired.

Revoke a CMEK key

Irreversible

Revoking a key permanently destroys it. Any data encrypted under that key becomes mathematically unreadable. Always export or re-encrypt first if you need that data back.

1. Settings → Data Protection → Revoke Key.
2. Confirm by typing the explicit phrase. The key is shredded from the vault.
3. Your tier resets to Standard. New writes go to the standard data plane.

Switch back to platform-managed

If you no longer want external KMS:

1. Settings → Data Protection → Switch Provider.
2. Cancel the active provider, or click the explicit Remove KMS action.
3. The platform falls back to the local-managed master key (if one exists) or the standard tier.

Configure BYOS

1. Go to Settings → Data Protection → Configure BYOS.
2. Paste your PostgreSQL URL (postgresql://user:pass@host:5432/database).
3. Click Test Connection — we run a SELECT version() to verify reachability and credentials.
4. Click Activate BYOS. The schema auto-provisions on first write; existing data can be migrated via Start Migration → byos.

Audit trail

Every key operation is recorded in the immutable audit log:

Event	Recorded
Key generated	dataPlane.cmek.keyGenerated + key ID
Key imported	dataPlane.cmek.keyImported + provider
Key rotated	dataPlane.cmek.keyRotated + old/new key ID
Key revoked	dataPlane.cmek.keyRevoked
KMS configured	dataPlane.kms.configured + provider, keyRef, activation state
Tier changed	dataPlane.tier old → new
Migration started	dataPlane.migration + job ID

Audit log content is itself subject to the data plane tier — under CMEK, the request/response bodies in the audit log are encrypted with your key.

Plan matrix

Capability	Starter	Growth	Enterprise
Standard tier	✅	✅	✅
CMEK (MeetLoyd-managed key)	✅	✅	✅
CMEK key rotation / revocation	✅	✅	✅
External KMS (AWS / GCP / Azure)	configurable	configurable	activated
BYOS PostgreSQL	—	✅	✅
BYOS object storage (S3 / GCS / Blob)	—	✅	✅
Online migration between tiers	✅	✅	✅
Air-gapped on-prem deployment	—	—	✅

External KMS configuration is captured on all tiers; cloud federation grants are typically negotiated as part of enterprise onboarding. If you're on Starter or Growth and need an active cloud-KMS federation, contact your account team.

Frequently asked questions

Does enabling CMEK slow agents down? Marginally. The decrypt happens at row fetch, AES-256-GCM is hardware-accelerated, and we cache derived keys in-process for 5 minutes. Typical overhead is under 2% on read-heavy workloads.

What happens if I lose my master key? If you generated it through MeetLoyd, we still hold the encrypted copy under our Platform KEK — you can read your data. If you used an external KMS and your KMS forgets the key, your data is unrecoverable. Always have a recovery procedure for keys held outside MeetLoyd.

Can MeetLoyd see my data in transit while running an agent? While the agent is running, yes — that's what the agent is doing. After the agent stops, the at-rest encryption resumes. If you don't want any MeetLoyd-side decryption ever, look at BYOS or the on-prem deployment.

Are embeddings encrypted under CMEK? No. Embeddings are cleartext because they support semantic search. They're lossy projections you cannot reverse into source text, but a leaked embedding does reveal "this row was about topic X" semantically.

How do I prove to my auditor that CMEK is active for my tenant? The data-protection page shows the current tier + key fingerprint. The audit log records every tier change with timestamp + actor. We can export a signed attestation on request.

---

Next: Configure Governance Packs to add automated compliance enforcement on top of your chosen data-plane tier.