Security and Compliance

How ScaiVault protects the credentials you store in it. The short version: every secret is encrypted at rest with a per-row data key, wrapped by a root key that lives in a KMS or HSM. Plaintext exists in process memory for the duration of a request and nowhere else.

This page is for security engineers, auditors, and anyone evaluating ScaiVault for a sensitive workload.

Encryption at rest#

Envelope encryption with per-row data keys. Every secret version is encrypted with a unique AES-256-GCM key (the data key). The data key is itself encrypted with the tenant's envelope key, which is encrypted with the partner master key, which is encrypted with the root key. The root key never leaves the KMS in plaintext.

The chain means a single compromised key affects a bounded blast radius: a stolen data key reveals one secret, a stolen tenant key reveals one tenant's secrets, etc. The root key is the only single point of failure, and it's the one ScaiVault never sees in plaintext.

Decryption walks the chain backward at request time. KMS round-trips happen once per request (the root → partner step) — subsequent unwraps are local. Latency under 5ms in most regions.

Supported KMS / HSM backends#

The root key never leaves the KMS — even ScaiVault operators with database access can't decrypt secrets without KMS access too. Compromising the database is necessary but not sufficient.

Encryption in transit#

• Client → API: TLS 1.2 minimum, TLS 1.3 preferred. HSTS with a 1-year max-age. Modern ciphers (ECDHE + AES-GCM or ChaCha20-Poly1305); RSA key exchange disabled.
• API → PostgreSQL: TLS required. Certificate verification on.
• API → Redis: TLS supported (rediss://). Used by default in managed deployment.
• API → KMS: Provider SDKs with their default TLS posture. Auth via IAM role / workload identity, not static keys.
• API → ScaiKey: TLS, JWT-validated. Inbound webhooks from ScaiKey HMAC-verified.
• API → federated backends: TLS to all of HashiCorp Vault, AWS SM, Azure KV, GCP SM, ACME providers.

Optional client mTLS for service-to-service: configure TLS_CLIENT_CA_FILE on the API and require certs from your internal PKI.

Authentication and authorization#

• Tokens: JWTs minted by ScaiKey. ScaiVault validates signatures against ScaiKey's JWKS, refreshed on a cache TTL.
• Token lifetimes: 1 hour for access tokens. Refresh via OAuth client-credentials or refresh-token flow. Personal access tokens up to 90 days (configurable per token).
• Workload identity: OIDC token exchange for Kubernetes, AWS IAM, GCP service accounts, GitHub Actions. No long-lived secret material on the workload side.
• MFA enforcement: policy rules can require recent MFA (require_mfa: true). The token's mfa_verified_at claim must be within the configured window (default 15 minutes). MFA delegated to ScaiKey.
• Policy evaluation: path-pattern rules with IP / time / MFA conditions. Every read or write is policy-checked at request time. See Policies and Permissions.

Audit logging#

Every read, write, delete, rotation, policy change, certificate issuance, dynamic credential generation, and federation sync is recorded. Audit entries include:

• Identity (user, service account, or system).
• Resource path.
• Action and outcome.
• Source IP.
• User agent.
• Request ID.
• Duration.
• Failure code if applicable.

Audit logs are append-only and stored in PostgreSQL with optional asynchronous export to S3 / GCS / Azure Blob for long-term retention. Default retention: 7 years.

Audit log access is itself audited — calls to /v1/audit/* show up in the audit log of an admin who has audit-read access.

Multi-tenancy isolation#

• Every row in every table is tagged with tenant_id. Queries are scoped at the API layer; the database doesn't trust the API layer's claim — application-level row checks and PostgreSQL row-level security policies both enforce.
• Cross-tenant access requires partner-admin role and explicit /v1/t/{tenant_id}/ prefix. Audit logs both the acting identity and the target tenant.
• Encryption keys are tenant-scoped. A compromised tenant key reveals one tenant's data, not the platform.
• Rate limits are per-identity, not per-tenant — one tenant's traffic doesn't shape another's.

Key rotation#

• Root key rotation: in-place via the KMS's rotation primitive. ScaiVault re-wraps partner keys against the new root version; existing data ciphertexts don't need to be rewritten. Recommended cadence: annual.
• Partner / tenant key rotation: triggered manually or on a schedule. Re-wraps the tenant's data keys; secret ciphertexts unchanged.
• TLS certificate rotation: handled by your ingress/LB or by ScaiVault's ACME integration.
• Service-account credential rotation: ScaiKey controls this; rotation cadence configurable per service account.

Backups and recovery#

• Database: standard PostgreSQL backup model — full snapshot plus WAL. Encrypted at rest by the backup provider.
• KMS root key: depends on provider. AWS KMS / GCP KMS: cross-region replication. Azure Key Vault: geo-redundancy. HashiCorp Vault Transit: rely on Vault's own DR. PKCS#11 HSM: vendor-specific backup (Thales has cloning, YubiHSM has wrap-key export). TPM 2.0: hardware-locked; back up the wrapping blob.
• Recovery test cadence: annually at minimum. Verify a secret-read works against a restored stack with a separately-recovered KMS material.

Threat model#

What ScaiVault is designed to defend against:

• Database compromise alone. Adversary with arbitrary DB read can't decrypt secrets without KMS access. They can read metadata (paths, tags, timestamps) but no secret values.
• Compromised application server access. A read-only foothold on one API pod can decrypt the requests in flight on that pod but can't bulk-extract. Audit log captures the foothold's activity.
• Stolen access token. Limited by the token's scopes, the bound identity's policies, the token TTL (1h), and the rate limits. Rotated tokens revoke immediately on the next JWKS refresh (~5 min).
• Insider with admin role. They can do administrative things (create policies, rotate secrets) — but every action is in the audit log against their identity.

What ScaiVault is NOT designed to defend against:

• Compromised KMS. If the adversary owns the KMS, they own the root key. ScaiVault's encryption is a wrapper; the wrapper assumes KMS integrity.
• Compromised host of a federation backend. If a federated HashiCorp Vault is owned, ScaiVault proxies will return whatever the adversary writes there. Federation extends but doesn't multiply security.
• Side-channel attacks on the host running ScaiVault. No formal defense against speculative-execution side channels, timing, EM emanations. Run on appropriate hardware for your threat model.

Compliance posture#

ScaiVault is a building block; compliance is properties of deployments. The managed scaivault.scailabs.ai service holds:

• SOC 2 Type II
• ISO 27001
• HIPAA-eligible (BAA available for healthcare deployments)
• GDPR data-processing-addendum available

For FedRAMP, FIPS 140-2 Level 3, or air-gapped deployments, the self-hosted distribution with appropriate KMS backend (PKCS#11 HSM with FIPS-validated firmware) supports the underlying requirements; certification is per-deployment.

Audit trail and key-handling are designed to satisfy:

• PCI DSS requirement 3 (protect cardholder data) when storing payment-processor credentials.
• HIPAA §164.312(a)(2)(iv) (encryption at rest and in transit).
• NIST SP 800-57 key-management guidance.

Per-control mappings are available on request — contact your account team.

Vulnerability disclosure#

Report security issues to security@scailabs.ai. PGP key fingerprint at scailabs.ai/security.txt. 90-day disclosure timeline by default; we coordinate on extensions for issues that need them.

What's next#

• Architecture — how the encryption and request flow fit together.
• Deployment — KMS configuration.
• Policies and Permissions — how access controls work in detail.