What does Enterprise Ready MCP mean?

[upbeat music] Thank you everyone for coming here.

I hope you're, uh, excited to figure out with me what enterprise-ready MCP means. Uh, I'm not sure a month ago e- people even fully understood what MCP meant. Um, so we're all on this journey together.

Um, but hopefully it should be fun. So I was chatting to a good friend and colleague who is, is giving a talk tomorrow on building MCP servers and what it looks like to build that out, and his question was:

how do the tools of today map to the AI systems of tomorrow? We already have some kind of kn- concept of enterprise-ready tooling and building tools for the enterprise and production.

What does it actually mean for MCP? And something I kind of, you know, wanna talk through today, chat with you guys. So, for a long time, for, you know, several years now, we've had the model of you are a user, you talk to an AI.

You talk to a chatbot, it does stuff. The AIs had tool calling, now they have MCP. This is the MCP logo, which is just a way of interfacing between the AI and an external resource of some kind to do something.

Right? It can just be a database access, it can be performing some complicated computation, it can be pulling in a prompt. There's lots of stuff in the MCP spec that frankly you should go and read.

There's more there than most people realize. We're also seeing workloads like this, where an IT admin spins up an asynchronous workflow, which is... we're gonna call an AI agent, which automates some process that is, you know, kind of headless and is going and doing a thing.

We're trying to manage that. That is then gonna use MCP to access external tools that might be secured, might be internal enterprise tools, which introduce some fun problems. I also, for the sake of this kind of diagram of what is the future gonna look like, wanna introduce this line here, just to throw some, some spanners in the

works, of users in a company using their chatbot, which makes a call to an MCP server, which then goes and queries an AI workload, an AI agent that's existing in the cloud performing some operation.

And so with this kind of diagram of what could happen, I want us to figure out what we need to fix to make this really useful and production-ready. Okay.

Why am I, why am I talking to you? Uh, I work for WorkOS, which is an enterprise security vendor, um, which I'll talk about in a second. I'm also a research fellow at Stanford working on safety for AI agents, and just finished a PhD where I got to wear this really funny, silly hat, um, just a couple

of months ago. Um, OpenAI, uh, uh, WorkOS is a, uh, enterprise security vendor that sells to all of the AI labs, because the AI labs do not wanna do the really painful, annoying work to scale the security and auth operations into the enterprise.

And so we've been thinking a lot about what it means to provide the glue that means people can build agents and then just seamlessly scale it and sell it to everyone.

And so I wanna just tell you all the answers today, whether or not you wanna use us. So let's go through the agent journey. We're all here trying to build agents.

Um, let's tell a, tell a story. So I found this great API, um, that you can query and it will feed a bunch of goats that you can then see on a live stream.

Um, this is a real API that you can go and use. And so naturally you do what anyone would do, and you're gonna build an emotional support bot for employees at a company to build a SaaS.

Um, and you give it tool use to query this. Now, this is fine 'cause it's a one-time query, but frankly, tool use kind of sucks. We've had it for years now.

Not as many people are using it. It's really painful. A lot of things go wrong, which is why the Model Context Protocol got invented. So why would you move to, to MCP?

One, there is this really robust ecosystem of tools and providers, security tooling, that lets you interface between the model and the resource to make things safe and reliable. It's also really good at providing standardization to the models, so the models are getting really good at learning how to use this, either through RL or just kind of, you

know, good evals on MCP usage. It also runs a stateful connection, which means you can do, you know, better security, better management, be- better context management in the way you're passing in to an AI model.

And maybe you're doing it just 'cause everyone's doing it and, and why not have some fun, right? It is genuinely quite fun to build an MCP server. You can make cool things out of it.

So what do we do? We make our local server, right? Hopefully, at some point everyone's had a little play with this. Uh, you tweet out, check out my local host.

Um, you know, try and get your friends to play with it. It's great. It's hacky. It's not particularly useful to anyone except yourself. You can build some fun local servers.

Uh, frankly, this is where we see a lot of people building MCP right now. It's an internal demo. You're gonna see if you can connect it to an API.

Cool, it works, and then we don't go much further than that.

And so kind of the next step where everyone has been talking about, a lot of discussion in the community is how do we do this really robustly, is just adding authentication and authorization to these workloads, which is truthfully right now the main thing you need to do.

These are links to docs that will help you do it. Uh, through there, you can come and chat with me and I will sit down with you anywhere in the world and help you build a really robust, secure MCP server and figure out some pain points.

Um, you should not have an external API that is unauthenticated, that has no access controls on it. Uh, things will go very wrong. So super simple. You make people log in, you scope, you have an admin privilege so that no one is feeding the goats too much.

You know, make sure goats are well-maintained and kept safe. Um, and maybe if you're doing this internally with an organization, you put in a VPC, you know, do a NAT gateway to make sure no one can access that they shouldn't.

But everyone, turns out, in your organization loves your goat emotional support tool, 'cause who wouldn't? And so you do what, what anyone would do. You, you say, "Let's make it public.

Let's make a public MCP server that people can add to their Claude, that people can build applications on top of. Let's add a Stripe in there to make sure they've got payment rails."

It just sends back a URL that you can call out to click things. It's pretty straightforward. Um, you give some users free credits 'cause, you know, this is how apps work, uh, and you put it on a cloud hosting solution.

Tons and tons of them are spinning up. I get ads and announcements about them every day.

Fundamentally, MCP servers are just a normal workload, which means a lot of the cloud hosting providers can support whatever you need to host. Um, and so there's, there's lots and lots that we can discuss there.

But you did this really well, and everyone loves goat feeding and emotional support, so you end up going viral. You've got a billboard on the highway. MrBeast tweets you out.

What happens? Now you end up with having way too much traction, right? You get free credit abuse on the signups. Uh, this is something that we see a, a ton of AI companies that we support happening, is AI companies give you some free credits to onboard you, but at the end of the day, they're just querying an

AI API, which means that folks will sign up for an account, abuse those free credits, and cycle back. One of the AI vendors, uh, that we work with, someone was using their free credits to write fan fiction stories, um, by just...

Uh, this is not an application designed for writing fan fiction, just because it- it's a convenient way to get free credits. And so you end up needing bot blocking on signups.

Um, you need kind of robust controls over the whole auth stack to make sure nothing goes wrong. Uh, you're gonna end up needing, uh, input validation so that no one prompt injection attacks your goats.

Gotta keep them safe. Uh, and then there's a lot of niche stuff that happens with MCP. So, uh, MCP servers dynamically register their clients with the server, which means if you have any developer admin dashboard, application dashboard, that's tracking the applications that you've created, they will suddenly be flooded with MCP servers 'cause of this weird choice in

how MCP servers register as applications. And so essentially, every auth stack you need, every, like, management tooling you need, needs to be adapted for MCP. And so this is something that we provide, but also, like, a bunch of other people are working on, and something to be conscious of, is if you scale, things will start going very

wrong. And so everyone loves your MCP server. That's super cool. Maybe it's just an AI, AI agent wrapping it, or you're selling the core MCP server. You wanna sell into enterprise.

What do we have to do? This is like a well-worn SaaS path that we're gonna go through. You have to do all of the boring stuff. You have to do the SSO, the lifecycle management.

You're gonna have to do provisioning. Um, Block, uh, are this super cool company, um, that developed Goose, and internally, they've been provisioning AI, like, access to this client, this chat client, as well as MCP servers.

And I really see a future where enterprises use SSO to provision access to a ton of internal resources exposed via MCP that then employees can chat with as a, you know, default way that employees are encouraged to use AI to automate workflows.

And so if you're going to sell into the enterprise, you end up needing all this, like, nitty-gritty stuff that really sucks. Fine-grained access controls that are highly performant, a really robust audit logs, um, for instant responses.

A lot of the regulations that exist right now, like GDPR, um, call out explicitly additional requirements on logging for AI workloads because the regulators like to regulate. And so your audit logs that exist normally have to fit a very specific set of requirements which are not well-supported widely.

And so something to think about as you scale these workloads. Um, and you need stuff like data loss preventions so that people aren't, like, uploading random things to MCP servers.

This becomes a significant risk when people are just chatting wildly with a ton of servers.

And so now you have an enterprise-ready server-ish, 'cause there are a lot of other questions to answer. Thi- this is a talk that was, was hidden to tell you the answers, but truthfully, the answers aren't entirely known yet, and the protocol is very rapidly developing.

And so this is the, the, the diagram we started off with. This stuff's super easy, right? How does a user log into an AI chatbot? Uh, done. We've solved that.

How do AI systems connect to MCP servers? This is something that's being worked on. It's pretty straightforward. We can do auth there. You can scan those QR codes from before, build it, and you have a production-ready MCP server.

MCP servers connecting to external resources is pretty straightforward. It's not too hard to do. Can be a bit annoying, but you know, you have to pass your scopes and do it properly.

Um, IT admins managing AI workloads, pretty straightforward. And in theory, you know, the other end of MCP servers existing in your tenancy connecting to resources, bit of a pain point but can easily be built.

There are lots of open questions still as to how we do this. Um, how exactly remote asynchronous workloads can do headless auth into MCP servers with dynamic client registration, uh, and make sure that is, you know, they have correct authorization controls.

It's actually super hard, and things keep going wrong along the way. Um, how these asynchronous workloads call out to relevant users. Uh, there is a, a new RFC in the MCP spec for elicitation.

So when your model doesn't know what to do, it knows that it should ask a human being, and this is becoming supported as part of MCP, that it can go and call out towards a user, um, and say, "Please provide additional input that you need because I'm missing details."

So stuff like this is actively developing, and nothing is stable. Um, and then there's this very broad question that we're running into with AI workloads, um, of, uh, passing scope between different AI workloads, passing access control between AI workloads, where if you have the A...

We're talking about MCP. If you're using A2A protocol, you are just telling an agent mostly in vibes what it should or shouldn't do and relying upon the alignment of that model to make sure it doesn't misbehave.

And so actually passing robust authorization, you know, scopes, uh, communicating access controls, making sure that service account, that that AI workload might be, has the correct access, turns out to be a huge pain point in doing this.

So frankly, the cloud vendors are, are mostly solving the cloud hosting. I think the authorization and access control element of this is the hardest part of putting this into external enterprise workloads, um, and a big thing that needs to be filled.

So if you want to build fun things, we are actively building out this entire stack to sell to AI companies and startups. Uh, and if you go to the docs, we can build some cool stuff together.

Um, everyone is building interesting things right now, and, you know, it's fun to get into the nitty-gritty and, and see what bugs occur. And then as a thank you for all listening to this fun talk, uh, you cannot use this on your phones, to be clear.

You can buy this shirt only through MCP. [laughs]

Uh, the instructions are on the website. Uh, very briefly, if you'd like to see... Let me see if I can get out of this, um, and go to Cursor.

You have to add the MCP server. There are many ways to do this, but the way I'd recommend is just going into one of your AI, um, editors, uh, typing in the JSON that the website will give you.

This is, like, the easiest way to add. You'll see that it's turned on. You'll need to make an account because authorization, access control, et cetera. Um, and then you can say, "Please buy me a shirt."

Um, and of course the Wi-Fi, um, will not work. [laughs]

Beautiful. We'll need my mailing address. Uh, [REDACTED:location_address], um, WorkOS, and I want a medium.

And it knows my name. It's authorized. It- it's done a validation check on me. We've got a bot blocker on the signup so that people can't abuse my shirts.

And you'll see right there that we purchased a shirt. So let's go back to Keynote. Um, scan it, add it to your computer if you want, um, and you guys can have a free, very nice MCP shirt, uh, that I would love to share around.

Thank you very much. [outro music]