Skip to main content

Connections

The Connections page is an admin-only view for managing the API keys and service credentials that AI agents use when calling external systems. The page subtitle reads "Manage API keys and service connections across your agents" and shows the total credential count in parentheses when at least one connection exists.

Connections are provisioned automatically when an agent is imported through the Providers page; they cannot be created manually from this page. The available actions are editing a connection's metadata and credentials, and activating or deactivating individual connections.

Connection Card Grid​

Active connections are displayed in a responsive grid of cards — one card per credential. Each card contains the following information and controls.

Card Header​

  • Status badge — An inline badge showing Active (success colour with a check icon) or Inactive (muted with an X icon) for the current activation state of the credential.
  • Edit button — Appears on hover for connections that are not suite-managed. Clicking opens the edit form in place of the card grid.
  • Activate / Deactivate button — A power icon that toggles the connection between Active and Inactive without navigating away. The icon is coloured with the error colour to deactivate and the success colour to activate.
  • Locked badge — Suite-managed connections show a locked badge instead of the edit and toggle controls, indicating the credential is owned by an installed agent suite and cannot be modified manually.

Card Body​

  • Connection name — The display name of the credential in bold.
  • Description — An optional free-text description of the credential's purpose, shown as up to two lines of secondary text.
  • Authentication type badge — A small uppercase pill showing the authentication scheme (for example Api Key, Oauth Client Credentials).
  • Source badge — If the connection is suite-managed, a locked badge shows which suite owns it.

The footer shows the creation date as "Added [Month Day, Year]" alongside a clock icon.

Edit Connection Form​

Clicking the edit button on a card replaces the grid with an inline form. The form header shows Edit Connection and a close (X) button that returns to the grid without saving.

The form contains the following fields.

  • Name — Required. The display name for the connection, pre-filled with the current name.
  • Description — Optional. A short description of the connection's purpose.
  • Authentication Type — Read-only when editing an existing connection. Shows the scheme selected at import time.
  • Credentials — One or more dynamic fields driven by the selected authentication type, such as API Key, Client ID, or Client Secret. Password fields mask the value. A placeholder of •••••••• (leave blank to keep) is shown so users know the stored secret is preserved if the field is left empty.

The form footer contains two buttons.

  • Update Connection — Submits the changes. Disabled when the name or authentication type is empty, or while the save is in flight.
  • Cancel — Discards changes and returns to the card grid.

Which agent may use which connection​

A connection is a stored secret, so the question of which agent may decrypt it is an authorization question rather than a configuration detail. Every point where Runtime turns a stored connection into a usable secret now checks that the agent making the request has been granted it, and records the outcome either way.

Existing agents are unaffected. Every credential an agent was already bound to — through its datasources, its skills, or a connection mapping — was carried over when the check was introduced, so nothing an agent could reach yesterday became unreachable.

Note: The check ships in observe-only mode. Requests that would be refused are recorded and allowed to proceed, so the change cannot break a working agent. An administrator moves an environment to enforcing once the recorded set is empty; until then the value of the feature is the record, not the refusal. This is deliberate — an authorization boundary added to a system already in use should be measured before it is enforced.

Each decision is written to the platform audit log with the agent, the connection, the reason, and whether the mode made it binding. That record answers "which agents are reaching which secrets", which previously had no answer at all.

Unattended runs use the agent's own identity​

When an agent runs unattended — on a schedule, or called by another agent, with no person present — it resolves its Hub connections and credentials as itself, using its own agent identity. It no longer presents the address of the person who created it.

This matters because an agent created by someone in March and left running on a schedule would otherwise keep reaching external systems as that person indefinitely — including after they changed role or left, since a stored connection does not notice a deactivated account. What the audit log recorded in that case was the person's name, for actions they did not take and might not know about.

Runs with a person present are unchanged. Acting on behalf of a signed-in user who is there to see the result is exactly what delegated access is for; only unattended runs narrow.

If an unattended run needs an MCP server whose only connection belongs to a person, it stops and says so — naming the server and explaining that an agent acting alone must use its own connection — rather than quietly using that person's connection.

Note: Connections owned by an agent identity rather than a person are supported by the Hub, and an unattended run will use one when it exists. Creating one from the Hub interface is not yet available — until it is, an agent that needs a shared MCP server should run with a person present. See Beak Hub · MCP Servers.

Best Practices​

  • Deactivate rather than delete connections that are temporarily unused — Deactivating a connection prevents agents from using it without removing the credential, making it easy to re-enable later.
  • Leave password fields blank when editing metadata only — The Connections form preserves the stored secret when the field is left empty, so you can update the name or description without re-entering credentials.
  • Review suite-managed connections before upgrading a suite — Suite-managed connections are updated by the suite upgrade wizard; verify the expected credential changes in the diff view before confirming.
  • Use descriptive names — When multiple connections share the same authentication type, a clear name (for example Production Salesforce — Service Account) makes it easier to identify the right credential in agent logs and approval payloads.