Skip to content

Security model

The parts of DXDT's security design that matter to integrators and security reviewers. Questions beyond this page: security@dxdt.ai.

Tenant isolation

  • Every API token is pinned to (user, tenant) at mint time. No request parameter can widen a token's tenant — attempts return 403. Tenant membership is verified server-side on every request.
  • All data — sessions, findings, incidents, graph, audit events — is tenant-scoped at the query layer.

API tokens

  • Format dxdt_ + 256 bits of URL-safe randomness; only a SHA-256 hash is stored. A leaked database cannot yield usable tokens.
  • Shown once at mint; revocation is immediate; optional expiry.
  • Minting requires an interactive browser session — a bearer token can never mint another token, so a leaked CI token can't self-propagate.
  • Invalid or revoked tokens are a hard 401 — there is no anonymous or fallback access path.
  • Mint and revoke events are written to the tenant audit trail.

Scopes and agent invocation

read-scoped tokens are restricted to safe (GET) endpoints and may not invoke the agent — agent runs can execute tools with side effects, so DXDT gates them on read_write rather than trusting HTTP method semantics.

Cost containment

Agent invocations are budgeted per token per UTC day server-side. A runaway cron job or CI loop hits 429, not your bill.

Sign-in and SSO

  • Browser sign-in via Google/Microsoft OAuth or per-tenant SAML 2.0 / OIDC SSO.
  • IdP client secrets are encrypted at rest and never returned by any API after write.
  • SSO just-in-time provisioning is seat-gated and domain-restricted.

Agent execution

  • Agent tool executions run tenant-scoped with per-tenant credentials; connectors are installed and authorized per tenant from the marketplace.
  • Agent runs are durable and auditable: every step and tool call in a run is recorded and replayable (dxdt attach, incident timelines).

Data handling

  • Findings carry their evidence — what was queried, when, and what came back — so results are verifiable rather than asserted.
  • Transport is TLS-only; tokens are accepted solely via the Authorization header (never query strings, so they don't land in logs).