Identity Best Practices to Secure & Scale Agentic AI / MCP Deployments | Kevin Gao, AI By the Bay 25
Now you might wonder why an enterprise would actually build their own internal MCP server. Why not just use something like the GitHub MCP server directly, something that already exists out in the world? And there's actually a couple reasons for why they do this. So, the first is with a GitHub MCB server, for example, uh or lots of different kind of MCB servers that are out in the world. Um there aren't actually that many there aren't that many uh like products that have an MCB server. Like notion has one, GitHub has one, a few others. Uh but they're not like super ubiquitous throughout the throughout the industry. And furthermore, they don't necessarily work exactly the way you want your internal MCP server to work. And what I mean by that is the tools that exist in the GitHub MCB server might only work for GitHub enterprise cloud repos and things like that
And if you have, you know, a more complicated use case and you have specific tools that you want to give your agents, uh, your internal employees access to, uh, you need to define those yourself. Um, so that's one common reason. And the other main reason which you know might you know be clear based on this uh this diagram here is that a lot of these MCP servers that exist out in the world today don't have the right security or authorization in place uh to where a CISO or administrator will actually feel comfortable letting all their employees just use. Um so a great example of this is like the HubSpot MCP server which you know uses things like an API key where you just kind of give it an API key and it has access to everything. that's not something that uh a lot of enterprise CISOs are really going to feel comfortable with. Um so, you know, this this is a a big use case uh for us as a company. Um and also just in general what we've seen in the in the enterprise landscape for MCB servers is they want to basically build agents and connect these agents to all these tools and they want to build an MCB server to do that. Now the other use case which is granted I think a little bit more forward- facing something that is or future facing I should say something that isn't uh fully materialized I think yet uh but something it's kind of in the mindset of people is when they think about what the future of MCP and AI look like um basically being able to expose any kind of external service to an agent things like shopping for example so like uh if you heard like Shopify has an MCP server you can spin up an MCP server off your Shopify store
Um, and you want to build an agent to be able to kind of understand what the inventory looks like, uh, be able to find deals, be able to cross reference with other MCP servers, all these kind of things. Um, and, uh, you know, these external facing MCP servers also require a lot of the same stuff as the internal servers from a authorization standpoint. Um, so one of those is obviously scope-based access control. Being able to say what particular tools based on scopes does that agent have access to? What can they do? Um, be able to register the clients either dynamically or using client ID metadata documents. What this means is the agents that are connecting to the server need to be able to identify themselves, have a unique client ID that can be audited, monitored, so you understand this is the agent doing this particular task and be able to control access that particular agent. Uh and finally, consent management is a very big thing. So uh this is uh especially for an externally facing MCP server, you want your users to be able to actually understand what they're giving the agent access to. So they need to see a consent screen that makes it very clear that when I say authorize and connect to this agent or whatever that I'm giving the agent access to read from my calendar
I'm giving it access to buy things because this is like fundamentally what uh you know is is is what authorization is about is making sure that the user is aware of what they're authorizing and giving them control over that. Um and so these are the two kind of main use cases for MCP. And you notice that in both of those cases, both in the internal one and the external one, there's an off layer here. So uh for the internal one, it was connecting to an existing SSO identity provider and for the external one, it was connecting to a cy provider. The difference being that both are effectively just identity providers where you have user information and user identity stored. Um, and for the internal one, typically who's using it? It's internal employees, right? So, they're signing in and giving access through their octa, through their Azure, anyone who just basically signs in through their company kind of workforce identity providers. That's an example of that. And for customerf facing ones, it can be anything
It can be username and password. hopefully not, but username and password, uh, social login, pass keys, all of those things you would expect from just a normal web page when you sign in. You also want to have the user identify themselves in that way when they consent for the first time. So, you can see like we've already talked about a lot of different use cases and some of the things that go into actually providing that authorization. Um, and because of those because a lot of those things are like very kind of complicated authentication authorization paradigms that most engineers don't understand or don't really want to worry about. You kind of see in the numbers why uh, you know, a lot of MCP servers don't get deployed. And and and I'm going to talk about why, but uh, you can see here out of 5,000 plus MCP servers in the ecosystem uh, in registries and things like that, less over 2,000 of them don't have any security at all. mostly because engineers don't want to worry about it or they don't need to because it's such a simple MCP server that does a very simple thing
It doesn't matter. And then you know you can see here only about 13% of remote MCP servers actually end up getting deployed. Um and a big reason for this at least especially in our experience um is uh when it comes down to adding that security layer there you know there's a lot of confusion about what that entails. there's a lot of uh concern about how they can actually control and audit and so these are come some of the common challenges one is just basically adding an identity provider adding an ooth identity provider either building it yourself or using a platform like dscope like ozero like work OS I'm sure you're familiar with a lot of them um using actually defining what function or tool level scopes there are what they how they exist at either a user or organizational level um being able to implement this kind of incremental consent where the agent has a limited amount of permissions at the beginning and can kind of ask for more progressively as it needs more and more access to different tools. Uh being able to integrate enterprise SSO I mean a lot of people have basically built entire businesses on making it easy for you to add SSO. It's not particularly easy to add SAML and add all the setup and configuration for your customers to configure that. Um, visibility and control, being able to actually audit when the tokens are issued, when they're refreshed, which users are signing in where, what tools they're access they have access to, all these things. Um, and then just deploying everything
So deploying the actual MCP server itself and and and maintaining that as a part of your infrastructure is one thing. Now having to also kind of manage an ooth provider and things like that is just another layer of things that make it complicated. So with that what I want to focus on is a few identity tips. So for all of you who are building MCP servers uh or building AI agents and uh you know maybe you're exploring them through your companies as as a enterprise for an enterprise use case or you just kind of are interested in figuring out how this all works. Uh these are some tips you can kind of keep in mind uh that uh you can bring back to your teams and whatnot. So there's basically I broke it down into a few kind of key layers. One is MCP authorization. Um so this is like the the most basic kind of [snorts] level of authorization or authentication that you need for your MCP server
Um and that's and this is actually mandated by the spec. Um and that's to implement OOTH 2.1 and to make sure that if you have a remote server that uh it you know conforms to all of the specifications of OOTH uses Pixie as a CL with your clients and supports that uh and that the authorization server which is the server that's actually issuing the tokens that's managing the user identities that's doing all of this identity stuff is separate from your MCP server. So this is mandated as part of the latest iteration of the MCP spec. Um, and this is basically very similar to how you would think about building a backend today. Like when you build a backend, you don't expect the backend to be able to issue tokens and manage all the authentication for the clients. You expect an IDP like you know an Ozero an octa dcope things like that to be able to do that. MCP servers are no different. So that's uh those two kind of things and then obviously uh implementing dynamic client registration so that the clients can kind of register themselves or uh you can have them statically defined as well
Um and then you know obviously ensure that your MCP server has some kind of authentication mechanism in place. So when I say implement OOTH 2.1 part of that is predicated on there's like an O flow that runs where a user can actually sign in either with SSO or some other method. Um, and if they have SSO, maybe map those sample groups and stuff to uh roles and whatnot. And so once you've done that, and this is actually uh, you know, that's that's fairly easy. There's a lot of tutorials online, including uh, some good ones from us on how you can actually do that. Just add O to your MCB server. That's pretty pretty simple. Where it gets a little bit more complicated is when you start talking about, okay, I don't just want to say this user does or does not have access to this MCP server
I want an agent or a MCB client to actually be able to access specific things within the MCP server. So this is the more granular kind of authorization we're getting into now. And this is controlled uh at the you know highest level by scopes. Um, and so typically what we see a lot of our customers do and what we recommend is to define a scope for each one of your tools in your MCB server. So if you have a tool to read from Google calendar, you have a tool to push to or read from a GitHub repo, you have a tool, you have a scope that's associated with that tool, and then you can implement those uh and manage those both from a user level or from an organizational level. uh you want to make sure that there's a defined list of what scopes are required for your whole server to just function and which ones are optional. So for example, maybe not every customer feels comfortable with letting this agent be able to access the Google calendar and write to it, but they still need to connect to be able to read events. So maybe you make the calendar read scope mandatory and the write scope optional
And you have mechanisms for the agent to progressively ask for new ones. So if you eventually decide I want it to actually write to a Google calendar, there has to be a way to actually facilitate that. Um and then finally, uh restricting access based on specific scopes is something that we uh we do and something that if you're building your IDP, you want to make sure that you can also enforce. So you when you when the agent actually requests to get a token initially, you know this is the agent, this is the roles and permissions it has. Can it actually ask for the scopes that it's asking for? Now, this next part is more about managing tokens not for the client, so not for the agent itself, but for the MCP server itself. We didn't really talk too much about this, but uh in these scenarios that I've been mentioning of like the MCB server goes out to Google calendar and does something. Google calendar operates with its own set of APIs and requires its own set of Google tokens. So typically with MCB servers, they have to have some way of managing those tokens to be able to execute that tool
And so uh what we what most enterprises will do is they'll use a token vault like they'll use like hashy court vault or something like that or um you know there's lot of other providers out there and they'll actually store the Google token they'll store the HubSpot token whatever it needs any API key or OOTH token to actually go out and do those things and so you actually want to make sure that you are using that token from that token vault and that you never pass it to the agent. Why? Because if you pass that token to the agent, the agent can just bypass the MCP server and go out and do whatever you want to do, what whatever it wants to do with that token. So the MCP server in effect becomes that kind of layer of authorization without maybe you not even fully recognizing it. And that's brings me to the next point which is that you never want to pass the agent token through the [snorts] MCP server to the resource. You want to have that degree of separation because if that token would work theoretically the agent could bypass the MCB server entirely. So this is the MCB server is basically a broker of authorization between the client and all of the tools that you want to access. And you want to make sure that those tokens that the tools actually need are stored securely. Now, from the consent management perspective, this is actually this is there there's a lot of actually uh kind of cool innovation that's that's in this
It seems kind of boring probably to most people, but it's actually really important because proper consent management is really key for your users understanding what they're actually granting access to. So, when I when we talk about consent management, um it's part of it is just having a consent page. Like you've I'm sure most of you have seen that when you sign in with Google or what whatever you see a consent page and it says I'm giving access to my Gmail or whatever. But it's more than just that. It's allowing your user to override whatever the agent is asking for. Say no actually I don't want it to have the ability to write emails just read for my emails and check a box or something like that. That's important to implement. The other thing that's important to implement is there's potentially a lot of different consents across all of the tools you want to access
Like think about it in an MCP server case where I'm a client and I'm connecting to Google Calendar and HubSpot. There's potentially three consents involved there. One consent for the MCP server, one consent for HubSpot, and one% one consent for GitHub uh for Google. So in all those three cases, you want to make sure that you manage that with in a way that's very pleasant from a user experience perspective, but very clear to the end user. This is what they're actually providing access to. So these are the kind of things that you know it helps to really kind of understand what the enduser experience looks like and how you implement all all the little kind of bits and pieces of the OOT spec to craft the right user experience for that and to init and to initiate step-up flows. So when the agent needs to get new scopes, new permissions, it can do that. And then finally, this is like basically kind of, you know, goes without saying from from all of this, but you need a way to kind of manage the life cycle of these tokens, things like that
Uh, and there's a lot of kind of cool things that you can do here. One is you can uh change you can assess the risk of the agent that's requesting your MCP requesting access to your MCP server via something like an IP address or something like that. You can determine, okay, is this agent allowed to access it or not? You can block its registration. you can decide it needs to consent more often. These are all things to consider especially in an enterprise when you're building an external or internal facing MCP server. And obviously you want to make sure that all the auditing and visibility that you would expect within your MCP server from the clients of who's accessing what what permissions they have the users have consented to being able to revoke those being able to see who revoked those everything is all supposed to be audit. All right. Uh, and that's my presentation
Thank you very much. I can take some questions if anyone has any. Yes. Yep. Yeah. Yeah. Good question. Um, so I'm actually one of the reviewers of the PR that got merged in the MCP spec very recently for this defining how this actually works progressively
Um, and so there's actually there's a couple ways you can define it, but basically how it works is um the MCP server you you might have a tool defined for a scope to read the repos for example. And then behind the scenes there might be an additional layer of authorization. This user is only able to access these documents within your embedded, you know, your vector database, whatever. There's a rag service associated with it, whatever. But the the core comp the uh the key piece here is that you should not be able to possess that scope if you don't have the permission to see the documents you're accessing. And how you get that permission is you return the MCB server is supposed to return a 403. Uh there's a www authenticate header. It returns a 403 and it says what scopes you need
There's different ways to define it. It's all part of the MCB spec. It's part of the latest draft that's going to be released in November or like end of this month. But um but basically uh it will return a 403 with the scopes that it needs. The client gets that and says, "Oh, I need more scopes." Then it will go through the authorized code flow process again. It'll run through the same O flow that you were that you were seeing, but in most IDPs or mo in most IDP scenarios, the session that already exists will just kind of be reused. So user doesn't have to sign in again. They just see a new consent flow
And that new consent flow will show the exact scope that they need to actually access that resource that you're talking about. And then they will have to click authorize or they can you know you can you can not show you can choose to bypass the consent flow and just show you know just basically like automatically allow access. There's different ways like that's ultimately up to you as the developer. But the idea is uh you you go through that concept flow again and you'll get a new token with that scope and then the client should automatically then remember the tool that it was calling before call again and hopefully the server doesn't return a 403 this time and that's how that's how it's supposed to work basically. Hopefully that answers your question. Any other questions? Yeah, sure. Yeah. So engineers in my experience don't want to deal with any of this
They just want to build an MCB server that works and they really could care less about who has access to what. Um it's really this the conversation usually starts with the CISO or whoever is in charge of the security in in enterprise. Um who actually dictates the policies, how that gets all implemented. Um, I mean it's it's part it's partly kind of propri it's partly proprietary to who's implementing it because not every company like they have their own IDPs that work somewhat differently than others. I'll tell you like from my experience working with customers of Dcope. Um, typically what happens is um there's uh a lot of them a lot of our customers will leverage the the roles the permissions that already exist from the workforce identity provider. So uh your octa your Azure that you sign into as an as an employee has groups and stuff associated with it. So within our product we allow you to map those groups and roles to particular like internal roles that can be that can be used to be associated with certain tools you can or cannot access
So that's like one one way that the policy is kind of like implemented in a sense from an engineering perspective. Um and then beyond that like how you actually like say okay this agents or this group of agents have access to those things. Um there's a bunch of ways. So um so uh at least with you know up until recently now we have CIMD which is you know a little bit different in how it operates but uh before we you know agents would come to us directly and dynamically register. So we would have a few kind of bits of information. We would have the name of the agent which could be faked depending on who it is. Uh the redirect URL which you know if it's a non native application so not like something like cursor but maybe claude or chatbt we have a verified domain associated with that redirect URL. That's one piece of information
We also have an IP address which we can determine if it's malicious or not through something like abuse IPDB or something like that. Um those kind of bits of information we can use to craft a policy to say okay agents that are coming from verified domains like claude or chatbt that maybe are part of a specific IP range within the enterprise on a VPN or something like that they're allowed to access certain tools that others don't. You can assign tags to different types of agents and build a policy according to that. So there's that's in Dcope that's how Dcope does it. There's many other like I've seen other kind of uh mentions of uh collecting more information from from the agent and it's part of what so that the client ID metadata documents I've mentioned a couple times now uh that's like kind of it's a sem a quasi replacement to how agents register dynamically uh be how agents dynamically registered before and that required the client or the agent to actually have a hosted wellknown of information about itself. um from that there's more stuff you can do um but that assume that that is predicated on the idea that the agent actually supports that which most mcb clients today do not only VS code as far as I know uh supports that out of the box but anyway that's uh hopefully that's a longwinded answer it's answer to your question yeah any other questions okay cool uh yeah come by our booth if you want to see a demo over product or anything. And uh it was great uh great talking