Customer-managed encryption keys

All content Syntic stores is encrypted at rest. With customer-managed encryption keys (CMEK), the key that protects your organization’s stored content lives in your cloud key management service, not Syntic’s. Syntic asks your KMS to use the key each time it needs to read or write your data, and you can see every use in your own cloud logs. If you disable or delete the key, Syntic can no longer read that data.

What CMEK covers

CMEK protects content that Syntic stores. It does not change how requests are processed in memory.

Chat completions requests are not stored, so they need no key (see Data retention).

Supported key services

Use a symmetric encryption key located in the same geography as the workspace’s data region.

Step-by-step setup for each service: Google Cloud KMS, AWS KMS, Azure Key Vault.

How it works

Syntic uses envelope encryption. Each stored object is encrypted with its own data key; data keys are encrypted (“wrapped”) by your key in your KMS. Syntic keeps only wrapped data keys. To read an object, Syntic asks your KMS to unwrap its data key, uses it in memory, and discards it. Unwrapped data keys are cached in memory for at most 5 minutes to keep latency low.

Set it up

With the Admin API:

PUT /v1/organizations/encryption_key with provider (gcp, aws or azure), key_ref, optional workspace_ids (default all) and reencrypt_existing (default true). Owner role only.

curl -sS -X PUT https://app.syntic.ai/v1/organizations/encryption_key \
  -H "Authorization: Bearer $SYNTIC_ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -H "syntic-beta: admin-2026-11-01" \
  -d '{"provider": "gcp",
       "key_ref": "projects/acme-sec/locations/europe-west3/keyRings/syntic/cryptoKeys/content",
       "reencrypt_existing": true}'

const res = await fetch('https://app.syntic.ai/v1/organizations/encryption_key', {
  method: 'PUT',
  headers: {
    Authorization: `Bearer ${process.env.SYNTIC_ADMIN_KEY}`,
    'Content-Type': 'application/json',
    'syntic-beta': 'admin-2026-11-01',
  },
  body: JSON.stringify({
    provider: 'aws',
    key_ref: 'arn:aws:kms:eu-central-1:123456789012:key/1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d',
    reencrypt_existing: true,
  }),
})
console.log(await res.json())

import os, requests
 
r = requests.put(
    "https://app.syntic.ai/v1/organizations/encryption_key",
    headers={"Authorization": f"Bearer {os.environ['SYNTIC_ADMIN_KEY']}", "syntic-beta": "admin-2026-11-01"},
    json={
        "provider": "azure",
        "key_ref": "https://acme-kv.vault.azure.net/keys/syntic-content",
        "reencrypt_existing": True,
    },
)
print(r.json()["status"])

Response:

{
  "type": "encryption_key",
  "provider": "gcp",
  "key_ref": "projects/acme-sec/locations/europe-west3/keyRings/syntic/cryptoKeys/content",
  "status": "active",
  "verified_at": "2026-11-05T10:00:00Z",
  "reencryption": { "status": "running", "objects_total": 48211, "objects_done": 1200 }
}

status is verifying, active, unreachable (Syntic cannot use the key right now) or revoked (access denied by your KMS). GET /v1/organizations/encryption_key returns the same object.

If the key becomes unavailable

When your KMS refuses or cannot be reached:

• Features that need to read or write protected content fail with 503 overloaded, code encryption_key_unavailable (if unreachable), or 403 permission, code encryption_key_revoked (if access was denied). Chat completions keeps working because it stores nothing.
• Owners are emailed and a encryption_key.unavailable event is sent to your webhooks.
• Restoring access resumes normal operation; nothing is lost.
• Deleting the key in your KMS makes protected content permanently unreadable. Syntic cannot recover it. This can be used deliberately as crypto-shredding.

Limits

• One active key per organization, or one per workspace if you set workspace_ids.
• Each read of protected content may add a KMS call (cached for up to 5 minutes), which your cloud provider bills you for.
• Enterprise plans only.

Errors

Build notes for the platform team

• Extend the existing KMS helper to call customer keys through per-cloud adapters; keep the envelope format identical across providers.
• Store wrapped data keys next to each object; never persist unwrapped keys.
• Every unwrap is attributable in the customer’s KMS logs; add a request context string containing the object type and id.

Related

• Data retention
• Data residency
• Credential vaults