All right. Um 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 more catchily, is why we think gateways are all you need. Um so before I go into the talk, I'm going to quickly tell you a bit about me. I'm a forward deployed engineer at Anthropic, first one outside the US. A lot of my work includes working with enterprises on things like MCPs, and I also work on our 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 how does that align with our future vision for agent tech deployments.

MCPs is an open standard that was created at Anthropic. There is an official registry today which contains over thousands of servers, and this is growing rapidly over the last year. Individual companies all the time are building new servers very quickly, and are trying to ensure that they stay ahead and trying to adhere to this protocol nowadays. But still, even if this happens, we see a major problem when enterprises try to use it.

Enterprises struggle to deal with what they believe to be table stakes. Things like observability. When they want to know who's using my MCP, who's using these tools, how do I ensure that the correct 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.

Second is access control. How do I ensure the correct users have access to these servers? Things like ensuring that certain servers are scoped correctly. Tools are only allowed for certain groups of servers. If you're working in observability MCP, you might want the entire company to have view into which things are failing, but only certain people to have the ability to actually change things and update new dashboards. These are the kind of things that currently are 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 of the three of these is almost like a three-headed hydra. Security is a wide range of things. Enterprises want to know how do you verify whether a 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 externally and 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.

Registries are really useful, and I don't think there's any discussion here where we think they're not useful. We're really proud of it and we're really happy we helped develop this. But it's really important to realize that registry simply aren't complete for an enterprise. MCPs were 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 well, and these include things like authentication, but also access control, observability, and credential management. These are all things that enterprises need and are critical part, but are simply not working.

So now that we have this happening, what do enterprises do nowadays? What they do is something like this, where every single team now with Claude, you know, and explosion of coding across various surfaces, can now start developing MCPs. But suddenly find out that they can't actually get them deployed. Or 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 end 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, and which they want to allow.

And finally, at the company level, CEOs and C-suites 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 need to ensure that security teams aren't overloaded, that users are given the freedom to actually develop their own MCPs, and organizations have visibility into all of them. This problem where enterprises stay with a handful of MCP tools is going to fundamentally restrict the protocol and hurt agents until we really go and solve this. 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 well.

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. The really important thing for security teams and enterprises that want to allow this to be decentralized is they need to establish a root of trust. And so we think that the goal for any security team is to bless one platform.

Enterprises that are able to do this, in our experience, are able to explore the usage of MCPs, and thereby explore the usage of how powerful the agents are. MCPs usage is exponential; every good MCP you have helps all of the agents in your company.

A gateway, as a black box definition of it, is simply a middleman or sort of middle layer in between your MCP servers, and they can be numerous into the hundreds, and any MCP client. What we want to get out of the gateway are things like authorization, authentication, observability, ensuring that you have clear secure connections between your MCP client, which might be untrusted, and internally. And also finally, an easy way to 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 redline 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. A gateway is a fundamental piece of that infrastructure.

What does a gateway contain? There are normally these components: a way to do auth, a way to do access control using roles, a way to 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. 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 like a CLI for your gateway.

Someone who just wants to create a new MCP server can use the gateway CLI and just easily integrate into these five components, and then completely focus on their MCP server.

Looking at what this gives you: you have a vision of a gateway which can give you 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 where agents are going to require newer and novel definitions of identity. Observability here is nuanced; you not only want usage metrics, but you also kind of want to know how are your tools being defined. How do you better adapt them to meet the needs of your various agents?

There's a lot of exciting follow-ons or almost free lunches you kind of get from there. The first is it's very easy for you to add any new surface. You only need to do it one time. Compare that to the world where you have 40 different MCP servers. The second is you have far more secured connections. You can now invest in much more secured connections between your MCP server and your client that is completely encrypted. The third is faster iteration. If the legal team is able to iterate on their legal MCP rapidly without repeated security reviews, that has a massive effect. The fourth is that you get more standard primitives. A gateway is a way of encoding your standard operating procedures. The fifth is pluggable credentials, allowing 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. A gateway is a far better place for your teams to focus on.

I want to take these last few minutes to think about where we're going with this. We want to ensure the larger picture: we want to separate the agent harness from where your data lives. We see an explosion of agents, but those agents shouldn't be tightly coupled to how your data is structured and how your MCPs are structured.

If you have an MCP gateway, you can easily connect it to Claude managed agents which was released recently, but you can also build it into use it internally with your own Claude agent SDK as well. 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 remains regardless. The gateway is an investment which will allow you the flexibility to meet the wide-ranging agent needs of the future.

In summary, three main things: The first and the most important takeaway is to invest in common infra, to not try and roll your own MCPs, and to ensure your teams can build their own MCPs. Second, gateways for secured connections allow you to build that root of trust. And third, that moves towards a world where we think the agent harness is better separated from your data layer. Thank you so much.