Credential management

How Weldable holds the keys to your services without ever touching them.

Wiring an AI agent into a real production stack means handing it credentials for ten or twenty different services. Each one has its own OAuth dialect, its own token lifetime, its own refresh quirks, and its own way of failing at the worst possible moment. Doing it correctly, with the security posture an enterprise reviewer would actually approve, is a project.

Weldable's credential layer exists so that connecting a service is a single click, and so that everything that happens after that click meets the bar a security team would set if they were building it themselves. You connect once. Weldable holds the credential, refreshes it, and surrenders it only to the specific worker that needs it for the duration of a single API call. You never see the token. Neither does anyone else.

Two independent auth systems

Weldable's surface area splits cleanly into two authentication domains.

• Agent identity authenticates an MCP client, like Claude Code or Claude.ai, to Weldable itself.
• Integration credentials authorize Weldable to act against an external service on a user's behalf.

The two systems share no storage and no code path. Revoking an API key does not disconnect any integration. Disconnecting an integration does not invalidate any API key. A compromised agent token gives an attacker no path to the underlying provider tokens.

Integration credentials

When you connect Slack, the OAuth handshake runs directly between you, Slack, and an isolated, encrypted credential vault that Weldable operates as a separate service from the rest of its application stack. The provider issues its tokens into the vault. Weldable's application servers never see them.

The guarantees that follow are the load-bearing part of the design:

• Credentials never touch Weldable's primary database. The application database holds only an opaque reference to a vault entry. No token column exists. No backup, query, or admin tool can surface a token from it.
• Credentials never appear in a log. Tokens are injected into outbound requests in memory and are not interpolated into log statements, error messages, exception traces, or audit records.
• Credentials are not cached across requests. Every action execution fetches its credential fresh and discards it the moment the call completes.
• Credentials are scoped per user, end to end. A worker can only ask for the credential of the user that initiated the action. There is no path by which one user's action can resolve another user's credential.
• Revocation is immediate. Disconnecting an integration deletes the encrypted credential from the vault. The next call against that account fails closed because there is nothing left to read.

Tenant isolation

Weldable is multi-tenant from the ground up, and the boundary between tenants is enforced as an invariant rather than as a policy any single piece of code is responsible for upholding.

• Every request carries an authenticated identity established at the edge. That identity is propagated through every downstream hop, including durable workflow runs that may execute long after the original request returned. No internal service trusts a caller-supplied user id.
• All data access is filtered by that identity. Credential lookups, action execution, workflow runs, and audit reads are scoped to the calling user. There is no internal API for "give me any user's credential" or "give me any user's run." The shape of the worker interface makes cross-tenant resolution impossible to express, not merely forbidden.
• The database is locked down at the role level. No client-facing credential can read the underlying tables directly. Application servers reach the database through a privileged path that exists only inside Weldable's infrastructure, and the public-facing roles are denied all access by default.
• Workflow runs inherit the identity of the user that enqueued them. A run cannot escalate to act on behalf of a different user, even when it fans out across workers, retries after a crash, or resumes hours later.

The result is that the worst-case bug in any single integration, action, or workflow has no path to cross a tenant boundary, because the boundary is not something an integration is asked to respect. It is a property of the request envelope and the data plane, enforced before any user code runs.

Agent identity

The wld_ API key system authenticates agents to Weldable. Keys are shown to the user exactly once at creation and persisted only as one-way hashes. Weldable retains no recoverable copy of any key it issues, and revocation takes effect on the next request.

OAuth 2.1 for remote MCP

Claude.ai's custom connector talks to Weldable's remote MCP endpoint over standard OAuth 2.1 with PKCE. Weldable implements the full discovery and grant flow, including dynamic client registration, user consent, and refresh.

Issued access tokens are prefixed wld_mcp_ and valid for 30 days. Refresh tokens are prefixed wld_mcpr_. Both are stored as SHA-256 hashes, on the same principle as the API key system: the platform retains no recoverable copy of any token it issues.

The MCP OAuth layer authenticates an agent to Weldable. It does not hand the agent any direct access to integration credentials. The two systems remain independent all the way through execution.