Enterprise MCP with identity built in — for every user, every system

This is a pretty familiar scene. You've got your users, their AI assistants, and a task that touches on a few different systems. In this case, let's assume that I'm a sales rep, and I wanna go ahead and make use of my LLM here in Claude, and I wanted to go and push back the billing date on a particular account of mine. So I'm gonna go ahead and ask it to do that for us, and it's gonna make use of the tools that I've added onto it and have authenticated into. So a relatively straightforward request, and our LLM should be able to assist with that. So in this case it's picking out the right tool, and they're gonna go ahead and execute that for us directly.

In this case, it's come back, and it's now pushed that back to May first. So simple enough. It handled it well. Job's done.

However, the big question here now, though, is that someone's gonna see a change in Salesforce. They're gonna see that this account has been pushed back from its billing date, and they're going to ask a very critical question of who made that change and were they actually allowed to make it. And right now, what you'll probably find for a lot of MCP services, the honest answer is it's often a service account that's doing that. So you're making use of a shared credential.

There's no real attribution. It really lacks any good permission boundaries, and there's no real order trial that means anything.

Now this is what was running behind the scenes for that particular chat interaction. This is what we call a composite MCP tool. Now this is just a single tool that spans both Salesforce and, in this case, Jira. So while I was able to take that action, actually update something in Salesforce, I've also added this additional step on the credit ticket in the ticketing system so that the remainder of the team has visibility about those changes from an accountability and audibility point of view. This allows you to build out really well defined scope processes with this idea of a composite MCP tool. Now these are the kind of services that enterprises actually need to be able to build out, and it allows you to expose out a ton of powerful functionality in a much more governed manner through MCP. However, this is exactly where authentication can start to get complicated.

Let's go ahead and run that scenario again, but take a look to see how our latest functionality known as dynamic authentication can come in here to make sure that any of those services that we're interacting with are scoped specifically to the user that that we're dealing with. So in this case, my user's gonna go ahead and ask it for its active pipeline again and update Meridian software enterprise upsell date to then be May thirtieth. Now, again, as we saw just a moment ago, it's gonna go ahead and pick out the right tools. Merlin is gonna see its tools that it's got availability for.

It's gonna, in this case, gonna ask you to make sure that it's able to make use of that. Now what we'll also see in just a moment, though, is that where it makes sense for the first time the user's interacting with that system, it's gonna prompt that user to go ahead and authenticate into that system directly. So in this case, it's like, okay. Great.

I just need you to go ahead and select this link and authenticate to this underlying system. This will allow me to redirect to the Tray platform where we're gonna securely collect the authentication information for any of those services that we're interacting with. So in this case, I'm gonna set up my Salesforce one, click on continue, I'm gonna come back on over. I'm gonna tell my LM that I have finished.

It's not gonna be able to make use of that authentication in the rest of its tool call as it was going through just a moment ago. So at the right moment, the access is requested, but most importantly is that we're now authenticating on the perspective of that user. So any of those permissions and roles are gonna be applicable to me. And I was gonna make use of that second tool.

Now the second tool is the one that also needed access to Jira. So, again, we're gonna make use of a user level authentication for Jira as well. And just as before, it's gonna provide us with that link so we can go ahead and securely access that as necessary. I'm gonna go ahead and click on open link, and I'm gonna be able to provide that authentication.

For the Salesforce, because we're now writing to that data, it's gonna ask me for extra permission scopes. And the same for Jira, I'm gonna authenticate into that depending on the right authentication.

Once that's done, I can come back in, and then go back through and finish off the rest of its process for us there directly. So it hit Salesforce. It hit Jira, and all of that has now been authenticated directly as my users. So two systems, two authentications, but they're all in line on demand and all under the user's own identity.

There's no service accounts being used here, no hard coded credentials, and there's nothing that needed to be set up there from that side. Now let's go back to that question at the start of who made that change, and were they actually allowed to make it. So here's the activity log from that run where we updated our billing date of that particular record. Now as you can see, we've got a full visibility.

We've got time stamps of that execution. We can see the systems that were accessed, Salesforce and Jira, and we can also see the details and the things that were obtained. Now most importantly, we can also clearly identify that these were user provided authentications using our DynamicAuth functionality. These weren't service accounts.

These were a person acting with their actual permissions with complete records behind them. And And that's the real answer that IT needs, and it's the difference between an MCP service you can pilot and one that you can actually put into production.

For the team that builds this, here's what the setup looks like. You can find out your MCP service that you would like to expose. You can have a think about the tools that you'd like to add on, whether that's the composite tools that we just went through or more specifically those connector tools that has ran across our entire connector library. Most importantly, you can then define out which users should be able to access this MCP server and whether they should be able to add on to their LLM of choice.

But then from an authentication point of view, you can then take a look at all of your tools and the authentications that are used, then define out whether they're user provided, that's the dynamic authentication piece, or they are making use of a service account where it is required.

In this case, it is a single place where from an authentication point of view, it's gonna apply to all of the four tools that make use of it, as well as the Jira one here that's applying to that single tool. So what's really powerful with this is that you only need to configure it once at this single level, and it applies every one of those tools that it makes sense to. You don't have to worry about this in the workflow logic. It's all handled for you. What's most importantly is that it gives you the ability to focus on what the actual tool functionality is doing. The authentication will then be handling itself.

Bringing this altogether, what that means is that every action is applicable. Every user is authenticated, whether that's a simple MCP tool or a composite tool. No matter how many systems and no matter how deep they get, they're governed from end to end.