Security

This page summarizes the security mechanics built into the Dynamiq platform: credential storage, authorization, secrets management, sandbox isolation, and data deletion.

Credential storage

Dynamiq never stores API credentials in recoverable form:

• Access Keys and Personal Access Tokens are hashed with SHA-512 before storage. The database holds only the hash and a short preview (e.g. dynamiq_acc_XXX...XXX); the full secret is shown exactly once, at creation.
• Incoming requests are authenticated by hashing the presented bearer token and looking up the hash — the plaintext is never persisted.
• Expiration is enforced at authentication time: a credential past its expires_at is rejected on its next request.
• Revocation is immediate: deleting a key removes its hash, so the very next request with that secret fails.

See API Keys & Tokens for creation, scoping, and rotation guidance.

Authorization

Every management API request passes through a centralized authorization layer before any resource is returned:

• Resource checks walk the hierarchy. Fetching a Workflow, App, Knowledge Base, Connection, Dataset, Trace, or any other project resource first verifies access to its Project, which in turn verifies membership in its Organization. There are no side doors that skip the chain.
• Roles gate management. Organization-level management actions require the Owner or Admin role; the full matrix is in Members & Roles.
• System resources stay internal. Connections that are managed by the system, or scoped internally rather than created by you, are never readable through the user-facing API — requests for them are rejected outright.
• Personal resources stay personal. Chat conversations, their files, scheduled tasks, and Personal Access Tokens are accessible only to the user who owns them, regardless of org role.

Secrets management

Secrets stored in the database, such as Connection credentials, are encrypted with envelope encryption: each secret is encrypted with AES-256-GCM under a data key, and data keys are stored in the database only in wrapped form, encrypted by a master key held in AWS KMS. The master key never reaches the database, so a copy of the database alone decrypts nothing. Self-hosted installs can use AWS KMS or supply master keys through the service configuration.

Sandbox isolation

Code execution (for example, the agent's code-interpreter tooling) runs in E2B cloud sandboxes, isolated from the Dynamiq control plane and from other tenants' workloads:

• Every sandbox is tagged with the Dynamiq project it belongs to (dynamiq_project_id metadata) at creation.
• The sandbox APIs — listing sandboxes, fetching a sandbox, its logs and metrics, and deleting it — all verify that the caller has access to that project before returning anything. A sandbox without project metadata is not accessible at all.

Data deletion

Deletion cuts access immediately. A deleted organization or project is soft-deleted, and no background job permanently deletes it later:

• Deleting an organization immediately cancels its subscriptions, deletes all of its Access Keys, memberships, and invitations, and soft-deletes the organization — it stops resolving for every API call from that moment.
• Deleting a project soft-deletes it, which removes it from all listings and authorization checks at once. Its Apps, Workflows, Knowledge Bases, Connections, Datasets, and Prompts stay stored.

Reporting and compliance

For compliance documentation, penetration test reports, or to report a vulnerability, contact your Dynamiq representative or reach out through getdynamiq.ai.

Next steps