enterprise data connectors for AI-governed knowledge platforms

Before the Model Context Protocol, every AI agent integrated with every tool through that tool's specific API, that vendor's function-calling format, and that agent runtime's own orchestration pattern. A GitHub integration written for Claude did not transfer to Cursor. The result was the classic N agents times M tools problem: N×M custom connectors, each requiring its own build, its own maintenance, and its own failure modes.

MCP, announced by Anthropic in November 2024, collapses that to N+M. One server per tool, one client per agent, and they interoperate. The protocol is an open standard built on JSON-RPC 2.0, defining three primitives: Tools (functions the AI can invoke), Resources (data it can read), and Prompts (reusable templated instructions). The Anthropic documentation reaches for a USB-C analogy that actually holds: just as USB-C lets any device connect to any peripheral regardless of manufacturer, MCP lets any AI model connect to any data source regardless of where either is hosted.

The economics are concrete. For a typical enterprise with dozens of integration targets, standardizing on MCP cuts ongoing maintenance substantially. More importantly, it makes previously uneconomic workflows viable; tasks that eat a few hours a week, never worth a large custom build, become trivially addressable once a single MCP server exists.

What MCP does not solve on its own is permission enforcement. The standard defines how to connect, not what access to allow. That design responsibility falls entirely to the platform built on top.

What "Inherited Permissions" Actually Means in Connector Design

Two philosophies exist for handling permissions in a connector, and they produce entirely different governance outcomes.

The first is redefinition: the AI platform creates its own access model, administrators manually replicate who can see what, and that replica drifts out of sync with source systems over time. The second is inheritance, where the connector reads and syncs the access controls already defined in the source system, so if a user cannot see a Confluence page, the agent cannot surface it to them either.

Redefinition fails at scale for a practical reason. Manual permission mapping across eight or more data sources either never gets done correctly or immediately begins to decay. When it decays, agents surface answers drawn from data the asking user was never authorized to see. That is a compliance failure, not a configuration inconvenience.

Automatic sync changes the picture considerably. When a source system revokes access because an employee changes roles or a document gets reclassified, the AI platform reflects that change without requiring a separate administrative action. Nobody has to remember to update a second system.

The least-privilege principle matters here too. An MCP server for Salesforce should use a service account scoped to minimum necessary permissions, but in practice, servers frequently get configured broad because it makes development faster: admin-level database access when read permissions on specific tables would suffice. A connector architecture that enforces scoped credentials closes this gap structurally, rather than relying on individual developer discipline. Credal handles this directly; permissions are inherited and synced automatically across connected sources, so when a new agent or team is added, the governance is already encoded in the connection itself.

Breadth of Sources as a Governance Variable, Not Just a Feature Count

The common framing treats connector breadth as a convenience feature: "connects to 1,000+ sources." The governance argument is different, and it carries more weight.

Every data source outside the governed connector layer is a potential shadow data highway. Non-technical users in marketing, finance, or operations will connect corporate Salesforce or SharePoint to AI agents through low-code tools, creating integrations invisible to the security team. This is the pattern that fast, ungoverned MCP adoption has already produced: teams connected agents to GitHub, internal databases, and third-party APIs through MCP servers without IT review, without a credential policy, and without any mechanism for security teams to see what those servers were accessing.

The coverage gap is a governance gap. If the governed platform does not reach a data source a team legitimately needs, that team will find an ungoverned path to it.

Category variety matters as much as raw count. Structured databases, SaaS platforms like CRM and HRIS and ERP, document stores, communication tools, and code repositories each carry different permission models. A connector layer that handles all of them with consistent inheritance logic is architecturally distinct from one that handles each case ad hoc. Credal's extensive source connections reflect this principle, and the value is that it shrinks the gap between what the platform governs and where the organization's data actually lives.

Why the Same Connector Layer Must Serve Every Team, Not Be Rebuilt Per Department

Without a shared integration layer, the duplication pattern takes hold fast. Engineering builds its own GitHub connector, sales builds its own Salesforce connection, support builds its own Zendesk integration, and none of these share authentication logic, logging, or governance policies. Each one compounds the security review and compliance burden independently.

Fragmented AI environments also produce inconsistent outputs. Different teams accessing the same underlying data through different connectors get different answers, which erodes trust in AI-generated responses in a way that is genuinely hard to recover from. We've watched this unfold firsthand; rebuilding that trust takes longer than building the right layer from the start.

The unified access layer alternative is straightforward in principle. Authentication, logging, governance policies, and data contracts get implemented once and inherited by every team's agents. New use cases add capability without adding governance debt. When a connector is updated, every team using it gets the updated version automatically, rather than a shared-drive situation where copies proliferate across departments and nobody knows which version is current or who last touched the credentials.

Credal's registry model works this way. The governance infrastructure scales flat while the number of teams using it grows.

How Department-Specific MCP Servers Work Within a Shared Governance Layer

Each department-specific MCP server should have one clear, well-defined purpose. A customer support agent needs business glossary terms and knowledge articles; an analytics agent needs certified datasets and lineage metadata. Neither should have access to the other's scope, and both sit atop the same shared governance layer.

Engineering teams were the earliest MCP adopters, and the pattern is instructive. The common stack combines a GitHub MCP server, a Snyk MCP server, and a Linear MCP server. Teams running this configuration have reported faster onboarding to unfamiliar codebases and reduced time on test-writing through spec-driven generation. The relevant governance constraint: a code-review agent that can read pull requests should not automatically have push access to production. Write access gets scoped separately at the connector level, not assumed from read access.

RevOps is a different use case with a different bottleneck. Before a governed MCP layer, an account executive preparing for a customer call spends 15 to 30 minutes assembling context from separate dashboards: CRM activity, email engagement, intent signals, website behavior. A governed MCP layer connects those sources in a single query and pulls a complete briefing in under a minute. Sales reps spend roughly 70 percent of their time on non-selling activities, and the data-assembly portion is directly addressable without building separate custom connectors for each system.

Support operates under a different scoping logic. Knowledge articles, product documentation, and prior case history should be available to support agents, but not the full CRM or financial data the sales team accesses. That boundary gets enforced at the connector layer, not through post-hoc filtering. Credal gives each team its own scoped MCP server that plugs into any agent or chat surface, while permissions and audit remain centrally enforced underneath.

Auditing and Versioning as the Missing Half of Connector Governance

Permission inheritance handles the "who can see what" question at query time. Auditability handles the "what did the agent actually retrieve and act on" question after the fact. Both are required, and only the first one gets talked about consistently.

Without an audit trail at the connector layer, compliance reviews require reconstructing agent behavior from logs scattered across multiple systems, or from logs that do not exist at all. The governance gap that fast MCP adoption exposed was exactly this: connectors existed and were active, but no record of their activity did.

The MCP gateway pattern addresses this structurally. A proxy sitting in front of all MCP servers acts as a single checkpoint for every request an AI agent makes. Rather than requiring every development team to implement security and governance logic inside their individual server, the gateway abstracts it into a shared, centrally managed layer, and every request passing through gets logged. One checkpoint, full visibility.

Versioning adds a second layer of accountability. When a connector is updated, the change is recorded in the registry with ownership and a timestamp. Rollback is possible, and every team using that connector knows what changed and when. In regulated industries, knowing which version of a connector was active during a specific agent interaction is not optional; it is the audit trail regulators expect, and it cannot be reconstructed retroactively if the versioning infrastructure was never there to begin with. Credal builds from this directly: every agent action is auditable, and version control, ownership, and access scoping are non-negotiable at scale.

Model-Agnosticism as a Connector Design Requirement, Not a Preference

Frontier model leadership has rotated frequently over the past two years. The model leading benchmarks in one quarter gets displaced in the next. Organizations that tied their data integrations to a specific model's function-calling format found themselves rebuilding integrations when they switched providers, which is the N×M problem reasserting itself at the model layer.

MCP's vendor-neutral design prevents that. An enterprise running Claude, ChatGPT, Cursor, and Slack bots simultaneously, which describes a large number of organizations in 2025, can serve all of them through a single governed connector layer without rewriting integrations when one model changes.

The adoption signal on this is significant. OpenAI officially adopted MCP in March 2025. Microsoft Azure incorporated it into Azure AI Agent Service in May 2025. Salesforce's platform began routing interactions via MCP, with Salesforce reporting 4.5 million MCP calls processed in late May 2026. Gartner projects that 75 percent of API gateway vendors and 50 percent of iPaaS vendors will have MCP features by 2026.

Connector investments built on the protocol are not at risk of being stranded by a model change, and for enterprise infrastructure decisions, that structural guarantee matters more than any benchmark number. Permissions, audit trails, and business context should travel with the organization, independent of any single LLM vendor. Credal holds business context, permissions, and guardrails in the platform itself, so swapping the model leaves the governance layer intact.

What the Connector Layer Determines About the Platform Built on Top of It

The connector layer sets the ceiling on platform governance. Every design choice made there propagates upward into every agent built on top of it, and those choices compound.

Permission inheritance versus redefinition determines whether access controls stay accurate or drift toward over-permissioning. Source coverage breadth determines whether ungoverned shadow paths form wherever the platform does not reach. A shared integration layer versus per-team rebuilds determines whether governance debt compounds with each new team or holds flat. Audit and versioning at the connector layer determine whether compliance is reconstructible, or opaque when a regulator asks.

So the question to ask of any platform is not how many sources it connects to. Ask what happens to permissions when a new team is onboarded. Ask what happens when a source system revokes access mid-deployment, when the organization switches models, or when a compliance review requires reconstructing what an agent did three months ago. Those answers come from the connector layer, and everything else follows from them.