Credentials available here
The first table lists every credential agents here can reach, one row per credential. Each row gives the Integration, who it was Added by, its Scope, a Policy chip, and when it was Connected at.
The Policy chip summarizes the credential’s policies and opens them: No restrictions, a count such as 1 policy, or the allowed methods when that is all a single policy permits, such as GET, OPTIONS only.
Manage credentials opens the account’s credential settings. It’s shown to organization admins and to the owner of a personal account.
Connect a credential
Click Connect credential. Admins and organization members both see it.- Under Who does this credential belong to?, choose The whole workspace for a workspace credential or Only me for a member credential. The choice appears only when you can connect both. Members who aren’t admins can connect only their own.
- Pick the Integration. The list includes integrations available to this workspace that connect with an API key or an OAuth sign-in.
- Click Connect, or Continue to integration to sign in with the provider.
Disconnect a credential
Disconnect appears on the rows you’re allowed to remove: credentials you own, your own member credentials, and, for organization admins, any member credential or credential the workspace’s account owns. A warning appears if active webhook triggers depend on the credential. To remove a credential from one agent, revoke it in the agent’s credentials instead. See Grant and revoke credentials.Which identity each agent will use
The second table, Bind a credential to an agent in this workspace, lists the installed agents with their Version, Binding, and when they were Added. A binding is a credential granted or dedicated to that agent, so the column answers whether the agent has one of its own and whose login it runs as. It doesn’t say which credential a call resolves to when the agent has none.
An agent bound for several apps lists one per line. If an agent holds more bindings than the page reads at once, a last line says Showing the first count credentials. Click Add Agent to install another agent in the workspace, or select a row to open the agent’s detail page.
A grant runs as the credential’s owner, and a task runs as the person who started it, so a grant of another member’s credential won’t resolve for your runs. Bind the agent with your own credential, or with one the organization owns, if it needs to work for everyone.
Grant and revoke credentials
Click Grant or Revoke on an agent’s row. Both open the same Credentials for agent dialog. The credentials are listed in two groups:- Granted to this agent — existing credentials shared with the agent, each marked Granted · owner. Pick one from Search credentials… and click Grant credential to add it. A grant runs as the credential’s owner.
- Dedicated to this agent — credentials that exist only for this agent, marked Dedicated. Click Connect a credential, choose the integration, then Connect API key or Connect via OAuth. If the agent already has a dedicated credential for that integration, connecting a new one replaces it and deletes the old one.
Restricting the account pool
Turn on Use only credentials scoped to this workspace to stop agents here from falling back to the owning account’s shared credentials. Agents then use only workspace, member, or agent credentials. The change saves as soon as you flip the toggle. The toggle appears on both the workspace’s Credentials and Settings pages. Connect or bind what the workspace needs before you turn it on. See Restrict a workspace to its own credentials.Related pages
- Credentials for how Guild chooses a credential
- Credential policies for restricting what a credential can do
- Workspace agents for the same bindings on each agent’s page