Data Security & Encryption

This page describes how HQ classifies, encrypts, controls, retains, and deletes data.

Data classification

Class	Examples	Handling
Customer content	Knowledge documents, project specs, skills, policies a team syncs to HQ.	Stored in a per-tenant bucket, encrypted at rest (see below).
Customer metadata	Organization/membership records, file paths, access-control entries.	Stored in control-plane databases, encrypted at rest.
Operational/audit data	Credential-issuance records, administrative actions, access logs.	Stored in audit stores; integrity-protected.
Secrets	API keys, OAuth credentials, signing keys.	Stored in AWS SSM Parameter Store (SecureString) or AWS Secrets Manager; never in source control.
Local-only (never synced)	Credentials directories, raw datasets, prompt libraries on a customer machine.	Excluded from cloud sync by default.

Where data lives

HQ’s primary stores are in AWS, region us-east-1 (United States). HQ does not replicate these stores to other regions. Some subprocessors process data in other locations, and AI requests through Bedrock cross-region inference may be processed in other AWS regions; see Subprocessors. Primary stores:

• Amazon S3 — customer content, in a dedicated per-tenant bucket.
• Amazon DynamoDB — access-control lists, organization/membership/entity metadata, audit records, and short-lived nonce records for single-use tokens.
• Managed PostgreSQL — used by specific feature services (for example, the e-signature/agreements service and the static-artifact deployment service). Where these hold personal data (e.g., signer name/email/IP for an executed agreement), it is treated as customer metadata and protected accordingly.

Encryption at rest

• Customer content (S3), new vaults: server-side encryption with AWS KMS (SSE-KMS) using a dedicated customer-managed key (CMK) for the vault. S3 Bucket Keys are enabled to reduce KMS request overhead.
• Customer content (S3), some existing vaults: a shared Indigo-managed KMS key, or S3-managed encryption (SSE-S3, AES-256), until the vault is re-keyed.
• Key rotation: vault CMKs and the shared vault key rotate automatically on an annual cycle.
• Control-plane databases: access-control and entity tables are encrypted with AWS KMS; primary tables additionally have point-in-time recovery enabled.

Honest note

We are standardizing KMS-CMK encryption and point-in-time recovery uniformly across all secondary metadata/audit tables (a small number currently use the AWS-owned default key); this hardening is tracked on the roadmap.

Encryption in transit

• TLS/HTTPS is enforced for all client-to-cloud and service-to-service communication.
• Customer storage buckets carry a policy that explicitly denies any request not using TLS (aws:SecureTransport).
• Static-artifact delivery is served only through Amazon CloudFront using Origin Access Control, with Secure; HttpOnly; SameSite access cookies where applicable.

Honest note

A minimum TLS version (e.g., TLS 1.2+) is not yet pinned uniformly in code across every edge/API surface; standardizing this floor is on the roadmap.

Key management

• Per-vault CMKs are created when a new vault is provisioned, tagged so that IAM can gate KMS operations on the tag, and used as the bucket’s default encryption key. Existing vaults keep their current key until a separate re-keying migration moves them.
• A separate, dedicated key protects control-plane databases.
• A dedicated symmetric master key (held in AWS Secrets Manager) protects HQ’s capability tokens. This key is environment-scoped; isolating it further per-tenant is noted on the roadmap.
• The control-plane key and the shared vault key are protected against accidental deletion in infrastructure code, and the shared vault key’s policy denies key deletion and disabling to every principal except the account root.

Secrets management

• Customer secrets managed through HQ Secrets are stored as AWS SSM Parameter Store SecureString parameters, encrypted with the AWS-managed SSM key (aws/ssm), not a per-tenant key.
• Application secrets are stored in AWS SSM Parameter Store (SecureString) and AWS Secrets Manager, injected at deploy time or read at runtime.
• In the primary application, secret values are bound at deployment and the runtime roles are not granted broad ssm:GetParameter, reducing runtime exposure.
• Human-held secrets (the source of truth for credentials) live in HQ Secrets, HQ’s own encrypted secrets-management system; credentials are referenced, never pasted inline or committed.
• No plaintext secrets are stored in source control.

Access control and audit

• Read/write access to customer content is governed by the ACL model and brokered through scoped, short-lived credentials described in Tenant Isolation.
• AWS CloudTrail records AWS management events, with log-file validation enabled for tamper-evidence. CloudTrail data events on vault buckets were turned off on 2026-09-24.
• S3 server access logs are configured on person and company vault buckets and loaded into ClickHouse. AWS delivers these logs on a best-effort basis (records can arrive hours late and a small fraction may not arrive), so they support investigation but are not a complete audit record.
• An application audit trail records every credential issuance (which principal, which scope) and every administrative/impersonation action.
• The e-signature service additionally maintains a hash-chained audit log for executed agreements.

Data minimization on the client

HQ runs locally on customer machines and is deliberately conservative about what leaves them. The following are excluded from cloud sync by default (the “privacy class”):

• Credential/settings directories (OAuth tokens, vault references).
• Raw company datasets.
• Worker/prompt libraries.
• Version-control internals.

A first-push protection check runs before an organization’s first upload and blocks the upload if any excluded path would be transmitted, surfacing the offending path to the user.

Capability-based sharing tokens

When data is shared, HQ mints a capability token rather than widening storage permissions:

• Vault share-session links: AES-256-GCM authenticated encryption (random IV, authentication tag). The token is single-use — redemption atomically consumes a one-time nonce — time-limited (15 minutes by default; minimum 60 seconds, maximum 7 days), and pinned to specific paths and a maximum permission level (capped at write; admin is never shareable). Tampered or expired tokens are rejected.
• Shared static-artifact links: high-entropy random tokens stored only as SHA-256 hashes (so a database export cannot redeem them), single-use, default/maximum 7-day lifetime, and IP-rate-limited on redemption. Optional password protection hashes passwords with Argon2id and is enforced at the CDN edge via a short-lived signed cookie.
• Upload links: pre-signed S3 upload URLs are short-lived (10 minutes), size-capped, and force the destination key into the authenticated caller’s namespace so a client cannot redirect an upload into another tenant’s space.

Retention and deletion

• Retention: customer content is retained for the life of the account. Time-to-live expiry is applied to ephemeral records such as one-time-use nonces and certain audit/event records.
• Deletion on request: customers may request export and deletion of their data. A self-scoped hard-delete routine exists that empties and removes a bucket and tombstones the associated identity.
• Self-service account deletion: a self-service flow is built that removes the user’s personal data, signs them out of all sessions, and schedules companies where they are the only member for purge after 30 days. It is off by default and is enabled by Indigo through a feature flag; until it is enabled for an account, deletion is handled on request. Copies outside HQ (support and feedback items in Slack and Linear, and Sentry error data) are not removed by this flow and are erased by hand on request.

Honest note

Production tenant offboarding today performs a soft tombstone of the organization; a fully automated hard-delete-on-offboarding routine (destroying bucket, per-tenant key, and metadata) is being productionized and is tracked on the roadmap. Until then, complete deletion is performed as an operational procedure on request.