Dexby
Request access

Agents act as the user

Not as a shared admin key. Dexby resolves a per-user credential at execution time, keeps it encrypted at rest, classifies what passes through it, and leaves an audit record behind. The same runtime runs in our cloud or inside your VPC.

Self-hosted needs no approval · Apache-2.0 connectors · No card

Scoped

Credentials belong to a user

Every execution carries a user identity. The runtime resolves that user’s credential at call time, or the call fails. One compromised session cannot reach another user’s data.

Encrypted

Secrets are never at rest in the clear

Envelope encryption with AWS KMS in cloud, local keyrings when you self-host. Plaintext exists in memory for the length of one call and is never written to a log or a column.

Accountable

Every payload is classified

Tool inputs and outputs are tagged standard, PII, or PHI in the schema itself. Telemetry is redacted before it is written, so an agent cannot leak a record into your logging vendor.

The problem

Connecting an agent to a real API is an access control problem wearing an integration costume

Calling an API from a model is a weekend of work. Doing it on behalf of thousands of distinct users, with revocation, rotation, redaction, and a record of who did what, is the part that stalls the launch. Teams discover this after the demo, when security reviews the design.

What ships without an access layer
  • A shared bot token in an environment variable, so every user’s agent quietly holds every user’s access
  • OAuth refresh and revocation logic copied into three services, each drifting from the others
  • Tokens in a plaintext column because encryption was scheduled for after the launch
  • No answer when an auditor asks which agent read which record, and on whose behalf
Sources

Any MCP server today. Any REST API next.

Every source gets the same treatment: credentials per user, encrypted at rest, and every call on the audit chain.

Available

Built-in connectors

15 typed connectors with classified tool schemas, maintained with the runtime.

  • Per-user OAuth, API key and client credentials
  • Tokens renewed automatically
  • Unmodelled endpoints through the proxy
Available

Any MCP server

Register a remote MCP server by URL. It appears in the catalog beside the built-in connectors, and each user connects their own account.

  • Streamable HTTP, and legacy HTTP+SSE
  • API key or OAuth, stored per user
  • Changed tool definitions are flagged for review
Coming soon

Any REST API

Import an OpenAPI spec and turn each operation into a typed, classified tool with per-user auth.

  • OpenAPI import
  • Choose which operations become tools
  • Classify fields before they ship
Browse all connectors
For engineers

Give the model tools. Keep credentials out of the prompt.

Sessions bind a user once. Tool definitions come back in the shape your framework already expects, with an executor bound to that user, so no token ever reaches your handler or the context window.

  • Direct execution or multi-turn sessions
  • Zod schemas reject bad arguments before the upstream call
  • Missing OAuth scopes fail closed and name what is missing
  • An authenticated proxy for endpoints nobody has modelled yet
Read the feature set@dexby.ai/sdk
For security

Answer the review before it starts

Classification, encryption, and audit are properties of the runtime rather than conventions a team is asked to remember. The controls hold for a connector nobody on your security team has read.

  • Envelope encryption under AWS KMS or a local keyring
  • Standard, PII, and PHI tags carried on tools and parameters
  • Tamper-evident records for access, rotation, and execution
  • Erasure covers credentials, bindings, and execution traces
Read governanceSOC 2 · HIPAA · GDPR · CCPA
SDK

The user identity is the only thing you pass in

import { Dexby } from '@dexby.ai/sdk'

// Reads DEXBY_API_KEY from the environment
const dexby = new Dexby()

// The credential is resolved for this user, at this moment.
// Nothing about the token is visible to the caller or the model.
const result = await dexby.execute({
  toolId: 'slack_post_message',
  input: { channel: 'general', text: 'Deployment complete' },
  userId: 'user_123'
})

Mastra has a first-class provider too. Anything that accepts JSON Schema function definitions works without one.

Dexby Cloud

Managed on AWS

KMS-backed key material, managed credential storage on DynamoDB or Aurora PostgreSQL, and warm Fargate runtimes. You bring the agent, we hold the token lifecycle.

Self-hosted

Inside your own network

Docker Compose, PostgreSQL, and local encryption keyrings, with no proprietary cloud API in the path and no outbound telemetry to us. The SDK contract is identical, so moving between the two is a configuration change.

Architecture

How credentials, tools, and runtimes fit together

Encrypted records live in PostgreSQL or DynamoDB, chosen per environment. Dexby Connect wraps them with AWS KMS envelope encryption in cloud, or local SDK keyrings when you self-host. Storage is not an authorization boundary: the owning application supplies the authoritative scope for a credential, and the runtime enforces it on every call.

Private beta

Request access

We onboard teams in batches so that every early deployment gets real attention. Tell us which APIs you are blocked on and that shapes what gets built next.