- Enterprises face significant challenges in deploying and managing Multi-Channel Protocols (MCPs), struggling with observability, access control, and security, which hinders the effectiveness of their AI agents.
- The recommended solution is to implement a "gateway" as a central middle layer between numerous MCP servers and clients, establishing a single root of trust for enterprise security and management.
- A gateway abstracts critical infrastructure concerns, enabling decentralized development of MCPs focused purely on business logic, accelerating iteration, and ensuring scalable, secure agent deployments.
What we learned scaling MCPs to Enterprise — Karan Sampath, Anthropic
- Enterprises struggle with MCP deployments due to opaque observability, complex access control, and security vulnerabilities, limiting the utility of their agents.
- The open MCP standard and public registry are valuable but lack essential enterprise features like built-in authentication, detailed access control, granular observability, and robust credential management.
- A "gateway" acts as a centralized middle layer, providing a crucial root of trust by managing all interactions between diverse MCP servers and various MCP clients within an enterprise.
- Gateways allow teams to focus solely on the business logic of their MCPs, as the gateway handles common enterprise requirements such as authorization, authentication, secure connectivity, and simplified deployment.
- Essential components of a robust gateway include an authentication system, role-based access control, a routing proxy, secure tunnels, an internal sub-registry of MCPs, and a CLI for easy integration.
- Implementing a gateway facilitates faster iteration, ensures adherence to standard operating procedures, enables more secure data connections, supports flexible credential management, and provides better scalability for agent deployments.
- This architectural approach promotes the separation of the agent "harness" from the underlying data layer, offering enterprises the flexibility to integrate various agent technologies while maintaining consistent security and access policies.
MCPs — An open standard protocol designed for agents to interact with various tools and services, facilitating communication and operations across different systems.
Observability — The ability to understand the internal state of a system (e.g., MCP usage, performance) by examining its external outputs, crucial for monitoring, debugging, and improving operations.
Access Control — Mechanisms that dictate who (users or agents) can access specific resources (like MCP servers or tools) and what actions they are permitted to perform.
Data Exfiltration — The unauthorized transfer of sensitive data from a secure network or system to an external location, a critical security risk.
MCP Registry — An official, centralized listing of available MCP servers, serving as a directory for discovering and connecting to various MCP-compliant tools.
Gateway — A crucial middle layer acting as a single point of entry and control for numerous MCP servers, managing authentication, authorization, routing, and security for MCP clients.
Root of Trust — A highly secured and trusted component within a system (e.g., a gateway) that forms the foundation of its security architecture, from which other security assurances derive.
Business Logic — The core set of rules and processes specific to a particular application or service (e.g., how an MCP processes a legal contract), distinct from underlying infrastructure concerns.
IDP (Identity Provider) — A service that creates, maintains, and manages identity information for principals (users, agents) and provides authentication services to applications.
Agent Harness — The framework or infrastructure within which an AI agent operates, distinct from the actual data and services it interacts with, allowing for flexible agent deployment and management.
So everyone, I'm Karan Sampath. I'll be talking to you about how we anthropic think about MCPs in the enterprise. I've alternatively titled it, I think what actually is why we think database are all you need. So before I go into the talk, I'm going to put you a little bit about me. I was, I'm a photo-plot engineer at Anthropic. That's why I'm outside the US. A lot of my work includes working with enterprises on things like MCPs and I also work on an internal use cases. In this talk, I'm going to be positing to you what we think the problems with enterprises, what enterprises face with MCPs today, why we think gateways and the necessary implications that come out of it are the best way to fix a lot of these problems and what is that, how does that align with our future vision for agentic deployments. So before we go on, I know a lot of you already know this, I'm going to quickly run through this, but just a very quick overview of MCPs as it is relevant today. The first is of course, we all know it's an open standard that was created, most of us know that at Anthropic. There is an official registry today which contains over thousands of servers and this has grown rapidly over the last year. And we see this happening that individual companies all the time are building new servers very quickly and are trying to ensure that they stay ahead and try to adhere to this protocol nowadays. But still, even if this happens, we see a major problem where enterprises try to use it. Enterprise is struggling to deal with what they believe the way it able to take. Things like observability. When they want to know who's using my MCP, who's using these tools, how do I ensure that the care people are using it, and how do I know how to develop on certain parts of the MCP protocol, which parts of my tools aren't working properly. These are something that's simply completely opaque to enterprises today. And in this access control, something just touched upon already. How do I ensure the correct users have access to the servers? Things like ensuring that certain servers are scoped correctly. Tools are only made, are only allowed for certain groups of servers. If you're working on observability MCP, you might want the entire company to have view into why, which things are failing. But only certain people to have the ability to actually change things and update new dash points. These are the kind of things that currently quite hard to do with MCP servers. And honestly, not something that we as a community have worked on enough. And finally, security. And I like to think that the three of these are almost like a three-headed hydrant in some ways. Security is a wide range of things. I like to think not only in terms of the MCP server, where you know, you enterprise the one, how do you verify whether the server is safe. It has the correct protocols and the correct ways of ensuring data. Exfiltration doesn't occur. Things like the tools can't be used in a harmful way, both for infrastructure, etc. externally, but for your internal infrastructure as well. But secondly, how do you ensure remote clients that are perhaps untrusted in nature can access your private data as an enterprise? These are all really hard problems that you've kind of solved in previous paradigms with APIs, but we really don't have a good way of solving it at the moment. So just going back to the registry point, it's really useful to think of where we are and where we want to go. The registries are really useful. And I don't think there's any discussion that here where we're having where we think they're not useful. We really proud of it. We're really happy we helped develop this. But it's really important to realize that the registry is simply incomplete for an enterprise. And once, like funny about this, is that MCPs are specifically designed, if you attended David's talk earlier today, MCPs are specifically designed because they allow themselves to be so much more useful for enterprises. And there's this kind of gap which the protocol allows for, that we have yet to build into the system as well. And these include things like authentication, but also access control, observability, and credential management. These are all things that enterprises need in the critical part, but are simply not working. So now that we have this happening, what do enterprises do right now? What they do is something like this, where every single team now with Claude Code and explosion of coding across various surfaces can now start developing MCPs. But suddenly find out that they can't actually get them deployed. But even if they want to get them deployed, the MCPs often can't use the tools they want to. Those tools can't give them the correct access. And security teams, on the other hand, are also pretty justified how they're going about it, because they're often overloaded and they're often unable to see which MCPs they want to go through, which they want to allow. And finally, at the company level, CEOs and C-sweets are like, why are my MCPs not working correctly? Why are my agents ineffective? Why can't your agents actually be the thing that we all thought it was going to be? And so this bottleneck, which we're seeing right here, is something we need to solve. We're going to ensure that security teams are overloaded, that users are given the freedom to actually develop their own MCPs, and organizations have visibility into all of them. And so what I'm going to tell you is that this problem where enterprises stay with the hamps for the MCP tools is going to fundamentally restrict the protocol and hurt agents until you really go and solve this. And I think it's worth zooming out at that moment, right? It's like, I think it's really valuable to think how important these paper cuts are and how valuable it is to try and invest the time to try and solve it super, super well. On to why we think the gateways are a better solution. I think this is a very good way to build intuition. The core intuition here is, at a point in which almost all of your teams can build MCP servers really well, or have the ability to theoretically be able to do so, because they're simply using coding agents that can understand the structure of the servers very well, that are able to understand what the tool definitions look like, what you should want, what access controls look like. The really important thing for security teams and enterprises that want to allow us to decentralize is they establish a root of trust. And so we think that the goal for any security team is to bless one platform. And this is, if I take one thing away from the stock, I would really suggest it be this slide, because it's irrelevant like, you might want to use a gateway and I'm not going to be talking to you through this, but I think this intuition is really the intuition I would really want to stress, because enterprises that are able to do this in our experience, we've done this internally and this externally too, are able to explore the usage of MCPs and thereby explore the usage of how powerful their agents are. And it's worth obviously coming back here and saying like, you know, MCPs, the usage is exponential, every good MCP you have helps all of the agents in your company. And so doing something like this has knock on effects beyond just that one MCP. So now that we think that, you know, our platform is really useful, let me tell you why I think gateways and I'll define it for you are a good way of doing this. So a gateway as a black box definition of it is simply a middleman, a sort of middle layer in between your MCP servers and they can be numerous into the hundreds and any MCP client. Notice the diagram here is extremely simple and it leaves a lot to be filled in. But what I really want to talk about is what we want to get out of the gateway. Things like authorization, authentication, observability, ensuring that you have correct connectivity between clear secure connections between your MCP client which might be untrusted and internally and also finally, you're able to easily host and deploy any new MCP server. What this allows for is that any new MCP server now does not have to deal with any of these five things. And a team that wants to add a new server only needs to care about what is the business logic. So your legal team which wants to review contracts only needs to care about, okay, if a contract comes in, this is what I want to be seen, this is how a red line should happen, this is how you should escalate to different people. They don't need to ensure who accesses this, how often can it be accessed, how do I know it's being accessed correctly, how do I know it's scalable and if I want to have new agents come in, these are all things you need to worry about. And that's a really, really used for middle layer to have because actually in the world we live in, your legal team can build the MCP server on their own. They aren't forced to go back to a new technical team and build it, right? And so if you really do want to live in that world, a gateway is a fundamental piece of the infrastructure. What does a gateway contain? Now there's like multiple definitions of gateway is we're going to give you examples, but in my mind there are normally these components which usually exist within it. You know, I'm not going to be like this is hard and fast, this is neither exhaustive, nor the only, like without these, like there's not all required. But what you would really like to do to achieve the goals I just achieved, I just talked about, is you kind of want to wait to do auth, you want to wait to do access control using roles, you want to wait in route using a proxy such that any MCP client can only see your gateway and the gateway then can route to the individual MCP servers which treat the gateways the only trusted endpoint. You want a way to ensure you have a tunnel which is a secured connection, you want to have a sub registry which is your MCP servers internally and finally you would want to have any additional tooling, tooling like a CLI for a gateway such that anyone who wants to create a new MCP server in your company can easily create one because the gateway is a quick and easy CLI that not you, not that team but the agent that team is using that Claude Core or something else can easily understand. These are all parts that when put together become really powerful because someone who's just wants to create a new MCP server can use the gateway CLI and just easily integrate with these five components and then completely focus on the MCP server. And that's why we really think that making that kind of one time investment which hopefully doesn't require a lot of maintenance and something you can easily do with agents would lead to several knock on benefits. Just like a higher level of view what this gives you. So we already talked about this in terms of the listing of what we think is required but just looking at once we have this you have a vision of a gateway which can give you your access authentication very easily you might have your own IDP which you can plug in. You can have delegated identity in terms of users and agents. This is something we think is going to be really important into the coming year where we think agents are going to require newer and novel definitions of identity that you can uniquely define and think about and scope for your enterprise using a gateway. We'll ensure that you have one access control panel for all of your agents and MCPs and your access control can be scoped depending on whether team is accessing it, whether users accessing it, whether another employee is accessing it. And finally observability and I think observability here is nuanced in the sense that you not only want usage metrics to reflect what MCPs are being used but you also kind of want to know how your tools being defined. In a world where MCP protocol is itself being developed so rapidly you kind of want to see how to add what are your load bearing tools and how do you better adapt them to meet the needs of your various agents. So I think this is really, really cool and really useful. Sometimes some people often say that it sounds too good to me true but I really encourage you to try and take a look at this and try and see where you can go from there. But let's say you have a gateway now. You've already talked about the minimum requirements. I think there's a lot of exciting worlds that you get or very easy follow on almost field lunches you kind of get from there. The first is it's very easy if you do add any new surface. So you can easily have it MCP servers now plug into claude.ai, they can easy plug into Claude Code, they can easy plug into Claude Code work because why? Because all of them are kind of listening to the same gateway and you kind of you need to do it one time. Compare that to the world where you have 40 different MCP servers and some MCP servers are better configured for only one of these surfaces and one of these clients. This is really important because this kind of ensures that you can be kind of invariant to any new surface that comes up and I know like this is something that sounds interesting coming from me but it's really, really useful for any new enterprise. I really, really use of any enterprise to do this. The second is you have far more secured connections that can be built in. Currently your MCP servers often have access to sensitive data internally and you, any enterprise, are worried about if I send this out to another client is that data going to be exfiltrated, what happens to my data? How do I ensure that my literally years and years of work doesn't go away? You can now invest in much more secured connections between the MCP servers that are a brilliant MCP server and your client that is completely encrypted and can ensure that you have root trust in what kind of data we sent. This is really important. I think like you know we've often done, you've often made MCP servers with kind of play data and things that you know enterprises can't really use but for enterprises to actually derive the exponential value they can get from this, this is something we need. The third is fast iteration. The real value in like ensuring your teams can be decentralized completely is going to be that they can iterate and develop their own workflows much faster. If the legal team is able to quickly just change their illegal MCP rapidly and iterate on it without repeated security reviews that has a massive effect which can just, which just builds upon itself. So this is something that shouldn't be underrated. The fourth is that you get very much more standard primitives. So any new MCP server that you want to build kind of has to adhere to primitives that are within the enterprise and how the enterprise wants to go about it. A common request you know a common problem enterprises have is like how do I ensure said AI agent meets my standards in operating procedures. A gateway is a way of encoding that. A gateway is a way of you being like these are my standard procedures, these are the primitives I want to see, these are the tools I expect and these are the things I don't want to see. That's a very quick way of encoding how you as an enterprise want to behave. The fifth is probable credentials. What we currently have is certain MCP servers will only accept one type of user authentication and it's very hard to kind of make sure it becomes like you can have a company wide one or a team wide one or something with service accounts. These are all things which are often useful in different cases and that becomes easier with a gateway because a gateway allows any new MCP server to easily support new credentials and swap it in and out in an intelligent manner. And then finally it's scalable right like if you have 40 MCP servers that need to scale to from tens to hundreds to thousands to hundreds of thousands of agents that's a really hard surface to maintain. A gateway which is able to take all these requests in and farm it out in an intelligent manner is a far better place for your teams to focus on. Finally this is not something that we think is going to be like we're telling you out of the blocks. We have examples of this both in the open source. You have providers, something in house but this is also something we can help with. This is something I do in my day basis. If you're interested I'd love to talk to you about this after this. But just finally zooming out right I want to take these last few minutes to think about where we're going with this. I like pitched a version of the MCP world to you that you know sound school probably works but does this really work in hundreds of things you've been hearing over this conference. I think what we want to ensure is larger picture where things are going is you want to separate the agent harness from where your data lives. We have many more surfaces coming up. We see an explosion of agents but those agents shouldn't be tightly coupled to how your data structure and how your MCPs are structured. An example of this is just a pure definition of an agent should like when you have tens of thousands of the orange box on the left you don't want to ensure that it has to be opinionated. You don't want the things on the right to be opinionated on how this works. We have an example of this which is released recently. Just as an example of this right now, if you have an MCP gateway you can easily connect to Claude management agents which is released recently but you can also build it internally with your own Claude Agent SDK as well. This is just an example from the Claude ecosystem. Think about the value of this. As an enterprise you now have the ability to quickly decide which agents you want to keep in house, which agents you want to have outside but that becomes an invariant decision. The gateway to millions regardless. What I'm trying to tell you is that the gateway is an investment will allow you to give you the flexibility to try and meet the wide ranging agent needs of the future and that's going to be really, really exciting. That allows you to not have to think that much about agent design at the moment but it also allows you to really invest very strongly in open-ended MCP gateway primitives. Just in summary, I would say three main things here. The first and most important takeaway is to invest in common infrastructure, to not try and roll your own MCPs and to ensure your teams can build their own MCPs. Second, we really think gateway to secure connections allow you to build a root of trust. Third, that moves towards the world where we think the agent harness is better be able to separate from your data layer. So yeah, thank you so much. If you interested in any of this, I'd love to talk and I'll talk. Thank you so much.
TL;DR
- Enterprises face significant challenges in deploying and managing Multi-Channel Protocols (MCPs), struggling with observability, access control, and security, which hinders the effectiveness of their AI agents.
- The recommended solution is to implement a "gateway" as a central middle layer between numerous MCP servers and clients, establishing a single root of trust for enterprise security and management.
- A gateway abstracts critical infrastructure concerns, enabling decentralized development of MCPs focused purely on business logic, accelerating iteration, and ensuring scalable, secure agent deployments.
Takeaways
- Enterprises struggle with MCP deployments due to opaque observability, complex access control, and security vulnerabilities, limiting the utility of their agents.
- The open MCP standard and public registry are valuable but lack essential enterprise features like built-in authentication, detailed access control, granular observability, and robust credential management.
- A "gateway" acts as a centralized middle layer, providing a crucial root of trust by managing all interactions between diverse MCP servers and various MCP clients within an enterprise.
- Gateways allow teams to focus solely on the business logic of their MCPs, as the gateway handles common enterprise requirements such as authorization, authentication, secure connectivity, and simplified deployment.
- Essential components of a robust gateway include an authentication system, role-based access control, a routing proxy, secure tunnels, an internal sub-registry of MCPs, and a CLI for easy integration.
- Implementing a gateway facilitates faster iteration, ensures adherence to standard operating procedures, enables more secure data connections, supports flexible credential management, and provides better scalability for agent deployments.
- This architectural approach promotes the separation of the agent "harness" from the underlying data layer, offering enterprises the flexibility to integrate various agent technologies while maintaining consistent security and access policies.
Vocabulary
MCPs — An open standard protocol designed for agents to interact with various tools and services, facilitating communication and operations across different systems.
Observability — The ability to understand the internal state of a system (e.g., MCP usage, performance) by examining its external outputs, crucial for monitoring, debugging, and improving operations.
Access Control — Mechanisms that dictate who (users or agents) can access specific resources (like MCP servers or tools) and what actions they are permitted to perform.
Data Exfiltration — The unauthorized transfer of sensitive data from a secure network or system to an external location, a critical security risk.
MCP Registry — An official, centralized listing of available MCP servers, serving as a directory for discovering and connecting to various MCP-compliant tools.
Gateway — A crucial middle layer acting as a single point of entry and control for numerous MCP servers, managing authentication, authorization, routing, and security for MCP clients.
Root of Trust — A highly secured and trusted component within a system (e.g., a gateway) that forms the foundation of its security architecture, from which other security assurances derive.
Business Logic — The core set of rules and processes specific to a particular application or service (e.g., how an MCP processes a legal contract), distinct from underlying infrastructure concerns.
IDP (Identity Provider) — A service that creates, maintains, and manages identity information for principals (users, agents) and provides authentication services to applications.
Agent Harness — The framework or infrastructure within which an AI agent operates, distinct from the actual data and services it interacts with, allowing for flexible agent deployment and management.
Transcript
So everyone, I'm Karan Sampath. I'll be talking to you about how we anthropic think about MCPs in the enterprise. I've alternatively titled it, I think what actually is why we think database are all you need. So before I go into the talk, I'm going to put you a little bit about me. I was, I'm a photo-plot engineer at Anthropic. That's why I'm outside the US. A lot of my work includes working with enterprises on things like MCPs and I also work on an internal use cases. In this talk, I'm going to be positing to you what we think the problems with enterprises, what enterprises face with MCPs today, why we think gateways and the necessary implications that come out of it are the best way to fix a lot of these problems and what is that, how does that align with our future vision for agentic deployments. So before we go on, I know a lot of you already know this, I'm going to quickly run through this, but just a very quick overview of MCPs as it is relevant today. The first is of course, we all know it's an open standard that was created, most of us know that at Anthropic. There is an official registry today which contains over thousands of servers and this has grown rapidly over the last year. And we see this happening that individual companies all the time are building new servers very quickly and are trying to ensure that they stay ahead and try to adhere to this protocol nowadays. But still, even if this happens, we see a major problem where enterprises try to use it. Enterprise is struggling to deal with what they believe the way it able to take. Things like observability. When they want to know who's using my MCP, who's using these tools, how do I ensure that the care people are using it, and how do I know how to develop on certain parts of the MCP protocol, which parts of my tools aren't working properly. These are something that's simply completely opaque to enterprises today. And in this access control, something just touched upon already. How do I ensure the correct users have access to the servers? Things like ensuring that certain servers are scoped correctly. Tools are only made, are only allowed for certain groups of servers. If you're working on observability MCP, you might want the entire company to have view into why, which things are failing. But only certain people to have the ability to actually change things and update new dash points. These are the kind of things that currently quite hard to do with MCP servers. And honestly, not something that we as a community have worked on enough. And finally, security. And I like to think that the three of these are almost like a three-headed hydrant in some ways. Security is a wide range of things. I like to think not only in terms of the MCP server, where you know, you enterprise the one, how do you verify whether the server is safe. It has the correct protocols and the correct ways of ensuring data. Exfiltration doesn't occur. Things like the tools can't be used in a harmful way, both for infrastructure, etc. externally, but for your internal infrastructure as well. But secondly, how do you ensure remote clients that are perhaps untrusted in nature can access your private data as an enterprise? These are all really hard problems that you've kind of solved in previous paradigms with APIs, but we really don't have a good way of solving it at the moment. So just going back to the registry point, it's really useful to think of where we are and where we want to go. The registries are really useful. And I don't think there's any discussion that here where we're having where we think they're not useful. We really proud of it. We're really happy we helped develop this. But it's really important to realize that the registry is simply incomplete for an enterprise. And once, like funny about this, is that MCPs are specifically designed, if you attended David's talk earlier today, MCPs are specifically designed because they allow themselves to be so much more useful for enterprises. And there's this kind of gap which the protocol allows for, that we have yet to build into the system as well. And these include things like authentication, but also access control, observability, and credential management. These are all things that enterprises need in the critical part, but are simply not working. So now that we have this happening, what do enterprises do right now? What they do is something like this, where every single team now with Claude Code and explosion of coding across various surfaces can now start developing MCPs. But suddenly find out that they can't actually get them deployed. But even if they want to get them deployed, the MCPs often can't use the tools they want to. Those tools can't give them the correct access. And security teams, on the other hand, are also pretty justified how they're going about it, because they're often overloaded and they're often unable to see which MCPs they want to go through, which they want to allow. And finally, at the company level, CEOs and C-sweets are like, why are my MCPs not working correctly? Why are my agents ineffective? Why can't your agents actually be the thing that we all thought it was going to be? And so this bottleneck, which we're seeing right here, is something we need to solve. We're going to ensure that security teams are overloaded, that users are given the freedom to actually develop their own MCPs, and organizations have visibility into all of them. And so what I'm going to tell you is that this problem where enterprises stay with the hamps for the MCP tools is going to fundamentally restrict the protocol and hurt agents until you really go and solve this. And I think it's worth zooming out at that moment, right? It's like, I think it's really valuable to think how important these paper cuts are and how valuable it is to try and invest the time to try and solve it super, super well. On to why we think the gateways are a better solution. I think this is a very good way to build intuition. The core intuition here is, at a point in which almost all of your teams can build MCP servers really well, or have the ability to theoretically be able to do so, because they're simply using coding agents that can understand the structure of the servers very well, that are able to understand what the tool definitions look like, what you should want, what access controls look like. The really important thing for security teams and enterprises that want to allow us to decentralize is they establish a root of trust. And so we think that the goal for any security team is to bless one platform. And this is, if I take one thing away from the stock, I would really suggest it be this slide, because it's irrelevant like, you might want to use a gateway and I'm not going to be talking to you through this, but I think this intuition is really the intuition I would really want to stress, because enterprises that are able to do this in our experience, we've done this internally and this externally too, are able to explore the usage of MCPs and thereby explore the usage of how powerful their agents are. And it's worth obviously coming back here and saying like, you know, MCPs, the usage is exponential, every good MCP you have helps all of the agents in your company. And so doing something like this has knock on effects beyond just that one MCP. So now that we think that, you know, our platform is really useful, let me tell you why I think gateways and I'll define it for you are a good way of doing this. So a gateway as a black box definition of it is simply a middleman, a sort of middle layer in between your MCP servers and they can be numerous into the hundreds and any MCP client. Notice the diagram here is extremely simple and it leaves a lot to be filled in. But what I really want to talk about is what we want to get out of the gateway. Things like authorization, authentication, observability, ensuring that you have correct connectivity between clear secure connections between your MCP client which might be untrusted and internally and also finally, you're able to easily host and deploy any new MCP server. What this allows for is that any new MCP server now does not have to deal with any of these five things. And a team that wants to add a new server only needs to care about what is the business logic. So your legal team which wants to review contracts only needs to care about, okay, if a contract comes in, this is what I want to be seen, this is how a red line should happen, this is how you should escalate to different people. They don't need to ensure who accesses this, how often can it be accessed, how do I know it's being accessed correctly, how do I know it's scalable and if I want to have new agents come in, these are all things you need to worry about. And that's a really, really used for middle layer to have because actually in the world we live in, your legal team can build the MCP server on their own. They aren't forced to go back to a new technical team and build it, right? And so if you really do want to live in that world, a gateway is a fundamental piece of the infrastructure. What does a gateway contain? Now there's like multiple definitions of gateway is we're going to give you examples, but in my mind there are normally these components which usually exist within it. You know, I'm not going to be like this is hard and fast, this is neither exhaustive, nor the only, like without these, like there's not all required. But what you would really like to do to achieve the goals I just achieved, I just talked about, is you kind of want to wait to do auth, you want to wait to do access control using roles, you want to wait in route using a proxy such that any MCP client can only see your gateway and the gateway then can route to the individual MCP servers which treat the gateways the only trusted endpoint. You want a way to ensure you have a tunnel which is a secured connection, you want to have a sub registry which is your MCP servers internally and finally you would want to have any additional tooling, tooling like a CLI for a gateway such that anyone who wants to create a new MCP server in your company can easily create one because the gateway is a quick and easy CLI that not you, not that team but the agent that team is using that Claude Core or something else can easily understand. These are all parts that when put together become really powerful because someone who's just wants to create a new MCP server can use the gateway CLI and just easily integrate with these five components and then completely focus on the MCP server. And that's why we really think that making that kind of one time investment which hopefully doesn't require a lot of maintenance and something you can easily do with agents would lead to several knock on benefits. Just like a higher level of view what this gives you. So we already talked about this in terms of the listing of what we think is required but just looking at once we have this you have a vision of a gateway which can give you your access authentication very easily you might have your own IDP which you can plug in. You can have delegated identity in terms of users and agents. This is something we think is going to be really important into the coming year where we think agents are going to require newer and novel definitions of identity that you can uniquely define and think about and scope for your enterprise using a gateway. We'll ensure that you have one access control panel for all of your agents and MCPs and your access control can be scoped depending on whether team is accessing it, whether users accessing it, whether another employee is accessing it. And finally observability and I think observability here is nuanced in the sense that you not only want usage metrics to reflect what MCPs are being used but you also kind of want to know how your tools being defined. In a world where MCP protocol is itself being developed so rapidly you kind of want to see how to add what are your load bearing tools and how do you better adapt them to meet the needs of your various agents. So I think this is really, really cool and really useful. Sometimes some people often say that it sounds too good to me true but I really encourage you to try and take a look at this and try and see where you can go from there. But let's say you have a gateway now. You've already talked about the minimum requirements. I think there's a lot of exciting worlds that you get or very easy follow on almost field lunches you kind of get from there. The first is it's very easy if you do add any new surface. So you can easily have it MCP servers now plug into claude.ai, they can easy plug into Claude Code, they can easy plug into Claude Code work because why? Because all of them are kind of listening to the same gateway and you kind of you need to do it one time. Compare that to the world where you have 40 different MCP servers and some MCP servers are better configured for only one of these surfaces and one of these clients. This is really important because this kind of ensures that you can be kind of invariant to any new surface that comes up and I know like this is something that sounds interesting coming from me but it's really, really useful for any new enterprise. I really, really use of any enterprise to do this. The second is you have far more secured connections that can be built in. Currently your MCP servers often have access to sensitive data internally and you, any enterprise, are worried about if I send this out to another client is that data going to be exfiltrated, what happens to my data? How do I ensure that my literally years and years of work doesn't go away? You can now invest in much more secured connections between the MCP servers that are a brilliant MCP server and your client that is completely encrypted and can ensure that you have root trust in what kind of data we sent. This is really important. I think like you know we've often done, you've often made MCP servers with kind of play data and things that you know enterprises can't really use but for enterprises to actually derive the exponential value they can get from this, this is something we need. The third is fast iteration. The real value in like ensuring your teams can be decentralized completely is going to be that they can iterate and develop their own workflows much faster. If the legal team is able to quickly just change their illegal MCP rapidly and iterate on it without repeated security reviews that has a massive effect which can just, which just builds upon itself. So this is something that shouldn't be underrated. The fourth is that you get very much more standard primitives. So any new MCP server that you want to build kind of has to adhere to primitives that are within the enterprise and how the enterprise wants to go about it. A common request you know a common problem enterprises have is like how do I ensure said AI agent meets my standards in operating procedures. A gateway is a way of encoding that. A gateway is a way of you being like these are my standard procedures, these are the primitives I want to see, these are the tools I expect and these are the things I don't want to see. That's a very quick way of encoding how you as an enterprise want to behave. The fifth is probable credentials. What we currently have is certain MCP servers will only accept one type of user authentication and it's very hard to kind of make sure it becomes like you can have a company wide one or a team wide one or something with service accounts. These are all things which are often useful in different cases and that becomes easier with a gateway because a gateway allows any new MCP server to easily support new credentials and swap it in and out in an intelligent manner. And then finally it's scalable right like if you have 40 MCP servers that need to scale to from tens to hundreds to thousands to hundreds of thousands of agents that's a really hard surface to maintain. A gateway which is able to take all these requests in and farm it out in an intelligent manner is a far better place for your teams to focus on. Finally this is not something that we think is going to be like we're telling you out of the blocks. We have examples of this both in the open source. You have providers, something in house but this is also something we can help with. This is something I do in my day basis. If you're interested I'd love to talk to you about this after this. But just finally zooming out right I want to take these last few minutes to think about where we're going with this. I like pitched a version of the MCP world to you that you know sound school probably works but does this really work in hundreds of things you've been hearing over this conference. I think what we want to ensure is larger picture where things are going is you want to separate the agent harness from where your data lives. We have many more surfaces coming up. We see an explosion of agents but those agents shouldn't be tightly coupled to how your data structure and how your MCPs are structured. An example of this is just a pure definition of an agent should like when you have tens of thousands of the orange box on the left you don't want to ensure that it has to be opinionated. You don't want the things on the right to be opinionated on how this works. We have an example of this which is released recently. Just as an example of this right now, if you have an MCP gateway you can easily connect to Claude management agents which is released recently but you can also build it internally with your own Claude Agent SDK as well. This is just an example from the Claude ecosystem. Think about the value of this. As an enterprise you now have the ability to quickly decide which agents you want to keep in house, which agents you want to have outside but that becomes an invariant decision. The gateway to millions regardless. What I'm trying to tell you is that the gateway is an investment will allow you to give you the flexibility to try and meet the wide ranging agent needs of the future and that's going to be really, really exciting. That allows you to not have to think that much about agent design at the moment but it also allows you to really invest very strongly in open-ended MCP gateway primitives. Just in summary, I would say three main things here. The first and most important takeaway is to invest in common infrastructure, to not try and roll your own MCPs and to ensure your teams can build their own MCPs. Second, we really think gateway to secure connections allow you to build a root of trust. Third, that moves towards the world where we think the agent harness is better be able to separate from your data layer. So yeah, thank you so much. If you interested in any of this, I'd love to talk and I'll talk. Thank you so much.