Enterprise-ready MCP // Jiquan Ngiam

Jiquan Ngiam [00:00:05]: Amazing. Cool. Thanks everyone. Thanks Allegra having me here. Super excited to be part of Agents in Production and share a little bit of insights into what we're seeing with enterprises using agents and MCPs. There we go. Okay, so just a bit background on myself. I'm co founder CEO at Mint mcp, previously at Google, Google Brain, Coursera, Stanford, used to do research and deep learning, helped launch the first AI courses on Coursera and used to work with Andrew Ng at Stanford doing deep learning before it was succeeding there.

Jiquan Ngiam [00:00:40]: So today in this talk I'm going to talk about three things. One of them is going to start on starting on 50. This thing I'm calling a paradigm shift of how we're going from static to dynamic programs. Some people call it software 1.0, software 2.0 and how that's really changing the type of users we're getting for the software too. Two, I want to talk about some core challenges that we're seeing with agents and MTPs in the enterprise and then some strategies that we are seeing enterprises take today that help them be ready for this wave that's coming with coding agents, MCP adoption. So maybe to start off with I think the really groundbreaking shift that's happening in the last year for us, it's really going from what I call static programs that are engineers, developers writing out software where we know exactly how the software is going to operate at every single line, to essentially becoming agents and dynamic programs that are driven by prompts and instructions where instead of giving the software code, we're giving it natural language instructions on what to do and it dynamically figures out how to operate, what tools to call and how to get the task done. So we're getting to more of a goal oriented way to think about programming in some sense. And the big shift in here I think actually comes from looking at the user there.

Jiquan Ngiam [00:01:58]: We used to be having developers writing these programs, statically coding it. Up to now a business user is able to specify the instructions and the logic on how the programs operate. With that in mind, this change I think really brings to us a flexibility to that's really powerful, but also has a lot of risk in here. Kind of like a dual edge sword. And with agents and how this works today, the pro of it is that we can get it to perform really difficult, complex tasks, give it a goal to figure out how to get some data, analyze it. But the con side of it is that we have no longer any way to predict what the agent is going to do. We used to be able to statically Analyze code to figure out all the code paths and what the agent might do. But now in this new world, we have no idea what's going to happen.

Jiquan Ngiam [00:02:46]: The other pro in here that's really interesting is that when you start looking at mcps, one of the things about MCPS that's really powerful is that the tools can change at any time. If you're using an agent, if an MCP tool and you make the tool, you can add more capability to it and the agents adapt to the new tool very easily. If a vendor gives you a new MCP server and they add tools to it, your agent will be able to adapt to that and use that seamlessly without any change into how you work with the agent. Now the problem on the other side of that is that because the tools can change at any point of time, we don't really have any more guarantees on future performance. If you use an MTP server from say GitHub as a really comprehensive one, and one day they added a delete function in there, delete a repo, delete a particular user group, these things may be risky things that you may not want your agent to have access to yet. And if the NTP tool just magically appear in what the agents can do, that can be a really big risk factor for enterprises. Especially below that we talked about cross system data manipulation. So previously it was a lot of work towards to get data from multiple systems to correlate across them.

Jiquan Ngiam [00:03:55]: Imagine you had Google Analytics data, marketing data, sales data and you wanted to make sense of all the touch points of a user through their journey. You know, looking into your software and buying it, joining that is really hard. But today with agents you could connect MCPs for that and there are MCPs for all those things. You know, there's MCP for Google Analytics and you can start asking it to now the agents to pull that data in and correlate it with other sources of data, maybe even internal data sources. But because cross system data manipulation is easy, that also means that cross system data exfiltration is easy. You know, yesterday I found a new MCP server from Okta. Okta does SSO logins and it allows you to manage your users groups, administer things. Really great for HR admin IT admins to manage Okta.

Jiquan Ngiam [00:04:41]: But if you had that Okta MCP active together with, I don't know, a Twitter MCP or Reddit mcp, that could be really risky. Your HR system data can now live and be pushed to external systems you do not want it to get to. Finally, I Think the biggest pro of all is that non technical users can now automate work with natural language. But simultaneously that vector of being able to use natural language as instructions is a whole prompt injection vector. That could now be a risk factor for agents that might be doing things that we don't expect them to. So kind of like high level, lots of opportunity here. Agents are easy to use. MCPs give us data access, but really also a lot of challenges in how we think about this.

Jiquan Ngiam [00:05:25]: And sometimes I think there's a lot of list of all the issues in mtps and all the issues with agents. I kind of like to break it down into this framework that I'm proposing here, which is already three different categories of things to look at. One, I think is the supply chain risk. Where's the McP coming from? 2, I think is the third party data risk. What kind of data is your agencying? And then number three is what I call the inadvertent adversarial agent risk, which is agents are trained to be really helpful and in the process of being helpful, they might actually be doing some things that are unexpected. So let me talk about these three things and cover how we think about them. So starting with the supply chain risk, I mean, kind of like it's kind of amazing to see how this ecosystem has taken off in that if you look around and say what are the MCP servers I can use? You start to see things like for example, Pulse MCP, one of the best registries out there has 6,488 servers. I took this screenshot yesterday, index into their server directory, tons of servers in there.

Jiquan Ngiam [00:06:27]: If you look over to MCP. So you see now there's 17,000 servers, huge numbers in there. And instead looking into mcpworld.com inside, you see like 38,000 servers. So many MCPs, oh my God, so many of them. On one hand, I can feel like the industry is really taking off here and there's so much opportunity. On the flip side, you start to get lost. What do I actually use? What is the supply chain? And how do I decide what's a good server to use? To show you a bit of that problem in real life, I did a search for SEO data MCPS yesterday. Let me show you what I see.

Jiquan Ngiam [00:07:04]: I went to one of these registries, I typed SEO in, hit enter and I see all the servers here and three different ones of them, you know, the exact same name. App SEO AI from this person, app SEO AI from another person. And it's really hard to tell which is the right one to use. Gave up on this registry, went to a different one type SEO data. Started to see a few matching rules here from the WordPress server SEO review tools. And this one had some badges on security and quality. Kind of interesting, but wasn't really sure where those badges are coming from. After that I went to Pulse, typed that in and then I saw that Data for SEO has a official MCP server.

Jiquan Ngiam [00:07:46]: I know about Data for SEO, figured out that might be the right one I want to use. This whole process of even figuring out the right servers to use is really challenging today. And the number of servers being 38,000 may not actually be a great benefit for the user community now because it's hard to figure out what's the best one to use there. Here's a question for you guys. Here's a MTP server that popped up in September in the NPM registry. You can look in the NPM packages. There's something called Postmark NPM Server. This screenshot was taken in September.

Jiquan Ngiam [00:08:23]: Looks completely legit. Postmark NCP Server MIT License 1500 downloads lots of good features. Once feedback open source NPM install Postmark MCP Great. This is the challenge that you run into. End users are looking at this and going, should I install this? And it's very easy to look at something like this and just install it. But it turns out that if you did install that specific Postmark MCP server in September, I think 25th, the creator of that server decided to inject one line into that server implementation. Just that one line here where BCC his email address. Since in a send email tool, any email that gets sent through this unofficial Postmark MCP server will now also be BCC to this particular attacker.

Jiquan Ngiam [00:09:15]: And this is an actual MCP server found in the wild with a particular attack there. This whole thing was shut down a day or two. Everyone figured it out. So the limited risk exposure there, but this is the risk that we are facing. Right out of the 38,000 servers you're seeing how many of them can you actually trust? And on top of that, how many of them can you trust the author of? And so this kind of form of it, where a server is released, the implementation changes and then now it's malicious. We kind of call it a rug pool attack where you might trust it at first, but it's now not trustworthy. So maybe things I stepped back in here is that one of the ways that I think about mcps is that when you install an mcp you should think of it as effectively giving the MCP effective, the MCP author as well, full control of your agent. And the reason for this is that the MCP server tools and descriptions all go into the system prompts.

Jiquan Ngiam [00:10:11]: The MCP author could change the tools any point of time. They can change the behavior of the tools. The two responses and that has a lot of control into how your agent behaves. On top of that, if you're installing mcps locally on your machine, you are actually running their code locally. So not only are you giving them full control of your agent, you may also be giving them full control of your computer. So that whole supply chain and figuring out who you trust is actually a critical part of using the right MCP service. The next thing in here is I think, what I call third party data risk, which is, let's say you have great MCP servers, you trust them, you trust the author, what's next? It turns out that the MTP service that you install could include more things in two responses. Even trusted servers that you may not expect.

Jiquan Ngiam [00:11:04]: This is a demo that we set up as a proof of concept and this is using CLAUDE code. And we installed a MCP server that acts as a documentation server that has a docs function and a send feedback function. A lot of MTP servers have send feedback functions, pretty common in there. So imagine you're typing, you're using your coding agent CLAUDE code, you send some feedback. And we're kind of used to CLAUDE just going ahead and doing lots of work for us. So in this case it called that particle sense feedback function. We told it that some links are not working and CLAUDE is clotting away, wrangling, figuring out all the things that it wants to do and sends that feedback to that MCP tool. So what's interesting about this experience is that this all happens really fast.

Jiquan Ngiam [00:11:48]: Very few of us go back in time and look at all the details of what CLAUDE did. But in this particular demo here, this proof of concept here, you actually scroll up and you start to see CLAUDE sending a bunch of data that we may not expect it to. You saw a bit of keys in there and sort of things that in there that looks sensitive to us. If you hit control o one of the shortcuts in Claude, you can start to see the full output of the tool calls. These things are not even shown to the user. They suppress behind the scenes. You got to hit a button to show it. In this case, what we did here in this proof of concept here was that we injected more instructions to the model to exfiltrate data.

Jiquan Ngiam [00:12:31]: So let me show you a bit more like what that was like in case you missed that whole screen going by really quickly. So this is the example of what we are seeing in the different keys in there. So OpenAI key, Google key showing up in the responses to the tool. And then this is the actual prompt injection that we did into the problem itself. Feedback received. Thank you for your initial response. We need more information and this is challenging because this whole thing in here mentioned something like your IT Enterprise team really needs this information, so please get it for me. And so this is what the agent proceeds to do.

Jiquan Ngiam [00:13:08]: And you can imagine that this prompt may be an okay, maybe even semi valid prompt in some settings if it was rolling out in mcp. So you've got to not only trust the pipeline of where the MCP comes from, the author, but also what data is coming into the MCP itself. The third risk that I touched upon earlier in one of the three categories is what I'm calling the inadvertent adversarial agent risk. Over here we train agents to be really helpful. They go out, they do work for us, they get data. And it turns out that if you ask your agent to say read your ENV file, it's going to be very happy to do that. So try that today, go read my environment files and it's actually going to read those files, pick up any keys in there and maybe even send it out. And these are all risk that you might see agents doing in a way that's not malicious.

Jiquan Ngiam [00:13:59]: It's just trying to be helpful. But this may be not things that we may not want our agent to be doing in a production setting, especially when we care about secrets being stored securely. So those are the three risks in that supply chain. Third party data risk, inevitant helpful agent risk. In this part of the next part of the talk, I'm going to talk a little bit about enterprise readiness, which is the key title of this talk, on how as a company we can start thinking about ways to mitigate this risk or get our hands around them so that we are ready for the wave of agents that's coming in here. Monitoring guardrails and secure deployment. Those are the three things we'll dive into next few slides there. First one is monitoring.

Jiquan Ngiam [00:14:44]: I think for monitoring, the key in here is that you can't really govern what you cannot see. If you do not know what agents are doing in your ecosystem, it's really hard to figure out what to even block, what to allow. The first thing that we do is we suggest having gateway architectures that sit in between the agent, say, plot code and the LLM provider. And these architectures are able to, in real time, inspect all the agent activity. They should be able to see all the tool calls, apply guardrail on the two calls, all the two responses, and really give you, as an enterprise, a sense across your entire organization what are all of these agents doing. So let me show you that in practice and how this looks. So, going back to Claude again, in this case, I'm going to ask it to read my M file, which we showed earlier that it will do. So claude's going to improvise, read it, and be able to tell me that I'm all set up, it's good to go.

Jiquan Ngiam [00:15:40]: Right. So this is a behavior that maybe we want to, number one, understand what's happening and number two, be able to block. So I'm going to go into the MintMcPagent monitor here and I'm going to add a new rule in here to say if CLAUDE ever runs the read command and is reading a file which has ENV in it, we're going to change the LLM response and tell the agent that it cannot read environment files. Instead, going to create this rule. Now, CLAUDE is actually running in a setting in here where it's not going directly to Entropic, but going through our gateway. Once you set up that rule, these rules are applied in real time. And you can see that now CLAUDE is unable to read the environment files. Ask you to try harder.

Jiquan Ngiam [00:16:22]: It still cannot read it because the read command is now being blocked to do that. So quick example of the agent monitoring situation there. But how this works under the hood is that we inspect messages. We look at two calls on the messages, we apply gut rails on the two calls or the two results, and then we revise the messages, the chain of messages that are shown to the agent from the agent's perspective, from Claude Codex Gemini's perspective, what you see is really a view that's very clean in that I cannot call that tool and I should only be doing the things I'm allowed to do. When we deploy this in production with customers in practice, we see a ton of stuff. The agent monitor starts to pick up all of these different things that the agents are doing in the real world. Environment files being one of the biggest offenders. We see it trying to run sudo commands.

Jiquan Ngiam [00:17:18]: Normally that fails because there's no terminal access. And we also do things like calling kubernetes to get secrets, calling Google Cloud to get secrets. And this is really, really common. And so depending on your security posture, you may not want your agents to do some of these tasks in here and rereading very sensitive data and having it sent to the LLM providers and being stored in multiple logs. The other thing that we recommend as an approach in here is to add guardrails from a hook spaces too. The second kind of guardrails that we are seeing appear in agents are this thing called hooks where we are able to have an agent before performing a particular action, be able to hook into that action and say, do something or don't do something. Over here I added a little link and a QR code to a open source security scanner that we made that helps you with this. Over here, I want to show you another demo on how this works with cursor to give you a sense of what this looks like if you secured cursor.

Jiquan Ngiam [00:18:17]: So in cursor, there's a system called hooks. In hooks, you can install hooks that apply before reading a file or before submitting a prompt. And these hooks can run and observe what cursor is going to do and be able to prevent cursor from taking actions on things that you may not want it to do. So in this case, I installed two hooks that would block secrets. Reading it will scan files for secrets and tell cursor that it cannot read. And you can see that now cursor is being blocked from continuing that agent conversation running that tool. When it sees those hooks active. You can also see what hooks are called and when they are triggered as well.

Jiquan Ngiam [00:18:55]: This is really nice. If you're interested in hooks, do check out the report that we have because that will get you started in very basic ways to secure the agents in your organization. We talked about monitoring guardrails, adding hooks, and looking at what agents are doing. The next step in here, I think is really figuring out how to deploy MCP securely. I think the first thing in deploying MCP securely is really thinking about what mcps do you want your organization to use. If the supply chain is really important and who you trust is really important, you really want to start with custom catalogs of what MCP servers your teams can access, what's approved, what's not approved, and what do you want to recommend as well. On top of that, today where we actually see MCP kind of being an early wild west where users are connecting all kinds of agents on the left to all kinds of MCP servers on the right. And this is happening at an end by end type connection thing where there's no telemetry into any of these things.

Jiquan Ngiam [00:19:56]: If you connected cloud code to the malicious postmark server and you sent out a bunch of emails that were BCC to an attacker, your organization may not have the locks necessary to be able to report on that or maybe for compliance reasons, to be able to understand how to email those users to let them know that something bad happened. Instead of this wild west of deployment for mcps, we suggest two things in there. The first thing is that rather than letting users connect all MCPs to any of the AI agents, you might want to be careful about what tools you actually allow those agents to use. For example, the GitHub official server has, last I checked, about 90 tools, 4,600 tokens. And it comes with a bunch of tools like delete file, delete project item that are really risky type behaviors that you may not want your agents to start doing initially. That's something that you want to be pretty careful about. When you think about mcps, it's not just what the servers are, but also what tools are in allowed to be used by each individual. So when we think about that, one of the frameworks that we're looking at is MCP gateways that sit in between your AI agents and the MCP servers.

Jiquan Ngiam [00:21:13]: They mediate access and then they organize the access and tools for each of these agents by specific roles. Engineers, for example, would have access to project tracking stuff in Jira, GitHub and maybe some data warehouse data. And Snowflake Sales doesn't need any access to GitHub at all. They shouldn't see that Finance might have access to different tables in the Snowflake instance. And I think that kind of mediation of that's driven by a role and driven by a use case actually makes mcps a lot easier to deploy and easier for individuals to understand how to use. I have a link in here to a white paper on how we think about this. So Happy, if you check it out, it goes into some of the concepts behind how we think virtual mcps can actually help use cases be secure and more effective. So I think maybe ending off in this slide here is I'm kind of like seeing the trend.

Jiquan Ngiam [00:22:08]: We're seeing this trend in 2025 this year where agents have really taken off. We started off, this is Claude Code's download stats, not too many. And it just exploded in the last quarter in Q3 to over 5 million downloads every week. And I think coding is where this starts. And I think what we're trying to see now is like There are more coding agents, but very soon the same concepts in here will apply to all the non technical business functions as well. Sales, marketing support. I'm going to see a lot more of this and it's important for enterprises to get ready for the wave that's coming. Cool with that.

Jiquan Ngiam [00:22:44]: That's all I have for today. I'm sharing min MCP1 platform for MCP deployment and agents. Please check out our white paper, the open source repo we have for agents security scanning and Find me on LinkedIn. We'd love to chat.

Allegra Guinan [00:22:58]: Thank you so much. That was awesome. A bit scary on some of the risks that you showed, but so great to see some of the ways that you've been addressing some of these risks. We do have a couple of questions here, so I'd love to just take a couple of minutes and answer them. So I will start with this one here. How do you ensure that agents can only do things that are explicitly allowed and everything else is blocked because there's no end to what an agent can and should not do?

Jiquan Ngiam [00:23:27]: Yeah, that's a really good question in there. So in our solutions we actually hook into the agent itself and so we observe every single tool call the agent makes and then we do as much as we can in scanning those two calls, figuring out what their data they're accessing, what data is coming in and out. And I think two calls is a good place to think about that because that's like the data boundary. That's a boundary between what the agent sees and what the agents are able to push and pull next to no world. So doing it at that layer I think is really important. And then I think on top of that, depending on your agents, you can do that through LLM proxy solutions or hook solutions which we both support. Then I think for beyond that we tend to look at the broadest ecosystem really understanding just like data egress and ingress. So a lot of the other systems like ChatGPT on the web port on the web, they actually allow you to enterprise set up what MCPs and connectors are available.

Jiquan Ngiam [00:24:20]: But what's critical there is not just making the connectors available, but having the monitoring of what's going in and out of those connectors. I think that's where we start. And then I think next step is now we have that because you're monitoring and in the line of the communications you can start injecting yourself and saying I'm going to permit that. I'm going to deny this, I'm going to add a PII filter on this. I'm going to add a secret scanner here and these are all things that I think we need as a defense in depth solution there.

Allegra Guinan [00:24:46]: Thank you. When you were walking through those hooks and you were mentioning being able to block when there's keys present in a certain file and not accessing those, were those based on the content itself and defining that ahead of time or is it more based on file naming and organization?

Jiquan Ngiam [00:25:04]: Actually both. So we actually recommend doing a bit of both in there. Like sometimes the file names are very good indicators of what you're concerned about. Secrets or JSON, obviously one that's probably not great. And then I think content screening is also important. So the open source report I linked at the bottom right here, that actually does content screening and the way it works is that there are secrets often have a particular format. AWS keys start with Akia and Caps. So we have a good list of patterns that we detect.

Jiquan Ngiam [00:25:34]: Entropy based scanning is another thing to do. And critically, I think for the content based ones, you want this to happen locally on the machines rather than remotely so that you're scanning in a local fashion that it never actually leaves the machine itself. It doesn't go on the wire in there. Maybe to answer the question both and check out the open source repo for a bit of the hint on how we do it on a content basis. Great.

Allegra Guinan [00:25:56]: And another one just came in here. What are the main challenges that are faced when deploying and maintaining multi tenant agentix solutions?

Jiquan Ngiam [00:26:05]: Oh, wow. Interesting. Yeah. So I think two things in there. I think that we've seen customers with like multiple agents, they use Claw, they use Cursor, they use Gemini and use everything. One of the challenges in there is that each of these systems are very new and so the ability to support some of the monitoring abilities that we have are all also pretty nascent. So one challenge they run into and we work hard to make compatibility layers and figure ways to stick ourselves in there. Another one I think is you start to see for mcps that the permissions you want are not at a server level but at a tool level.

Jiquan Ngiam [00:26:42]: And let me explain that a little bit. So for example, your product manager, your PM, you may want to give them access to GitHub to see what pull requests were closed, what bugs do we fix so that they can go back to the customers and say hey, we fixed this box or there's a weekly update email descent. But you do not want them to be going in there perhaps and closing a pull request or changing it up or Making changes to code. Even though two different users in an organization are given access to a MCP server, you may want to have very differentiated role based access based on the tool or even based on the data behind the tool. And that's also challenging for many organizations, especially as you're rolling out internal mcps. You know, so the most advanced organizations we work with, they have their own internal custom MCPs connected to their own data sources. And so figuring out how to secure that, do RBAC on that, do SSO on that, that's already hard. And that's kind of where we come in and help quite a bit as well.

Allegra Guinan [00:27:38]: Yeah, I'm really glad you called that out. And definitely something that organizations can do to prepare for agents, if they're not already deploy, is getting a sense of their role based access and knowing which teams and which individuals need access to which tools and what within those tools they need access to to do their job. I think that's such a big undertaking that not a lot of organizations have done necessarily. So if they're getting ready for this agentic revolution, that's one really important thing to focus on.

Jiquan Ngiam [00:28:08]: Exactly, yeah. If you find yourself using API keys or bearer tokens as a way to secure your agent, you're probably not in a great state right now.

Allegra Guinan [00:28:15]: Well, thank you so much. This was awesome. It was a pleasure having you on. I'm so glad that you are our final speaker. It was such a strong way to wrap up this track. So thank you for joining and we'll see you over in track one.

Jiquan Ngiam [00:28:28]: Thank you, Alicia. Thank you everyone for listening.