LangChain shipped a feature called Connections for its Managed Deep Agents platform that separates two things most agent deployments still bundle into one API key: what a tool is allowed to do, and who is actually asking it to act. The company describes the problem as its own framing, not an independent audit finding: a single hard-coded credential means every action an agent takes, whether it is a shared search query or a pull request opened in someone’s name, shows up under the same service account.
Connections addresses that by letting a developer choose ownership per credential, at creation time, through a command called mda connections create. A credential can belong to the agent, meaning every caller shares it, or it can belong to the caller, meaning it resolves to a specific person at run time. Separately, the credential itself is either an OAuth grant or a static secret. LangChain’s own example pairs a shared secret with a web search tool, since a query to a pricing feed or a geocoder does not need to differ by user.
The more consequential case is user-owned OAuth. When an agent needs to open a GitHub issue or query a Linear ticket on someone’s behalf, LangChain’s design stores no credential value at deployment time at all, only an app registration. The token itself arrives per caller, and if that caller has never authorized the connection, the run pauses and asks for a grant before the tool executes. According to LangChain’s post, that pause happens once per missing connection, even when a task spans multiple services, and the resulting action (say, a created GitHub issue) shows the human caller as its author rather than a bot account.
That distinction is the real story here, more than the command-line syntax. An agent-owned credential creates a single point of accountability: every action traces back to the deployment, which is fine for stateless lookups but creates a blast radius problem the moment the same key touches anything destructive or user-specific. A user-owned OAuth grant pushes accountability down to the individual, which solves the audit-trail problem but introduces a new one: the agent is now capable of taking real actions, with real permissions, under someone else’s identity, and the security posture of that action depends entirely on how narrowly the OAuth scope was set at authorization time. LangChain’s own example shows exactly this tension: GitHub’s default scope cannot open an issue, so the documented setup replaces it with the broader repo scope, which grants far more than issue creation requires.
LangChain frames the alternative to Connections as one shared credential hard-coded across a deployment, which is a real failure mode but also the easiest version of the problem to solve. The harder version, which the company’s post does not fully address, is what happens when an OAuth-scoped agent misfires: a wrongly filed issue, a bad API call, an action taken against a repository the human caller can see but would not have chosen to touch. The post does not describe an approval or dry-run step between a model deciding to act and the OAuth-authenticated call executing.
Teams building agents that touch source control, ticketing systems, or any user-facing OAuth surface should treat scope selection, not credential ownership, as the control that actually limits damage. Ownership decides whose name is on the action; scope decides how much the action can do once it is authorized.
This account is based on LangChain’s blog post “Connections: managed credentials and per-caller identity for Managed Deep Agents,” written by Victor Moreira and published September 9, 2026.
