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

The platform includes a secrets manager built on HashiCorp Vault's transit encryption engine. Encrypt and decrypt operations are performed inside Vault against per-resource key paths, so encryption keys never leave Vault and never touch the application database.

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 is designed so that access is cut immediately and data is removed permanently after a retention window:

• 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. A background cleanup job later permanently deletes the project and everything in it — Apps, Workflows, Knowledge Bases, Connections, Datasets, Prompts, files, memories, evaluations, fine-tuning jobs, inference and database deployments, and the project's Access Keys — once the retention period has elapsed.

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