Security at Dexby
Dexby holds your customers’ credentials, so the design starts there: per-credential encryption, per-customer isolation, and a record of every access.
Each credential has its own key
Each stored credential has its own encryption key and is tied to the project, customer and connection it belongs to.
- Never written to disk or logs in readable form
- Deleted when the customer disconnects the account
- Opened only for the call that needs it
Checked on every call
Every request goes through these steps before it leaves Dexby.
- Agent asksFor one customer
- Find the actionSearch the catalog
- Check policyActions and data allowed
- Load the credentialAcme’s HubSpot token
- Call the APIapi.hubapi.com
- RedactPersonal data masked in logs
- RecordAudit chain + 1
- Stops here if the policy or scopes say no
An audit trail that shows tampering
Each record links to the previous record. Changing a record breaks the links that chain verification checks. Verify the chain from the dashboard.
- credential.readhubspot · john@acme.comprev 51ab…07c4hash 8f1c…2e9a
- tool.executehubspot_create_noteprev 8f1c…2e9ahash c09e…f311
- tool.executegoogle_calendar_create_eventprev c09e…f311hash 3d72…aa10
- connection.permissions_updatesupport inbox · adminprev 3d72…aa10hash 9e04…61bd
Other controls
Private networks blocked
Custom MCP servers and imported APIs must use public addresses. Dexby blocks private and cloud metadata addresses.
TLS everywhere
Dexby Cloud uses HTTPS. Outgoing webhooks include a signature your backend can verify.
Control payload retention
Request logs keep metadata by default. Payloads from personal-data actions require a separate opt-in. Health-data projects cannot store payloads.
Least privilege
Calls must pass session policy and the account’s permissions. Shared accounts start with no actions allowed.
Walled off per customer
Calls are scoped to your project and the customer’s connected accounts.
Responsible disclosure
Report issues to security@dexby.ai. Please do not disclose publicly before a fix.