# What We Learned from Dozens of Enterprise MCP Deployments

Jiquan Ngiam, MintMCP | MLOps Community | 26:13

Source: https://www.youtube.com/watch?v=t2RknZh8U9I
Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks.
Page: https://mlopstalks.com/talks/what-we-learned-from-dozens-of-enterprise-mcp-deployments
Published: 2026-08-19
Tags: governance, mcp, security, tool-use

## TL;DR
- MCP adoption is moving from engineers running local servers toward everyday employees using hosted, managed connections to work tools.
- Enterprise deployments need role-based MCP bundles, fine-grained access boundaries, and inline masking for sensitive data.
- Agents become easier to adopt when they run in shared workspaces such as Slack, where teams can see, guide, and reuse how they work.

## Summary
Jiquan Ngiam shares lessons from working with enterprise teams that deploy MCP and agents in production. He argues that the main problem has moved from agent intelligence to getting governed data into agents safely. Everyday work tools such as Gmail, Slack, Figma, HubSpot, and Airtable are driving much of the usage, including among non-engineers. Enterprise connections are harder than individual connections because companies have multiple tenants, deployments, mailboxes, and regions. Ngiam recommends role-based virtual servers that combine the tools needed for a job and expose them through one-click bundles. He also describes security controls that mask sensitive values in tool responses and restrict agents to specific folders or channels. Finally, he argues that agents work better as shared participants in Slack or Teams, where colleagues can observe and teach their use. For infrastructure, he favors buying trusted routing and security layers while building custom tools that encode the company's own business rules.

## Key ideas
### MCP usage is moving from engineering teams to everyday work
[02:36](https://www.youtube.com/watch?v=t2RknZh8U9I&t=156s)
Ngiam says the most-used connectors are everyday work tools, including Gmail, calendar, Slack, Figma, Ahrefs, HubSpot, Airtable, and Miro. Engineering tools such as GitHub and Linear appear later in the usage data. He sees this as a shift away from MCP being mainly a technical product. At Coursera, he says 25% of AI usage comes from non-technical employees. At The Other Few, a mostly non-engineering advertising company, more than 30 MCPs were deployed across the company in about a month. These examples show operational, sales, marketing, and creative teams using MCP directly.

### Hosted MCP and managed deployment remove much of the old setup burden
[03:31](https://www.youtube.com/watch?v=t2RknZh8U9I&t=211s)
Ngiam describes how early MCP use required people to install JSON configuration, run servers locally, and place credentials in configuration files. Remote servers and newer HTTP-based approaches moved execution to hosted infrastructure. OAuth and short-lived access tokens also replaced much of the manual credential handling. He says enterprises prefer managed cloud execution because running local servers creates supply-chain risk. In his view, MCP is no longer only a developer tool because non-engineers can use hosted connections without assembling the system themselves.

### Enterprise connector management has to support many instances of the same system
[07:10](https://www.youtube.com/watch?v=t2RknZh8U9I&t=430s)
Individual users may have one Gmail or Salesforce connection, but enterprise deployments often span several tenants, regions, environments, and shared accounts. Ngiam gives examples of Snowflake installations in both the US and EU, Salesforce production deployments in multiple places, and Gmail shared mailboxes. The requirement is to keep many MCP connections to the same underlying system live at the same time. This makes the enterprise connector problem different from setting up a personal account.

### Making an MCP server possible is insufficient when users still have to configure every task
[10:07](https://www.youtube.com/watch?v=t2RknZh8U9I&t=607s)
Ngiam describes a marketing operations employee at Workstream who used Claude and API documentation to create, deploy, and use a custom 70-tool HubSpot MCP server. He sees this as evidence that non-engineers can now build useful integrations. He also says this is only a low bar. Users still have to enable many connectors for one task and change them when their task changes. His proposed answer is a one-click bundle for a role, such as a store manager, salesperson, or operations worker, with the connectors needed for that type of work already grouped together.

### Role-based virtual servers reduce tool count and limit dangerous actions
[11:17](https://www.youtube.com/watch?v=t2RknZh8U9I&t=677s)
Ngiam describes MCP gateways and virtual servers that group tools into bundles for roles such as engineering, sales, finance, or outreach. An outreach bundle might combine LinkedIn, Gmail, and Salesforce while appearing to the model as one MCP server. Administrators can choose which tools enter a bundle and remove risky actions. This reduces the number of tools the model must search through and discover. It also creates a simpler user experience because a new tool can be added to an existing role bundle without changing the end user's workflow.

### Security controls must inspect responses and enforce narrow access boundaries
[13:33](https://www.youtube.com/watch?v=t2RknZh8U9I&t=813s)
Ngiam says enterprises worry about the data that agents can see through tool calls. For finance customers, tool responses may contain card numbers or Social Security numbers. His example of inline masking scans the response before it reaches the language model and removes sensitive values while allowing the tool call itself. He also argues that broad permissions such as access to all SharePoint files or all Slack channels are too risky. A safer policy might restrict an agent to three specific SharePoint folders. Prompt instructions are not enough for this purpose. The boundary needs to be enforced by the system.

### Shared agent workspaces help teams learn how to use AI
[17:01](https://www.youtube.com/watch?v=t2RknZh8U9I&t=1021s)
Ngiam calls the isolated use of agents in tools such as ChatGPT, Claude, or Cursor a single-player environment. People cannot see how colleagues use agents, so the company has to rely heavily on formal training. He says teams are experimenting with putting agents into Slack and Teams instead. When the agent works in a shared channel, people can see its actions, intervene, and learn from one another. Juro and Workstream have more than six agents in Slack channels, according to Ngiam. Modern Treasury's bank operations agent also works through Slack while retrieving information from systems such as Notion, Hex, Sentry, and Linear.

### Companies should encode their own business rules while buying trusted infrastructure
[23:12](https://www.youtube.com/watch?v=t2RknZh8U9I&t=1392s)
In the closing discussion, Ngiam separates custom business logic from infrastructure. Generic tools supplied by Snowflake or Salesforce do not reflect how a particular company defines work, such as its own meaning of revenue. He expects companies to build custom MCP servers and agent definitions that represent those rules. He is more inclined to buy infrastructure for routing, authentication, security, and encryption because mistakes in that layer can be costly. The division he proposes is to build the business-specific layer and choose a trusted vendor for the underlying infrastructure.

## Notable quotes
- "The bottleneck is no longer about the agent and the harness and intelligence. It's now about data." (01:06)
- "It's not a developer tool anymore." (05:36)
- "We need to make it easy. And by easy, we need to make it one click." (10:07)
- "You want to create hard boundaries so that you know where the agents can play in and what they can do." (16:05)
- "You should be building all the custom layers that reflect your business." (24:24)

## Tools & references mentioned
- MintMCP
- Model Context Protocol
- MCP
- Stanford
- Andrew Ng
- Coursera
- Google Brain
- Waymo
- Box
- Coursera
- Gmail
- Slack
- Figma
- Ahrefs
- HubSpot
- Airtable
- Miro
- GitHub
- Linear
- OAuth
- Claude
- ChatGPT
- Salesforce
- Notion
- Modern Treasury
- The Other Few
- Workstream
- SharePoint
- Snowflake
- LinkedIn
- Intercom
- Cursor
- Juro
- Teams
- Coda
- Codex
- Zendesk
- Doven
- Hex
- Sentry

## Who should watch
- You are evaluating MCP for a company where several teams need access to the same business systems.
- Your agents can call tools, but you still lack narrow permissions, response filtering, or a clear way to manage multiple enterprise connections.
- You want teams to learn from shared agent use instead of keeping every workflow inside a private chat or coding environment.

## Related talks

- [Enterprise-ready MCP](https://mlopstalks.com/talks/enterprise-ready-mcp) (Jiquan Ngiam, MintMCP, 28:36)
- [MCP Security: What Happens When Your Agents Talk to Everything?](https://mlopstalks.com/talks/mcp-security-what-happens-when-your-agents-talk-to-everything) (, 24:26)
- [MCP Security: The Exploit Playbook (And How to Stop Them)](https://mlopstalks.com/talks/mcp-security-the-exploit-playbook-and-how-to-stop-them) (, 26:55)
- [MCP is not going to change everything (yet)](https://mlopstalks.com/talks/mcp-is-not-going-to-change-everything-yet) (Sam Partee, Arcade AI & Rahul Parundekar, AI Hero, 1:04:43)
- [Responsible Autonomy: Building Governance Frameworks for AI That Act in the Real World via MCP](https://mlopstalks.com/talks/responsible-autonomy-building-governance-frameworks-for-ai-that-act-in-the-real) (Saurabh Mishra, Optum, 27:55)