How to manage shared and user credentials with Managed Deep Agents Connections

0:00 Every agent today hits the same wall. It needs to do something on your behalf. Search the web, file a ticket, open a PR. Today, that usually means one API key hardcoded across every deployment. And every action showing up under a service account. Connections, a system for managed deep agents, fixes these issues. I'm Nathan, a PM at LangChain, and today we're going to talk through three ways to wire credentials into a managed deep agent using connections with agent-owned secrets, user-owned OAuth through MCP, and user-owned OAuth with a custom app. Let's dive in. First, let's take a look at agent-owned secrets. So, agent-owned secrets is where you have one key that's shared across every user.

0:36 In this situation, I want to add web search to an agent that I've stood up with MDA and it. And because every user has the same web search, it's okay to share that key across all the interactions. So, we're going to use an external service called Tavily. And first, we want to create our connection. So, we'll run MDA connections create. The name of our connection is Tavily agent. and will pass through an API key that I have stored in my environment.

1:02 This is going to create the connection in LangSmith so that once I deploy my agent any interaction that agent will be able to pull it dynamically. I can verify that it was created with MDA connections list and you can see it was created and it's of type secret. So this is an agent secret rather than a user secret. Now we can create our tool. I'll create the search web file and I'll write in my tool. The tool code here is pretty straightforward. We're creating a tool called search web which takes an input of some query that the agent can pass.

1:38 And the interesting part here is that I'm grabbing the API key using this connections.get command. So I'm keying on this slug that we defined with our create command. And this is of type agent rather than of type user. We're always pulling out the key. And then we can pass that key however we want. In this case, it's a simple post to the Tavi API where we just pass through the query and then we get some results. Now our agent can search the web. So let's propagate this tool into the agent. And now that we've stood this up, our agent can interact with that tool using the API key that it'll fetch from the connection that we've configured.

2:15 So here I have it running in my studio which is interactive dev environment. And if I ask to search the web, you'll see it'll invoke the web search tool and it can pull up some information about the query which in this case was lang. And if I inspect the web search, you'll see it passes just the simple query lang. It gets some results from our API. So however I've defined the tool, but of course whenever it interacts with Tavi, which is a restricted service, it's going to do so using this API key that it pulls from the connection system.

2:48 Okay. Now let's add a user-owned OAuth connection. So with a user-owned OAuth connection, whenever a user interacts with the tool, it's going to prompt that user for their own credentials and then we can use those credentials passed through in any query that we create. So to start, we'll just use them to pass through to an MCP tool set. I can run MDA connections create linear MCP and this is a connection of type MCP. So I'll pass in the linear MCP URL. So once I've done this, this will discover and create the MCP connection. And then I can reference this connection when I define my MCP servers in my application.

3:28 We'll add in a file to our tools directory called mcp.py. And this is a special name. And when I do this, I'm going to import the define MCP connection. And I'll set up the set of servers that I want to connect to. So in this case, we're only connecting to Linear's MCP server, but I could add any number of MCP servers in this connection. The MCP server URL is defined here and the connection is of type user which is fetched from our connections.get command.

4:01 Okay, so now that this is set up, our deep agent is going to automatically detect the MCP connections that we have configured. And if I go back to studio, I can create a test issue using linear. And what this is going to do is it's going to prompt me to run the OAuth connection. So although I'm using this in studio, if you had configured a slack channel, the user would similarly see a connection flow in Slack. If I run this flow, this will open up the connection approval flow, the OAuth approval flow. I can click approve.

4:36 This will authenticate my specific linear account and then pass that token back. So now the agent can automatically leverage that token in order to run any number of tools from Linear's MCP store. So this is useful if you're configuring a connection in a situation where you know the set of tools that the resource provides is sufficient and you want to just pass those through directly. But you always want to ensure that you're using the end user's credentials rather than some shared credential set. So it created an issue and if we take a look you'll see this was created by me specifically. This wasn't created by some service account or bot token. It was created using my credentials specifically and that's because of that ooth flow. So to configure all I had to do was set up the connection fetch it in this MCP server definition and we're good to go. Now let's take a look at user-owned OAuth in a custom app. So this is a bit more sophisticated but a lot more flexible. First of all, we can take a look at some quick start for a few different connection options with the with the MDA catalog. We provide a ton of connections out of the box that you can get set up with where many of the parameters are passed in as defaults.

5:49 So, you don't need to do any lookups. In this example, I'll connect to GitHub so I can quickly grab the link to set up my OAuth app here. I've already set up an OAuth app, but if you haven't yet, you could create a new one. Just make sure that the redirect URIs are configured correctly. Now that I have my OAuth app set up, what I want to do is to register that OAuth app in Langmith. To do so, I will run the create command like we've done before. In this case, I'm passing this is a type ooth connector using the GitHub credentials or the GitHub config from our connections catalog. We're going to pass in the client ID from our OAuth app and the client secret from our OAuth app which I was able to fetch after creating the application and I want to define the scope to repos. You can configure whatever scope you need. Now that the connection is created, I can leverage this in my app in custom tools.

6:42 So as before, let's create a file for the new tools that we'll be adding. And once we have that set up, we can add in our tools. I've already written these, but let's take a quick look at what's happening here. Essentially, we're pulling in as before the connections function. So, we can use this method to fetch our access token. What will happen is at runtime, connections.get will either invoke the OAuth flow and then pass through the token or if the token already exists, is already cached in Langmith, it'll just pass that through and it'll use it automatically.

7:17 So, if a user interacts with the agent, whether the user has previously accessed this tool, if a token is still valid, or if they've never accessed this tool before or a token is invalid, it will run the refresh flow or the get flow for a new token. And we'll see that in a second. Again, we're using the same slug as before. In this case, it's type user rather than of type agent as we saw in the tab example. We can use this token however we want. In this case, we're passing it through to the GitHub API.

7:46 We've got a search issues tool which takes some term. We've got a create issue tool which takes in the repo name, the title of the ticket and the body and that'll just do a post command to our little helper method here. But you could configure this however you want and obviously it's generic. We're using the GitHub API but any API would function here as long as it supports the access token that you are pulling in from the OAuth connection. Now that we've got this set up, let's pass through these new tools to our agent. We'll pull in the search issues and create issue and make sure that they're registered. We can go back to studio and I have this repo that I'm working on and I want to interact with the issues in here. So I'll say what is the highest priority ticket in example agent repo. And what's going to happen here is the agent will find the new tool that's been registered and it will try to invoke it. And if it can't invoke it, it will run me through the OAuth flow so that it can fetch my credentials and pass those through.

8:52 Okay, so it tried to run the search issues tool and it wasn't able to because it needed to run the OAuth flow. So all this happens automatically as a developer. I didn't have to configure this. I didn't have to manage it. The only thing I have to do is run this connections.get method and it will guarantee that it will give me the token at some point. So I'll click connect. This will pass me through the OAuth flow. You saw before the authentication was successful. We get redirected back and now the agent is able to access these tickets on my behalf. And like before it's running these queries using my credentials rather than some service credentials or user credentials.

9:29 So, let's add a new ticket to run some triage because I guess I haven't done that very well at this point. So, now the agent can like before leverage that custom tool that we wrote. It's going to write a new issue in the same repo to track triaging the open issues. This is a silly way maybe to use ticketing, but we'll do it for this example. So, this is going to invoke the create issue tool that we looked at. Okay, so now it's created. Here's the new issue and here's the triage that it created based on the tickets that were in the repo. And again, you can see this was performed on my behalf. This was using my user credentials. So that's a quick intro to custom OAuth apps using connections and how you can configure and get started with the connections catalog.