Encryption | Keva Docs

Keva's shared local encryption helper uses AES-256-GCM for selected application credential envelopes. This is a source-level control, not proof that every stored field, provider-managed store, backup, or deployed environment has the same encryption boundary.

Current Local Control

For callers using the shared helper, each encryption operation uses:

a 256-bit key
a fresh 96-bit (12-byte) initialization vector
a 128-bit authentication tag
a key-version marker

The resulting envelope stores Base64-encoded ciphertext, IV, and authentication tag. Current credential-bearing paths include selected platform connector credentials, email-account passwords, API-key ciphertext, webhook or notification secrets, site connector tokens, and encrypted platform settings.

This list is not a complete encrypted-store inventory. Ordinary ticket, message, customer, analytics, and other application fields are outside this application-level encryption claim. Hosting-provider storage, attachments, backups, secret-manager ownership, configured key validity, deployment, and product behavior require independent verification.

Key Handling and Rotation

ENCRYPTION_KEY is the current local encryption key. When configured, ENCRYPTION_KEY_PREVIOUS lets the runtime attempt fallback decryption of older envelopes.

Fallback decryption is not completed key rotation. The registered global credential re-encryption function is intentionally suspended and returns a skipped result before secret or database access. Re-encryption remains unavailable until Keva has:

configured-record reconciliation against the complete static schema manifest
durable key identity for every manifest entry
explicit disposition of credential-like fields outside the envelope convention
resumable and idempotent per-target outcomes
redacted durable failure and audit evidence
independent old-key and new-key read-back
rollback and recovery proof before previous-key removal
deployment ordering and old-runtime quiescence

Keva therefore does not currently claim automated or zero-downtime global key rotation.

Runtime Plaintext Boundary

Credentials must be decrypted to ordinary JavaScript strings when an admitted operation needs them. Parsed encryption-key buffers are cached by the current helper, and deterministic memory zeroing is not implemented or claimed.

Selected route and audit designs avoid returning credential envelopes and use secret-free metadata. Those controls do not establish a whole-application guarantee that plaintext or credentials can never appear in every log, error, provider, runtime, or historical record.

Credential-Access Evidence

Selected platform-action and Copilot paths attempt a content-minimized connector.credentials_accessed audit event. The shared helper uses best-effort persistence for these calls, and many other decrypt callers do not emit the same event.

Credential-access audit coverage is therefore not universal or fail-closed. Configured reconciliation, deployment, alert delivery, retention, export, and product proof remain open.

What Administrators Should Do

Restrict access to deployment encryption keys.
Treat key replacement as a supervised operation, not an automated runbook.
Do not dispatch the suspended re-encryption event.
Rotate provider credentials at the provider when compromise is suspected.
Review current application-readiness evidence before making compliance claims.
Independently verify the exact configured store, environment, and read-back for any security assurance.

Decryption Failures

If a credential envelope cannot be decrypted:

confirm the expected deployment environment
verify the current and, if applicable, previous key configuration without exposing either key
preserve the affected envelope and categorical failure evidence
avoid deleting a previous key or rerunning a partial rotation
escalate for supervised reconciliation

Do not treat successful local encryption, a build, or a skipped rotation handler as configured storage, deployment, rotation, audit, or product proof.