Security
How Dexby encrypts credentials, classifies data, audits access and erases data.
Dexby stores credentials for your users' connected accounts and uses those accounts for tool calls. This page describes the controls in the code today. Controls that are designed but not built are labelled Planned.
Encryption
Every credential belongs to one scope: organization, project, user and connection. The organization
and project come from the API key or dashboard session, never from the request body, so two projects
with a user_123 never share a credential.
| Control | Behavior |
|---|---|
| Envelope encryption | AWS Encryption SDK. A fresh data key per write, wrapped by the keyring. Key commitment required. |
| Encryption context | Binds the ciphertext to its scope and revision, so a copied or replayed record fails to decrypt. |
| Storage | DynamoDB on AWS, PostgreSQL elsewhere. The store holds ciphertext only. |
| Use | Decrypted only for the request that needs it, placed on that one request, then discarded. |
| OAuth refresh | Tokens near expiry are refreshed by one caller under a lease, and every refresh is audited. A provider 401 forces one refresh and one retry. A refused refresh (invalid_grant), or a 401 right after a successful refresh, marks the connection revoked; any other failed refresh marks it reauth_required. Calls then fail with REAUTH_REQUIRED. |
Dexby Cloud wraps every data key with AWS KMS.
The same service encrypts project OAuth client secrets, webhook signing secrets and trigger secrets.
Key handling
| Secret | Stored as |
|---|---|
API keys (dx_...) | SHA-256 hash. Shown once at creation. |
| Webhook signing secrets | Encrypted. Shown once. |
| OAuth client secrets | Encrypted. Never shown again. |
| Connect link and trigger URL tokens, OAuth state | SHA-256 hash. |
Credentials never appear in logs, audit records, error messages or API responses. Tool and proxy errors never include the request URL, which could contain a key. Revoked API keys stop working at once. See Project settings.
Data classification
The dashboard shows these classes as General, Personal data and Health data.
| Class | Examples |
|---|---|
standard | Weather, public search results, ids, timestamps |
pii | Names, emails, phone numbers, messages, account handles |
phi | Patient records, diagnoses, prescriptions, vitals |
| Tool source | Class |
|---|---|
| Catalog connectors | dataClassification in the spec. |
| Unclassified tools | pii. |
| MCP servers you add | pii, since a remote server declares none. |
| Imported REST APIs | Chosen per operation at import. |
phi tools exist only in a project that handles health data; in any
other project they are neither listed nor callable. Sessions also take a data class
ceiling (default phi); tools above it are neither listed nor callable in that session. A class is a label and a filter; it does not encrypt
or redact data by itself. Request logs can store tool inputs and outputs when Details and payloads
is enabled: standard payloads are eligible, and pii payloads also require Include personal data.
phi payloads are never stored. Audit records never contain tool inputs or outputs. See
Request logs.
Planned: per-property classification of tool input and schema-aware redaction in telemetry.
Audit trail
Every credential write, read through the proxy, rotation and deletion, every tool run, and every change to keys, members, auth configs, connections, MCP servers and endpoints, imports, webhooks, triggers and Connect settings writes an audit record. Records hold ids, names and counts, never tool input, output or secrets.
- Each organization has one SHA-256 hash chain. Each record commits to the previous hash, so an edit, deletion or reordering breaks every later hash.
- The table rejects
UPDATEandDELETE. - Verify the chain with
GET /api/dashboard/projects/:projectId/audit/verify(see Project settings).
Limits: a failed audit write is logged but does not fail its action. A chain cannot detect removal of its most recent records.
Planned: a write-once copy of the audit log (S3 Object Lock) on Dexby Cloud.
Erasure
Credentials are erased first. If one cannot be erased, the request fails with
503 CREDENTIAL_UNAVAILABLE and nothing is removed.
| Request | Removes |
|---|---|
| Erase a user (Operate → Users) | Triggers, credentials, connections, sessions, stored results, stored payloads. User id removed from request logs. |
| Delete a project (Configure → Settings) | Every credential and secret, uploads, then the project and everything in it. |
DELETE /v1/connections/:id | The connection's triggers, credential and row. |
| Data | Kept |
|---|---|
| Credentials | Until the connection, user or project is removed. |
| Sessions, stored results | Until they expire. |
| Webhook deliveries | 30 days after they finish. |
| Request logs | 30 days, or not at all when the project's request logs are Nothing (Project settings). |
| Request payloads | 7 days with Details and payloads. Excludes health data tools. Recognized credential fields in JSON and query parameters are stripped. |
| Usage counts | Per project and hour: counts and byte totals only, no user ids. Until the project is deleted. |
| Audit records | Not deleted, so the chain stays verifiable. |
Planned: crypto-shredding with per-organization keys, so erasure also reaches backups, and a retention schedule for audit records.
Network safety
Every customer-supplied URL (MCP servers, REST API base URLs, webhook endpoints, credential hosts,
auth config hosts, logo URLs) must be public https: no localhost, .local or .internal names,
and no loopback, private, link-local (including 169.254.169.254), CGNAT, multicast or reserved
addresses. Connector requests refuse redirects, so a credential never follows one to another host.
Compliance posture
Dexby is designed to support SOC 2 Type II, HIPAA, GDPR and CCPA requirements. It holds no SOC 2 report, HIPAA attestation or other certification. This is engineering intent, not an audit result or legal advice.
| Framework | Designed-for controls |
|---|---|
| SOC 2 Type II | Access control by role, tamper-evident audit trail, change history. |
| HIPAA | Encryption at rest, TLS in transit, phi classification, health data switch and session ceilings, audit of access. |
| GDPR | Right to erasure, data minimization in logs. |
| CCPA / CPRA | Deletion requests per user. |
Business associate agreements, data processing agreements and subprocessor lists are outside the code.