Background agent credentials
An agent's gateway credential identifies the agent to Willow. Integration authentication identifies the account used to call an application such as GitHub. These are separate credential sets.
Authentication
The gateway accepts the agent's access key and secret together:
Authorization: Bearer <access_key>:<secret>
The Connect dialog on Overview shows the selected gateway, the agent's MCP endpoint, and the authentication header format. Use the exact endpoint shown there, including any gateway path prefix.
The secret returned when the agent is created is its Default token. An agent can hold several tokens, listed under Tokens on the Settings tab, each with its kind, the last four characters, when it was created, and when it was last used:
| Kind | Created by | Behavior |
|---|---|---|
| Platform | Deploying the agent | Handed to the agent's platform. Every deploy replaces it, so an old copy stops working. It cannot fire API triggers. |
| Manual | New token, or when the agent is created | For callers outside the platform, such as API triggers or an MCP client. Deploying does not touch it. |
| Legacy | Agents that predate tokens, from their old secret | Works like a manual token, and can be revoked. |
Give each manual token a name for the caller that uses it. Its secret is shown once when you create or recreate it; store it before closing. The Admin API also returns a secret when creating or rotating the agent's credentials; subsequent get/list responses do not expose it.
Managed platforms receive their platform token through deployment. Use a manual token when configuring an external client or runtime.
Secret rotation
| Action | Effect |
|---|---|
| Create a manual token | Adds a token for an outside caller; its secret is shown once. |
| Recreate a token | Issues a new secret for that token; its previous secret stops working immediately. |
| Revoke a token | Rejects that token's callers immediately. Revoking the platform token cuts the agent off from the gateway until you deploy again. |
| Deploy to a managed platform | Replaces the platform token; manual tokens are not affected. |
| Disable the agent | Prevents it from authenticating and running while preserving its definition. |
Clients using a recreated or revoked token must be updated. The underlying integration account is configured separately; changing a gateway token does not establish a new integration connection.
Integration authentication
Authentication is configured per MCP server in the agent's Tools tab.
| Selection | Identity used by tool calls |
|---|---|
| Run as the initiator | The person who triggered the run, using their integration connection. Available for per-user-auth servers. |
| Connect my account | The connected account displayed in the dialog. Calls run through this account. The label includes the configured authentication method. |
| Use the MCP server default | The server's shared credential, when it has one. On a per-user server, this supplies no agent identity. |
| API Key, Client Credentials, or Server App | The credential supplied for the integration, where that method is available. |
| None | No application authentication. Suitable only for an endpoint that requires none. |
For initiator authentication, Slack provides the person's identity. API triggers and direct MCP/API connections require x-user-email or x-user-id. Re-authenticate every run requests a fresh provider connection on each run when enabled.
The Admin API capability model includes integration authentication with auth_user_email for a connected account. See Update Background Agent.
Owner visibility
Show credentials to owners controls whether owners can view access keys and create, recreate, and revoke tokens in the end-user portal. Administrative permissions are controlled separately by the Background Agents role scope.