Skip to content

SUPPORTING KNOWLEDGE · 0013

Connections, extensions and who manages them

Berd has two different ways to give an agent reach into the world, and they share one settings surface, which is why they get confused.

A connection is an OAuth sign-in to an external service the agent can act through (Slack, GitHub, Google Drive), chosen from a catalog Berd defines. An extension is a directly configured tool integration: you or an administrator supply the command, URL or config. Extensions come in five transports (stdio, SSE, streamable HTTP, ACP, builtin); most of what people call "an MCP server" is one of these.

Both appear side by side in the connections section of Settings because, from where you sit, they are both things Berd can use on your behalf. The grid groups them as Company managed and Local, and since v0.6.2 an Add connection action hands the setup to a chat whose prompt first asks which of the two you want, and is told to ask before changing configuration and never to print or copy credentials.

Not in the public build

At v0.6.4 the public release compiles company-managed connections off (VITE_MANAGED_CONNECTIONS=0 in the release workflow), and the OAuth catalog goes with it because it mirrors Block-internal services; the security ML thresholds are off the same way (VITE_SECURITY_ML=0). Block's internal distribution has both. In a public build the connections section holds extensions only, and the security section holds trusted link domains only. The connection material on this page describes what exists in the source for the day a distribution you run enables it. Last checked: Berd v0.6.4, 2026-09-11.

Why it matters to you

A connection is standing access — and so is an extension that holds a token you supplied, which in the public build is how an agent reaches GitHub or Drive at all. Once an agent can act through it, every session that has it can use it, unattended runs included (in distributions that enable automations, scheduled ones too). The grant is the decision, and it is made once.

Three distinctions the help skill insists on, the first two of which only arise in distributions that enable connections:

Company-managed is not yours to edit. Some connections are provisioned centrally and matched against the same catalog. They are not freely editable or deletable the way your own extension is. A missing or greyed control on one is the design, not a fault.

Expiring is not disconnected. A connection has a status (active, disconnected, expired) and can show Expires in N days, with an Extend access action. A connection that "stopped working" and shows expired needs its access extended or a reconnect, not a fresh setup. Check the status before you rebuild anything.

Security thresholds live next door. In the public build the security section holds the trusted link domains — the domains you accepted from link-safety prompts, which now open without asking. In distributions that enable security ML, the same section adds prompt-injection detection (scans conversation context) and command-injection detection (scans tool calls), with a sensitivity from 0.0 to 1.0 where lower means more prompts; changes apply after a restart. An organisation-managed install can lock these on. One notice says ML classification requires a connection to WARP, which is why it is Block-internal.

How to apply it

Name which kind you are adding before you start. Command or URL you supply: extension — in the public build, always this. Sign-in from the catalog: connection, in distributions that enable them.

Grant narrowly and review the grid at the end of an engagement. A connection to a client's system that outlives the engagement is an exposure nobody is watching.

Where a flagged action produces a security alert, read it. Do not raise the threshold to make them stop. In the public build, review the trusted domains list at the end of an engagement with the same eye.

The same discipline applies to an MCP app inside a chat: since v0.6.4 an app must ask before it sends a message as you, and the confirmation shows the extension, the tool and the exact text. See Work with artifacts and MCP apps.

In Buzz the equivalent decision is granting an agent access to real systems; the reasoning is the same even though the mechanics are not, as the Buzz Guide's Agents as colleagues, not bots explains.

If you ignore this

You rebuild an expired Slack connection from scratch when Extend access was one click. You try to delete a company-managed entry and file it as a bug. Or an automation keeps acting in a client's Drive three weeks after the work ended.

Examples

A building pass (connection) versus a key you had cut yourself (extension). Some passes are issued by the company and you cannot alter them; every pass expires; and the lobby has a metal detector whose sensitivity someone sets.

A consultant on the public build adds a GitHub MCP server as an extension for one engagement's repo, using a token scoped to that repo, and on the last day removes the extension and revokes the token. A local extension for a document-conversion tool stays; it touches nothing of the client's. On a distribution with connections enabled, the same discipline is a GitHub connection, its expiry noted, disconnected from the grid on the last day.

Treating an Expired badge as "Berd lost my connection" and deleting it. Expired is a state with its own action, and the help skill tells the agent to ask about it before assuming a setup problem.

Do it: Manage connections and extensions

Last checked: Berd v0.6.4, 2026-09-11.

Reference

Verified
Berd v0.6.4 · 2026-09-11
NEVER BESTUCK AGAINCLICK ME

Guide built with Berd, Claude and Codex · verified against Berd v0.6.4, 2026-09-11 · read from source, not yet tested in the app · Buzz Guide · About · not affiliated with Block