Connections: managed credentials and per-caller identity for Managed Deep Agents

LangChain introduced Connections, a credential management feature for Managed Deep Agents, available in version v0.7.0 and later. A connection is a named credential stored in a LangSmith workspace that tools read at run time by slug through a single call, connections.get().

Each connection has an owner and a credential type, which the announcement describes as independent. The owner is either the agent or the caller: an agent-owned credential belongs to the deployment and is shared by every caller, while a user-owned credential resolves per person at run time. The credential type is either a static secret or an OAuth grant; the company says an agent can hold an OAuth grant and a user can hold a secret. Ownership is fixed when the connection is created using mda connections create, and connections.get() only selects among credentials that already exist.

Connections are created with the mda CLI. The announcement describes an agent-owned Tavily secret created from an environment variable, and a user-owned GitHub OAuth connection for a custom app using a client ID, a secret from an environment variable, and the scope repo. It states that GitHub ships in the connections catalog alongside 22 other services, and that passing --scope repo replaces the catalog default read:user rather than adding to it. Some MCP servers register the OAuth client themselves; the announcement gives Linear's MCP server as an example where setup is a URL with no client ID, client secret, or app registration.

According to the announcement, user-owned connections resolve to whoever is asking, so an issue an agent files carries the caller's handle rather than a bot's. The feature runs the authorization round-trip, which the company says removes the need for a callback route, token store, refresh logic, or consent screen in a project. If a caller has not authorized a provider or their token has expired, connections.get() pauses the run and asks for a grant instead of failing, and a run spanning multiple services pauses before the first model turn with a single interrupt listing every ungranted connection.

The announcement also describes an --authorize option that stores one OAuth grant for the deployment so every caller acts as a single shared account, --allowed-scope to cap what later authorizations may ask for, and --authorize-url with --token-url for providers outside the catalog. Connections ship in the Managed Deep Agents prerelease, and the OAuth catalog ships inside the binary.