tools for encoding business context into governed AI queries across enterprise data sources
Every enterprise AI project used to start with the same hidden cost: a custom connector. Hook the model up to Salesforce, and you write one integration. Hook it up to the data warehouse, and you write another. Multiply that by every AI platform your company tries and every tool it needs to reach, and the math turns ugly fast: five models, ten tools, fifty custom integrations nobody wants to own once the person who built them leaves. There's a hidden cost beyond the hours spent writing connectors: the work that never happens because your best engineers are stuck rebuilding the same plumbing instead of solving something new.
That fragmentation broke governance too, and honestly, I think this part gets underrated. Each custom connector managed its own access rules, its own credentials, its own idea of who could see what. Connectivity and permissions were never two separate problems. Context couldn't move cleanly between systems, so the controls meant to protect it couldn't either.
What MCP actually is and what it changes about data connectivity
Anthropic put out the Model Context Protocol in November 2024, built by engineers David Soria Parra and Justin Spahr-Summers, as an open standard for connecting AI assistants to the systems businesses actually run on: content repositories, internal tools, dev environments, databases. People call it USB-C for AI, and the comparison mostly holds. You expose your data once through an MCP server, and any MCP-compatible client can read from it, replacing the pattern of building the same connector five different times for five different AI products.
Under the hood, MCP runs on JSON-RPC message exchange. Sounds heavier than it is, really. It just means the client and server agree on a standard shape for requests and responses, which replaces the bespoke, one-off connector with something reusable. It hands a model three things: resources, meaning read access to files, databases, and APIs; tools, meaning the ability to take action, like running a search or filing a ticket; and prompts, which are templates the model fills in and runs the moment it needs them.
The architecture is client-server. An MCP client lives inside whatever host application you're using, and it keeps a one-to-one session with a given server, formatting requests, tracking state, handling what comes back. The math that used to run N times M custom connectors now runs N plus M instead. BCG calls this the shift from quadratic to linear integration complexity as agents spread through a company. Language models gain the ability to work off what the organization actually knows right now, beyond whatever they memorized in training.
How fast MCP went from Anthropic proposal to cross-industry infrastructure
The adoption curve is worth sitting with, because it's steep in a way most technical standards never manage. At launch in November 2024, MCP's SDK pulled roughly 2 million monthly downloads. By April 2025, OpenAI had adopted it and downloads hit 22 million. Microsoft folded it into Copilot Studio that July, pushing the number to 45 million. AWS added support in November 2025, and by March 2026 monthly SDK downloads reached 97 million, with the project passing 81,000 stars on GitHub. Most technical standards stall when they try to cross vendor lines. This one didn't.
Server-side growth tells the same story from another angle. Company-run MCP servers grew 232% between August 2025 and February 2026, going from 425 to 1,412, with new monthly additions climbing from 56 to 301 over that stretch. On the public side, the PulseMCP directory listed over 13,230 public servers as of March 2026. Block, Bloomberg, and Amazon run it in production.
Then in December 2025, Anthropic handed MCP over to the newly formed Agentic AI Foundation under the Linux Foundation, with Anthropic, Block, and OpenAI as co-founders and Google, Microsoft, AWS, Cloudflare, and Bloomberg backing it too. Just over a year earlier, this was one company's proposal. Now it's vendor-neutral governance, and that transfer matters more than most people give it credit for. Forrester expects 30% of enterprise application vendors to ship their own MCP servers in 2026. The standard crossed from proposal to infrastructure in under two years. The harder question now is whether anyone's actually going to govern it once it's everywhere.
Why encoding business context is an infrastructure problem, not a prompting problem
The instinct when an AI system doesn't understand your business is to write a better prompt. Add more detail, phrase the instructions more carefully, pad out the system message until the model finally gets it. That instinct is aimed at the wrong layer entirely.
A prompt lives on one person's laptop, tucked into one team's setup. It disappears the moment that person leaves or a tool gets swapped out. Business context is what your team knows about a customer's history, how a process actually runs, what a database field really means, and who's allowed to see it, and phrasing alone can't capture any of that. That kind of knowledge is structural, and it belongs in infrastructure, not in something typed fresh every time someone opens a chat window.
CData's 2026 State of AI Data Connectivity Report found only 6% of organizations satisfied with their data integration architecture for AI. No amount of prompt tweaking closes a gap that size. MCP's job here is architectural: it gives teams a standard way to attach real data, live context, and defined tools to a query, changing what the model can reach when it runs, not how the question gets worded.
Three layers have to sit in place for a query to carry real business context. Connectivity comes first, the standard interface to your data sources MCP provides. Permissions come second: access controls that travel with the query itself instead of getting redefined per tool. Governed reuse comes third, a way to take a working setup and hand it to another team without that team rebuilding it from scratch. Skip any one of these, and context stays stuck in silos. One team builds a well-tuned agent, and the team down the hall never sees a bit of the benefit, because the same integration work and the same prompting logic get reinvented department by department for no good reason.
What happens to security and compliance when MCP governance is absent
Adoption has outpaced governance almost everywhere MCP has landed. Teams wire agents into GitHub, Slack, internal databases, and third-party APIs through MCP servers, often with no IT review, no credential policy, and no visibility for the security team into what just got connected to what.
A REST API call runs a fixed code path a developer wrote and reviewed ahead of time. An MCP tool invocation is a decision an AI agent makes on its own, at runtime, based on context it's reasoning through in the moment. Those are different threat models, full stop. Treating an MCP connection like a normal API integration leaves audit gaps that are hard to explain to a regulator after the fact.
Overprivileged access drives how bad an incident gets. A code-generation agent gets write access to production repos when it only needed to read. A database agent gets admin rights when read access on two tables would've covered the task. A CRM agent gets full API access when all it does is look up contacts. If that agent gets compromised, whoever's on the other end inherits every permission it was ever handed.
Shared credentials make the compliance picture worse. When ten agents run off one shared credential set, there's no way to trace a specific tool call back to a specific user, agent, or team. HIPAA requires an audit trail tied to an identifiable user or service for every touch of protected health data. SOC 2's CC6 controls require access restrictions with evidence they're actually enforced. GDPR's accountability principle requires documented authorization behind every processing action. None of that holds up when the credential layer is shared and anonymous by design.
Security researchers flagged prompt injection and poisoned tools as live attack surfaces back in an April 2025 analysis, and the industry's response has been to converge on a mediated access layer. Gartner projects 70% of software engineering teams building multimodal applications will run AI gateways by 2028, up from 25% in 2025. That's a fast swing for an industry that usually takes its time on security tooling.
How the 2026 MCP specification closes the enterprise auth and scaling gaps
Two enterprise-grade problems needed fixing, and the 2026 spec updates take them on directly: authentication at scale, and the ability to actually scale servers horizontally.
On authentication: the original per-user OAuth flow made every employee authorize every MCP server one at a time. Painful during onboarding, no centralized audit log, and a blurry line between personal and corporate access. The fix is the enterprise-managed authorization extension, stabilized in June 2026, which implements the Identity Assertion JWT Authorization Grant, or ID-JAG. During SSO login, the client swaps the user's identity token for an ID-JAG scoped to one specific target server, using RFC 8693 token exchange. That grant then gets presented to the server's own authorization server to get an access token, all in the background, with no consent screen popping up for every employee on every server they touch. MCP access now rides the same onboarding and offboarding pipeline that already governs email, code repos, and cloud consoles.
On scaling, the older stateful sessions required session affinity across load balancers, so MCP servers couldn't scale horizontally the way normal web infrastructure does. The July 2026 spec strips the stateful handshake out entirely. The old initialize and initialized exchange is gone, and protocol-level sessions went with it. Instead, client information, protocol version, and capabilities travel inside the metadata of each request, so every request describes itself completely on arrival. Remote servers can now sit behind a plain round-robin load balancer, no session stickiness required. The 2026 roadmap makes enterprise observability, meaning audit trails and gateway patterns, a first-class part of the spec instead of something bolted on after the fact.
The permissions inheritance problem and why it has to be solved at the infrastructure layer
The default pattern most companies fall into: every new AI tool or MCP server gets its own credential set, scoped however seemed convenient the day someone set it up. Fine when you've got three servers and a dozen users. Stops being fine once you're running tens of thousands of users across dozens of servers, and by then you've got tokens copied between agents, reused across environments, and granted broad, long-lived permissions that nobody actually owns anymore.
The better pattern provisions access by team, not by individual. An MCP gateway with an internal registry of approved servers lets admins hand each team a controlled slice of what's available, and lets that configuration evolve centrally instead of drifting apart in every team's local setup. Each server or gateway should expose only the tools needed for the task at hand. A smaller, tightly scoped tool set is easier for the agent to use well, and easier for a security team to audit.
Virtual server architecture is where this gets enforced in practice. Platform teams compose a curated subset of tools pulled from multiple registered servers, exposing exactly what a given team or use case needs, without spinning up new infrastructure for every department. That's how you get role-based tool access that actually holds: the sales team can't reach the HR database, even though both MCP servers technically live on the same platform. And all of it runs through the same identity provider that governs the rest of the company, whether that's OAuth 2.0, SAML 2.0, Okta, or Azure AD, so when someone leaves, their MCP access disappears in the same motion as their email and repo access.
Permissions should inherit from the source system automatically, staying stable as new AI tools show up rather than getting redefined each time. Redefinition is exactly where drift creeps in, where scope creeps wider than it should, and where compliance gaps start.
Why a governed registry is what separates scalable context from team-by-team silos
Without a registry, a well-built MCP skill lives on one team's setup and stays invisible to everyone else. The team down the hall doesn't know it exists, so they rebuild the same integration, write the same prompt logic, and define the same tools from scratch. Multiply that across five departments and you've paid for the same work five times over.
A shared drive doesn't fix this, no matter how neatly it's organized. No version control, no record of who owns what, no access scoping, no way to tell whether a configuration is current, abandoned, or unsafe to touch. A real registry gives you a searchable catalog of approved, versioned MCP servers and skills any team can find and reuse. It carries ownership metadata so you know who built it and what it connects to, access scoping so you know which roles can invoke it, version history so drift is visible and rollback is possible, and audit records tying every invocation back to a specific user, agent, or team.
A centralized governance model is a useful reference point here. A platform team manages MCP server deployment company-wide, so that someone wanting to expose an internal resource goes through an approval process, inheriting default-deny write controls, audit logging, and auto-generated secrets management without building any of that from scratch. Standing up a new governed server takes minutes of scaffolding rather than a security review that starts from zero.
The registry ends up working as organizational memory, which is a phrase I don't use loosely. Domain experts publish what they know, governance sets the guardrails, and every other team draws from that shared pool instead of starting over. Gartner predicts 40% of enterprise applications will carry AI agents by the end of 2026. At that density, a pile of one-off, ungoverned MCP setups just doesn't hold up. A registry is what makes that density something a company can actually run.
What a department-specific MCP server looks like in practice across teams
Give each department a scoped MCP server that surfaces only the tools and data relevant to its work, with permissions inherited from the underlying systems rather than redefined at the AI layer. It's simpler than most teams make it out to be, and I say that having watched a few overbuild it.
Take RevOps, since it's the clearest case I know. An MCP server connects to the CRM, pipeline data, and revenue forecasting tools. Agents pull deal status, put together forecast summaries, and flag at-risk accounts, all while staying inside the exact access boundaries the CRM already enforces. Nobody wrote a separate permissions system for the AI layer. It just inherited what was already there, which is the entire point.
The server exposes existing, already-governed access in a form an agent can use, rather than granting anything new, and that distinction is what separates a pattern that scales across a whole company from one more silo waiting to happen.
