When AI teams first build enterprise data connections, the instinct is to write a thin API wrapper: a function that calls the data source, formats the response, and returns rows to the agent. This works for a proof of concept. It fails at scale, and it fails in a particular way that is easy to miss until you are three months into a production deployment with a compliance team asking questions.
The problem is not the API call itself. The problem is everything that must happen around that call in a production enterprise environment: credential management, schema stability, access policy evaluation, and a complete audit record of every data access event. None of these concerns belong inside the agent. They belong at the connector layer.
What a production enterprise connector actually does
A production connector for enterprise AI is not a wrapper around an API. It is a protocol boundary with four distinct responsibilities.
The first is credential isolation. The connector holds the connection credential; the AI agent never sees it. This is not just good security hygiene: it is a requirement for any security review in a regulated environment. When an agent is compromised or its context is leaked in a prompt injection attack, the attacker should not find database credentials or OAuth tokens in the dump. The connector is the trust boundary, and it must be enforced at that layer, not depended on agent-side discipline.
The second is schema negotiation. Enterprise data sources change their schemas. A hardcoded connector that maps field names at write time will break silently when a column is renamed, a table is split, or a view is restructured. A production connector declares its schema at registration time and revalidates it on each connection, surfacing schema drift as a typed error before it produces incorrect query results downstream. In a SAP ERP environment where table names follow naming conventions like MARA and KNA1, and field mappings change across ERP versions and configuration namespaces, this matters enormously.
The policy layer is not optional
In regulated industries, every data access event must produce a record: which agent requested data, which fields were returned, which policy rule authorized the request, and the exact timestamp. This is not a logging concern you can add later. It is a compliance requirement that shapes the connector architecture from the start.
When audit requirements are addressed after the connector is built, teams typically add application-level logging. Application-level logging has two structural problems. First, it can be bypassed. If a bug in the application code skips the logging call, the access event is unrecorded. Second, it captures the application's view of the data access, not the actual data layer event. Compliance auditors need the second kind. They need evidence that the log is produced at the protocol boundary, not by the application that performed the access.
A connector that captures audit events at the protocol layer, before returning data to the agent, produces an authoritative record that cannot be bypassed by application code and is not dependent on the agent logging its own behavior correctly.
Schema negotiation in practice
Consider a connector to a Salesforce org where the AI agent needs opportunity data to build a deal summary. A naive wrapper makes a REST call to the /sobjects/Opportunity endpoint and returns the fields it happens to find. When the Salesforce admin adds a custom field namespace or renames a picklist value that the agent was filtering on, the wrapper returns wrong data silently.
A connector built with schema negotiation does something different. At registration, it introspects the target org's field definitions for the declared object types and records a schema fingerprint. On each connection, it compares the live schema against the registered fingerprint. A mismatch produces a schema drift event, which pauses the connector and alerts the operator rather than serving stale field mappings to the agent.
This is not a feature you add to a connector after the fact. Schema negotiation requires the connector to have a registration state, a connection lifecycle, and a way to propagate schema events back to the policy layer. That architecture must be designed in from the beginning.
The MCP protocol boundary
The Model Context Protocol formalizes this boundary. MCP defines a typed interface between an AI agent (the client) and a context provider (the server). The connector is a context provider that implements the MCP server interface. By building connectors as MCP servers rather than as raw API wrappers, you get the protocol boundary for free: the agent communicates with the connector using structured requests, the connector owns the credential and schema state, and every exchange is typed and introspectable.
This is not the only reason to use MCP for enterprise connectors, but it is the most practically important one for teams in regulated environments. The protocol boundary is where you insert policy evaluation and audit capture without requiring the agent to participate in compliance infrastructure.
What this means for how you build connectors
We are not arguing that thin API wrappers have no place in AI development. For a developer building a quick prototype against an internal staging database, a wrapper is the right tool. The boundary question becomes important when you need to ship to production in an environment where access must be controlled, audited, and explainable to a compliance team.
The practical consequence is that you cannot retrofit these requirements onto a connector built as a wrapper. You can add logging around a wrapper, but the log is not at the protocol layer. You can add a credential lookup function to a wrapper, but the credential is still visible to the application code. The four responsibilities we described, credential isolation, schema negotiation, policy enforcement, and protocol-layer audit capture, require a connector architecture that is designed for them from the start.
Building that architecture once and applying it across all your enterprise data sources is the core of what a governed connector platform provides. The alternative is building it per data source, per AI project, repeatedly. Teams that have tried both approaches know which one they would choose in retrospect.
