Security

Our approach

Security in enque.ai is a set of rules the code enforces, not a page of promises. The rules are short: seal every secret, scope every query, record every action, hold no key we do not need, and fail closed rather than fall back. This page describes what that means in practice.

One deployment, one agency

Every agency runs its own deployment with its own database. There is no shared tenant table, no tenant header and no cross-agency query to get wrong. Joining a deployment is invite-only: the first user of an empty deployment becomes its admin, and every later user arrives through an email-bound, signed invitation that names a role.

Inside a deployment, every client is a project, and every read, update and delete on client data is filtered by project in the data layer. The filter is applied by the framework, not remembered by each developer.

Encryption

• In transit. Every connection uses TLS, terminated at the ingress with certificates from Let's Encrypt. Plain HTTP redirects to HTTPS. The product can sit behind Cloudflare for an additional edge layer.
• At rest. Credentials your agency connects are stored only as AES-256-GCM encrypted envelopes under a master key. There is no plaintext column and no environment-variable fallback: if the master key is missing, the service refuses to start. Data keys are wrapped by the master key and can be rotated; the previous key is kept so sealed values stay readable through a rotation.
• Passwords are stored as salted PBKDF2-SHA256 hashes, never reversibly.
• Sign-in tokens are HMAC-SHA256 signed, carry an expiry of 7 days, and are checked on every request against a live account. A deleted account's token stops working at once.

No keys we do not need

enque.ai holds no AI model key. Agents run on the agency OS against the providers your agency configures. A tool key your agency pastes is forwarded to the agency OS and sealed there; a connected account's OAuth token lives on the OS and never passes through enque. What enque stores is the fact that a credential exists and which client uses it, never the secret.

Credentials never appear in logs, API responses or pages. Credential endpoints return metadata only.

No silent fallbacks

A missing credential, provider or configuration fails loudly with a response that names what is missing. Nothing substitutes a default key, a default identity or a default route. A removed or disabled credential stops the work that depended on it rather than quietly switching to another one.

Every action is recorded

Every agent run writes a ledger row before its result is applied: who started it, which agent, on which surface and subject, when, the provider's usage, and any error verbatim. Every human decision that changes state records the actor, the timestamp and the exact payload, in the same transaction as the effect. Credential changes, agent actions on records and admin operations are each an audit row. Your agency can see what was done in its name, and prove it.

Access control

Authorisation is decided by the caller's identity, never by which URL they reached. The identities are signed-in members, admins, and the agency OS acting through the runner as the member who started a run. Platform controls such as mail, invitations and members are admin-only. An unregistered path is a real 404.

Application hardening

• Every dynamic table or column name in SQL passes an allowlist; every value is parameterised.
• The browser app loads its fonts from itself and includes no third-party tracking script.
• Embedded previews of HTML content render in a sandboxed frame with no access to the sign-in token, the parent page, cookies or storage.
• The source tree is scanned for committed secrets with gitleaks; every environment file is ignored by version control, and only examples are tracked.
• The one vendored dependency, the agency OS SDK, is pinned to a recorded version and never edited in place.

Infrastructure

The stack runs as three containers, the API, the web app and PostgreSQL, behind the platform's ingress. No host port is published by the application; only the ingress listens on 80 and 443. Production images carry no source mounts, and memory limits and restart policies apply. Hosting runs in INDIA; a dedicated or on-premises deployment runs where your agency chooses.

Backups of the database are taken nightly and kept for 14 days on an access-controlled host. The restore procedure is part of the deployment runbook.

The agency OS

Agents, tools, skills, files and knowledge run on the agency OS at core.enque.ai, operated by us. enque calls the OS through a signed developer key configured at deployment; the OS never calls into enque. Which tools an agent may use is set per agent, on the OS, by the agency owner, and a run carries only the credentials the client in question has chosen.

Compliance

We align our practices with the GDPR, the UK GDPR, the CCPA and India's Digital Personal Data Protection Act, 2023, and we offer a Data Processing Agreement on request. We do not hold a third-party certification such as SOC 2 or ISO 27001 today, and we will say so until we do. Agencies with compliance-sensitive clients can run a dedicated or on-premises deployment so their data never leaves infrastructure they control.

Responsible disclosure

If you find a vulnerability, write to info@digimaxx.co with enough detail to reproduce it. We acknowledge within 3 business days, keep you informed, and ask for 90 days to fix before public disclosure. Please do not access data that is not yours, degrade the service, or run automated scanning against production. We will not pursue good-faith research that follows these rules.