Fost Singapore 2026 - The MCP Gateway: A Journey from Idea to Infrastructure.

In this talk, Benjamin Tindall discusses his experience building the Model Context Protocol (MCP) Gateway at Mimecast, a cybersecurity company. He explains the challenges faced in integrating customer-facing APIs with the demand for clients to utilize their own language models (LLMs). Tindall introduces MCP as a flexible protocol that allows for dynamic tool discovery and interaction at runtime, in contrast to traditional APIs. He outlines the development journey, including a proof-of-concept that led to a production-ready MCP Gateway, which streamlines user authentication and enhances security through a centralized OAuth-based system. The talk also covers lessons learned during the project, including the importance of flexibility in technology adoption and the evolving nature of MCP specifications. Tindall concludes with insights into the future of AI integration and the role of traditional software engineers in this new landscape.

Hi everyone. My name is Benjamin Tindall and today I'm going to talk about my story of building the MCP Gateway at Mimecast. So just a quick introduction about myself. I work for a company called Mimecast. It's a cybersecurity company for human risk, email collaboration and inside threats. Um in my current role I'm a senior principal software engineer in the platform. Um my areas of responsibility are architecture

for identity and access management, um API uh ecosystem and a new um area called agentic risk. Uh previously I was a founder of two health tech startups in the UK and USA before Mimecast. So to start with I want to ask you a couple of questions. Um how many of you are building APIs that your customers are using today? I imagine that's a quite a fair few

of you. how many have been looking at exposing MCP servers to your customers? So that's the gap in functionality that we faced at Mimecast. Um a lot of our customers have been asking us about using their own LLMs. Uh they want to bring their own AI agents and interact with data from And actually I think that's a gap that every enterprise with customer facing APIs is going

to have uh to close soon as well. Um if not now then very soon. Uh customers are beginning to expect kind of functionality. So let me start by explaining what MCP is. Um it stands for model context protocol. Um I've actually heard it uh referred to many times as the USBC for AI. Um so the idea is that uh if you imagine like USBC is like a

on a computer, the LLM is the computer and you can extend functionality by plugging in different MCP servers into the side of it. Um so in our situation Mimecast services are one of the plug one of the extensions you can plug in. Um so, actually um I found out about MCP from uh at the API Days conference in Singapore last year. the conference pretty much changed overnight

from being an API conference to an AI conference. And um it's from that presentation that a lot of my ideas for MCP and how we can apply it to our problems uh came from. It's worth also calling out that API callers and MCP callers are fundamentally different. Uh API callers um follow follow a very rigid contract. Um but MCP callers follow a much looser contract um where

the MCP tools and the parameters can be discovered at runtime. So, there's less of a need for versioning um and it has um a totally different trust model as well built in. So, first section I'm going to start talking about I'm going to talk about what we built and why. So, the journey. Um I attended the API Days conference um last year in April 2025. Um and

the first time I heard about MCP um immediately started thinking about how I could use it at Mimecast. Um as I mentioned before uh maybe but we we have an API strategy at Mimecast. Um it's a pretty strong API strategy. So, I started thinking, how can we expose our existing APIs to our elements? So, I spent from May to September building a use case for Mimecast. Um

I found a colleague um who works within one of the product lines, um is a good friend of mine, and is very passionate um in the area. Um and we spent 2 months defining the problem. Um we eventually end up building a POC and we made a uh recorded a video that uh then pitched to leadership. Um the good news is that leadership loved it immediately. Um,

then from September to October, we started building an MCP strategy after they bought in unconditionally. Uh, all this technology was very new uh, to a lot of people. Um, so it it required a lot of um, understanding and explaining. Um, we moved from having a POC as a side project to um, MCP being um, a roadmap project that we were able to prioritize. Um, it was also

at this time that I identified that in order to uh, for MCP adoption across the company to scale within engineering, we we would need a form of MCP gateway. And I'll explain um, about what the an MCP gateway is in a bit more detail later on. So in December, um, we shipped our first MCP server. Uh, we built an MCP server for one of our products called

Insider. Um, and the MCP server detects uh, well, it the Insider product detects insider risk within companies and the the MCP server allows you to surface those alerts and interact with them. We released this MCP integration into early access mode and we had customers connecting Microsoft services to their cloud LLMs. And this was working end-to-end. Then in February, uh, so two months ago now, uh, we released

the first version of our MCP gateway to production. Um, and I'll talk a bit more in detail about what that actually means in the next few slides. So the the the I'm going to talk a bit about the initial POC use case. So it started with a prompt. the prompt is, "Show me all threat events across my managed accounts for the last seven days." So it seems

like a It's straightforward prompt, but actually underneath it is quite complicated and um, so why do we use this as use case? Actually doing this is quite difficult to do with existing API endpoints. It's a complex set of steps that requires in this case we're dealing with partners who it requires them to have experience in how to build APIs. It requires them to understand topics such as

pagination, authentication, aggregation and actually it requires multiple steps. Right? So there's one which fetches threat events, there's one which fetches all accounts and then you have to iterate over those accounts to get all the threat events. Generally partners don't have the skill set to do this. Their their priorities are more around managing customers, managing their infrastructure. And to be honest I don't really think that they should

really need to have the skill set to write API clients in this They want to own the whole process end to end. They want to So that I thought this was a clean test of LLMs. Like it means that with LLMs we can customize things in a very very clearly. So I thought it would be very useful for for partners to use. So how it works. So

I've got a picture here on the right hand side of of what [snorts] a report looks like at the end. But the way it works is that a partner first installs the the Mimecast MTP server into their agent. So in this example it's Claude. And attaches their credentials to it. Then a partner administrator executes a In this example it was show me all for the last 7

days. Claude will then invoke an MCP tool to fetch list of accounts for that partner that they are the partners managing. The next step is that Claude then invokes another MCP tool for each of these accounts right to get the threat events for each of the accounts. And Claude will then aggregate this into a report. So, and as I said, there's a example on the right. this

actually worked really well. It worked end-to-end, and it was a very compelling use case for the business to for us to get started, to really think about MCP. So, I want to show a high level of how this works. So, um at a high level, we have three components. So, we have Claude Desktop, which is the uh the desktop version of the Claude AI um that the

customer's using. Uh we have a local MCP server, which um uh we built in-house, and that runs it plugs into Claude Desktop and runs within the runtime of Claude Desktop. And um inside it we have configuration uh in which we put the client uh the customer credentials as um I will token. Um and then this local MCP server makes uh REST API calls to the existing API

that we had. So, in this case it's the uh I was using the Mimecast threat API, which runs on our public API gateway. So, this worked really well, but there were a few issues with it. Uh firstly, as I mentioned, the credentials are in local config. So, uh we were storing uh OAuth credentials secrets in uh plain text file on the hard drive of the machine of

the user's machine. This is obviously not great from a security perspective. secondly, this only works for Claude Desktop. Um if we if we wanted to support other agents uh like Claude AI or ChatGPT, um it would we would wouldn't be able to do it this And thirdly, um we are performing a an MCP to REST translation on the uh the And um obviously that's not ideal. We

want this to be moved out somewhere where we have more control over it. So, then a few months later we released the early access MTP server for uh Menlo Security Risk. Um as I mentioned before, it allows the uh the administrator to action alerts and view alerts. So this design looks fundamentally similar to the POC, but it has a few improvements to it. Um we now have

a dedicated MTP server on the right-hand side. Um so instead of translating from REST to MCP um on the client side, we're now doing it or we're talking MCP throughout. So the native protocol is >> [clears throat] >> We also We also still have a local MCP server that was running within Cloud Desktop, but now instead it's a signed install installable binary. Um it's actually called in

the Cloud context an MCPB file. And um when the user connects that local MCP server, they're prompted to put in their credentials. Um and then Cloud manages those credentials and stores them securely within their environment. So obviously this is a lot more secure. So this worked well um and customers started using it immediately, but there were a few limitations still. Um firstly, um this approach only supports

tenant level OAuth credentials. Um By this I mean a customer um gets a set of credentials and installs it into their Cloud Desktop. It has no concept of uh what user is operating um the the the the agent at that particular time. So it means that we're quite limited in the kind of MCP actions that we can do. We need as we are security products, we need

to have a full end-to-end trace of um what happened, who did it, and the the exact person who did it. Secondly, the MCP server that we created is a publicly facing um MCP server. Um which means that we have to mitigate all kinds of public threats like denial of service attacks and elevation of privilege and that kind of thing. And lastly, it doesn't scale very well. So,

for one product, it's fine. But then, whenever we team engineering team within Mimecast who wants to build an MCP server does we'll have to probably duplicate things that duplicate the MCP server, duplicate the configuration, duplicate a lot of things. So, it gets messy. So, the ultimate solution that we built is called the MCP gateway, which is the gold standard Mimecast platform solution for us. It's a proper

OAuth-based gateway and it but it no longer uses local MCP servers. All these services that you see at the top of the screen are also Well, these two services are managed services as all this means is that authentication is now handled entirely by the gateway. The gateway uses OAuth, which is the standard, and and also supports user-level consent. So, by user-level consent, what I mean is that

a user, when they install it, they connect and they log in as themselves. And and that that context is pushed upstream. We no longer have credentials in local config files as well as a result. All major agents are now supported. So, we support Claude, Claude AI, which is the web-based version, OpenAI, Copilot, Gemini. Um, the MCP server is upstream. This in inside MCP server is now private.

It's it's hidden behind the MCP gateway and it's therefore protected from public threats. So, the gateway handles, as I said before, denial of service, elevation privilege, all this Um we also are able to do authorization at the gateway level. So, we do a high-level authorization at the gateway, and then we perform the more granular authorization at the MCP server level. I'll talk about this in a bit

more detail in the next slide. And it scales across products. Um we have one gateway um and we have many product MCP servers behind it. Um so, the teams can now focus on building their tools. Uh they just focus on the functionality they want to provide. They don't need to think about Um as an aside, um here I've I've listed the technologies that we use as well.

So, the MCP gateway uses um AWS Bedrock Agent Core Gateway. Um the authentication is using Amazon Cognito, and then the MCP servers behind it are using Spring AI. So, the four steps from um on on how to install how to connect the MCP gateway. The first step is to you log in to the Mimecast console um an admin as an administrator. The registers an application. this returns

a gives them a gateway URL, the MCP gateway URL. a set of set of client credentials, and a set of scopes. The admin then adds the URL and credentials um as a custom MCP connector to the agent. Um in this picture here, um this is ChatGPT. Um and and now now it's configured. Now, that was what an admin did. Now, the end user then goes into and

is and here ChatGPT, um they see the MCP gateway connector, they click connect, and now they're given uh they log in to the Mimecast login screen. And lastly, um um now it's installed and then user can now start prompting and asking questions. Um when they do this, the agent then connects to the MCP gateway and starts calling MCP tools. So, the MCP gateway gives us a few

additional benefits as well. And actually, a lot of these benefits are very similar to the kind of benefits you get from an API gateway. Um teams focus on tools. Um there's a single entry point for all MCP traffic. The authentication is centralized. Um we can do product level authorization. Um operational visibility. Uh we can see things like MCP adoption rates per tool performance, error rates, capacity planning.

Um all from one place. And lastly, cost control. We can control um how much is being used by doing things like rate limiting, spike arrest, uh having quotas for uh customers, etc. So, I'm going to talk about the security um in this in this in this uh project. I've broken this into two slides. So, um first thing I'm going to be talking about the inbound authentication. the

flow um so, the flow starts with the starting by initiating an OAuth authorization code flow against the OAuth provider. So, as I spoke about before, this is Cognito. So, the AI agent uses its OAuth client credentials to call the OAuth provider and gets itself an access token and uh refresh And also, the access token that's returned is scoped for that specific AI that's the first step. Um

the next step is that the AI agent then makes a call to the MCP gateway. Um the MCP gateway validates the token and scopes to make sure that it's meant for that for that this this token is meant for this agent uh for this product. Um and then the MCP gateway then proxies the call to upstream MCP servers. Just as an aside, um why did we use

Amazon Cognito for authentication and not something else? Well, it has a very tight integration with Bedrock agent core identity. and we use a lot of AWS as well. Um It has native OAuth2 support with authorization code and client credential flows and is highly customizable as well with lambda integrations. So, that was the inbound part. Now, the outbound part, um let's just start from where the MCP gateway

is proxying to upstream MCP servers. So, at this point actually is I'd like to point out that uh Mimecast has its own internal auth token um that that is used upstream and internally for uh for all our services. Um And it's bespoke to Mimecast's service mesh. Um all internal auth tokens contain the very important context such as the account that uh we're operating in, the user that

has consented, um the role and the scopes um that have been applied to this token. And um and also we chain all our requests together. So, we have So, with every hop that that occurs on our network, we we um we we create a new internal token, we attach it, and then we chain that. So, at any point uh any of our services, uh we can see

the path of where it went, uh where the where where that token came from, uh what user it started with for example, and and where it's going. So, back to the flow. So, the MCP gateway proxies it proxies the calls up to MCP servers. Um as I said, we we have the internal auth token, but we at this point we only have the uh public facing JWT

token. So we need to translate that. So we have an interceptor lambda which performs the task of translating JWT to an internal token. Um and once it does that, it then proxies the call to the MCP server, the product level MCP server, with the auth internal token as an authorization header. The MCP server then validates the internal token and extracts the context from that. And it uses

that to make informed decisions about what tools to use and what is uh available. Right. So authorization happens in two layers, as I mentioned previously. So there's the domain level uh check first. Um so it's answering the uh it asks the question, can this client access this MCP server domain? it validates the high-level OAuth And uh you can see there's an example here, MCP colon compliance colon

star. Uh it's a very high-level domain. Uh what product level domain uh question um scope. The idea is to reject early and then protect upstream calls. The second layer is at the MCP server it's asking the question, can this client invoke this specific set of tools? It evaluates the scopes in the internal auth token to do this. And generally the um the scopes being validated are fine-grained.

Um and as as an example, MCP compliance archive search. So there's a couple of key design principles here um that we that we settled on. Um the first one is that scopes should not be mapped one-to-one with tools. With MCP tools. Remember that the contract is very loose, so tools do change over time. And if we we don't want to get ourselves stuck with that one-to-one mapping.

MCP tools are not the same as API Um and also they're not the same as API permissions, either. in my experience, um MCP tools can be a complex set of aggregate operations. So, you may have an MCP tool that effectively makes multiple um API calls. So, it's best not to bind MCP tools to a uh to API endpoints. And lastly, authorization should reflect intent, not implementation. Beyond

authentication, um because the MCP gateway sits in the middle of everything that we do, we can do things like mitigate against uh prompt injection in tool responses. we can detect um if the MCP server is returning content which has prompt injection inside it, and we can revoke remove that uh mitigate it before it gets returned to the agents, where it may be where the agent could be

compromised. We can detect personally identifiable information leaking from an MCP server to an AI agent, as well. Removing sensitive information. We can protect against runaway agents overwhelming servers. So, one of the things that we know is that LLMs are effectively in charge of invoking tools. We don't really have much control in this AI world of what tools are going to be invoked. So, but we can prevent

that by rate limiting. And lastly, um we have a full audit uh trail of of the everything that happened through the MCP gateway. every tool that was called, who called it, what they called, which account for. It's a single point of compliance. So, lessons learned. So, the first lesson I would say is that the that we learned that I learned was that the MCP spec is a

moving target. Since MCP was released just over a year ago, there've been four major specification changes. as an example, one change was that the the initial spec talks about using something called SSE for um the transit of traffic, but um of MCP, but this was recently more recently changed to streamable HTTP. That's a fundamental change to the Another change is around the way that our old clients

are dynamically provisioned. Um this was also changed very recently about 4 months ago from something called DCR dynamic client registration to something called CIMD client ID metadata. So, my recommendation for this kind of project where it's cutting edge like this is to to design for flexibility. Embrace standards and use standard technology as much as you can. Um there are plenty of good MCP server libraries that you

can use like Spring AI, Fast MCP, environments like Agent Core. So, use these instead of trying to evolve your own. Managed services have real limits. Agent Core is a brand new service from AWS and was only released a few months ago at uh on the standard re:Invent. AWS is still defining the the product. So, you need to understand what these limitations are up front. And lastly, on

the technology, authentication and authorization are very difficult to get right. Um actually, this is the riskiest part of the system. you need to spend a lot of time trying to understand exactly how you want the calls to be made. Uh the MCB specification doesn't actually enforce anything. It advises on the types of technology you should use, but it doesn't enforce anything. We actually needed to modernize parts

of our authentication stack to get this working in the most secure way. So, about introducing new ideas, um the first thing I would say is that a POC video beats 100 slides. Uh a working video made the concept real to everyone. Uh when leadership saw it, they saw the potential immediately. So, I would say, show, don't tell. Or tell as well, but but show. Uh it'll help

you really convince everyone to the idea. Um find your collaborators early. Uh my colleague and I met met regularly to discuss the technology. We started thinking about uh many different use cases in different areas. but together we were able to shape a use case and a vision together. Um two people exploring an idea is definitely more powerful than one. Um and I will say also that the

enthusiasm that that brings is is really infectious. It really drives through the project and it makes it um keep moving when things feel difficult and you're stuck. And lastly, I would advise to let the idea spread organically. as I mentioned before, AI is new and most people don't really understand agents or MCB. Um talk to many people in different areas of the business. Um explain the concept

to them. Um by by many people, I mean like engineers have a different view. Engineers will think about the technology and and how great it is. Uh product managers will think about um how we can use this innovatively um and and the business will think about how it really helps our customers. So, everyone has a different point of view. Um it's worth talking to many people, getting

their points of view, um and then convincing them. And once the idea is there and they understand what it can do, the idea definitely sells itself. So, what's next? next we're looking at building internal agents at Mimecast. I'm sure a lot of people are also looking at internal agents right now. Um what I think is that building the internal agent uh internal agents here reasonably straightforward uh

with there's plenty of technology for this, but what I think is the hardest bit is understanding how to make outbound calls from agents to to other uh APIs or to Um especially in the area of authorization. Remember that LLMs here are calling the shots. They're they're the ones that are deciding what what tools that should be invoked. Um so, we need to make sure that the LLM

doesn't inadvertently give access to the wrong tools. also we we are in an uh in a multi-tenant um environment. So, it's critical for us to not give access to to the wrong customer data. So, that needs to be enforced by a solid authorization model. Um and then this these are actually all the same principles that I previously talked about for the public MCP gateway um but for

private MCP gateway. So, it's all the same. Um authorization um making sure that that the uh access is correctly scoped. These are really important factors. Next we're looking at publishing to publishing our MCP service to AI provider marketplaces. So the um Anthropic, um OpenAI, and so on have their own public marketplaces where where companies can publish, and it makes it really easy for customers to go into

that marketplace and just install the um the MCP server and start working on it immediately. It's self-service. And lastly the we're looking at the next frontier of API of AI integration. So um beyond the MCP, um we already have agent skills, which only came out in November um last year. There's still other protocols like agent communication protocol, agent-to-agent. And I'm sure that in the future there'll be

even more. The good news though is that the gateway pattern that we built extends to whatever comes next. So this is my final slide, and I wanted uh leave you with this quote. Um so a reflection I've had over this last year working on MCP um and AI is that what I think is that a lot of a lot of are traditional software engineers. Um and we've

heard a lot about AI, and it really feels like an MCP and this really feels like it's a completely different world. Um but actually there really isn't that much of a gap between traditional software engineering and AI engineering. Um it purely is just the application of these new concepts that we've uh heard to our existing job. there was a huge demand for people who are able to

take these AI concepts and bring them into their organizations. And I think that a lot of people who are hopefully watching this presentation will soon be excellent AI engineers, too. I started this project as a software engineer. Somewhere along the way I became an AI engineer, and you can, too. That's it for me. Thank you very much.