"With models that sometimes make mistakes, I couldn't connect important apps and risk an accidental edit or delete one that may not even be recoverable," says Mateo Murillo.
Mateo is a Software Engineer at PRISMA and uses AI in his development work. Two apps he wouldn't connect before were Atlassian and Miro. "They have wide access to lots of data and contexts, not only the ones I'm currently working on," he says. "Those would risk accidental execution of unwanted tools."So he kept them out and did the legwork himself.
"My normal day while using AI for my work looked different before the MCP Gateway," Mateo says. "I needed to fetch the information from the different sources, and then give it to the AI to continue with my development work."
The obvious way to connect is MCP: The Model Context Protocol is an open standard that lets AI assistants such as Claude or ChatGPT connect to other software and use its functions, which are called tools.
"MCPs were already a thing, but they didn't have granular permissions," Mateo explains. "If I enabled an integration with another product, all its tools became available — editing and deleting tools as well."
The same went for local MCP servers, which run on the user's own machine and talk to the AI over standard input and output. That's why they're known as STDIO servers. Remote servers, by contrast, are hosted by the provider and reached over the internet.
The company felt it too. "From an organisational perspective, it was painful," Mateo says. It was hard to see which MCPs were being used, which were authorised, and how to control denied MCPs or tools at company level.
What he wanted as an engineer: "giving my AI only the tools that it needs to work, and nothing else."
Mateo’s answer was a gateway that sits between AI assistants such as Claude or ChatGPT and the MCP services they connect to, such as those from Atlassian or Miro.
He explains it with a theme park. "Multiple groups can have a ticket, and they can all get into the park," he says. "The MCP Gateway acts like an extra bouncer. After the tickets are checked, it checks each individual against a banned list, and only lets in the ones who aren't banned from the park."
In practice, the gateway passes the AI only the allowed tools. Denied ones, like delete tools, never reach it. "The AI doesn't know of the existence of the tools it doesn't see," Mateo says. "And if, by any chance, the gateway receives a request for a denied tool, a failure is returned."
Or, in his own one-sentence summary: "It gives the user control over exactly what actions the AI can take on connected services."
"The first thing I built was a local Java service that ran on my machine and helped me filter out the tools I didn't want my AI to have," Mateo says.
He did look at what already existed. Some providers offered allow and deny policies for MCPs, and even for individual tools inside them. "A good example is LiteLLM, which has great features for MCPs, but not all we needed," he says.
None of them worked for his need, "at least at that point in time": local MCPs, with the gateway also running on the machine. And without its own solution, "the company would have needed to buy an already existing solution, which solves some but not all of the PRISMA needs we had." So Mateo built his own, and that meant starting with the basics.
"I had to learn about the MCP protocol and how it works to be able to build a gateway around it," Mateo says, "as well as how to make installable software for different operating systems."
What turned out much harder than expected was serving two very different groups. "Finding a solution that works both for the experts who want a local gateway for their remote and local MCPs, and for the employees who just need a normal connection to the remote servers — and still be compliant with company policy," Mateo says.
Today, the Gateway has two parts. In the local gateway, each user manages their own security controls: what the AI can see, which MCPs and which tools.
The control plane is managed by the organisation. It’s a website where admins set the policies for the whole company or for individual users.
The rules reach every gateway automatically. "The ruleset is pulled by each client when the MCP Gateway is installed and started," Mateo explains. "Then it constantly checks if there are any changes in the policies, and if there are, it pulls the new ones to apply locally."
"Getting every gateway connected took a while.It was difficult to solve distribution within the company, and to ensure that all MCP gateways are connected to PRISMA's central control plane," he says. "When it worked, it was an immediate relief."
Mateo had help. Andreas Ulm, IT Security Coordinator at PRISMA, took part in the security consultation. Tony Hartmann, the IT Service Manager mentioned that it helped a lot to run the control plane on PRISMA's servers. And René Linder, Head of Product and AI, has been testing it and finding some improvements.
Distribution is also where the Gateway still has friction. "Distribution for employees, and running a local MCP gateway, is the biggest friction right now," Mateo says. "This is the reason to focus on a new remote-only MCP gateway. That is way easier to integrate with AI clients."
It's also what he would change. "Today, I would have made this product three pieces instead of two," he says.
One would be a web-hosted version for people who only need remote connections, like Atlassian. One would be a local version for people who need local servers, like engineers. And the third would be the existing control plane, where the company controls the allow and deny policy.
Now the company controls which MCPs are allowed and which are not. When someone wants a new MCP, it goes through security analysis and legal review. It's then enabled for everybody, or for a specific person.
Users choose from the pre-approved MCPs and, with one click, add them to their favourite AI. Right now, 40 people at PRISMA use it.
Today, Mateo connects Atlassian and Miro himself. "This project started as a personal project," he says. "What made me proud is that it became interesting enough for the company to put some work into it, with effort from different departments, to the point that now it's within the internal company policy."
Interested in how AI tools like the MCP Gateway are shaping the way we build software at PRISMA? This is one story in our series "Behind the Platform". Read here how Engineering Manager Marvin Stickel tested CodeRabbit, an AI tool that reviews code, across PRISMA’s engineering teams. And there are more stories to come.