TL;DR. On September 29, 2026, CData opened early access to Connect AI Gateway, which folds a model gateway, an MCP gateway, and an agent gateway into one control point on top of its connector portfolio, and pairs them with a context engine that imports a company's metric definitions and accumulates knowledge from use. The pitch is enforcement at the data connection, with policy applied "at the model, the tool, and the record." That is a meaningfully lower altitude than the prompt-level and session-level gateways that preceded it, and the bundle of context plus enforcement is the right shape. The open question is the vantage point: a connector gateway governs the requests it mediates, and both an agent's direct database credential and the query executing inside the source sit on the far side of that line.
CData's announcement describes Connect AI Gateway as one control point between AI and enterprise systems: models, MCP servers, tools, and agents registered in one place, with routing rules, guardrails, token budgets, observability, and audit shared across them. It extends the Connect AI platform CData launched in March 2026, which already exposed more than 350 business systems as schema-aware tools with per-user authentication and native source-system permissions applied at runtime.
The part worth slowing down on is where the enforcement claims to live. Most AI gateways to date police the perimeter: which model a request may reach, which MCP server is allowlisted, what the prompt may contain. Connect AI Gateway sells governance at the data connection. Agents act "with exactly the access their users have," entitlements are "enforced at the source down to the record," and SiliconANGLE's coverage confirms the granularity: policies govern specific rows and columns, and an audit trail records which prompt, model, tool, and policy contributed to a response. For a category that has mostly answered "which tool was called," a control point that answers "which records came back, under whose identity" is real progress.
One control point, four systems
Unpacked, the gateway is four systems sharing a policy plane.
The model gateway routes requests across Claude, GPT, Gemini, Llama, Mistral, and DeepSeek with budgets, caching, and policy enforced in one place. CData's numbers here are about cost: in its own testing it found a 178x cost spread between the most and least expensive models producing the same correct answer with governed tools. CMO Will Davis told SiliconANGLE the routing starts policy-based and is meant to get smarter: eventually seeing the prompt and the system behavior and selecting the lowest-cost model that handles the task.
The MCP and agent gateways are the registration and permissioning surface: which MCP servers exist, which tools each agent may call, what identity each request carries. This is where the connector portfolio matters. CData's tools are schema-aware, built on the structure, relationships, and semantics of the source systems, so a governed tool can send the model only what a request needs instead of a raw table dump.
The context engine is the strategic move. It imports the knowledge a company already holds, metric definitions, business terminology, existing semantic models, and SiliconANGLE reports it reuses definitions from dbt and Power BI alongside source metadata. It then keeps what resolved each request, accumulating informal knowledge from documents and from corrections users make in conversation, stored in an editable knowledge graph that lives outside any individual model, so the context survives a model swap. SVP Marie Forshaw's framing of why is the memorable line of the launch: "You don't want AI redefining revenue every time you ask a question about revenue."
CData's accuracy claim rests on this pairing: 98.5% correct answers across 378 enterprise queries in a company-run test, against 65% to 75% for other MCP providers it tested. That is a vendor benchmarking unnamed competitors on its own question set, so apply the usual discount. But the direction of the claim matches what we have argued before: agents fail on databases for lack of resolved meaning more than for lack of access.
The vantage point ends at the connection
Everything above governs one class of traffic: requests that enter the gateway and leave through a CData connector. Two things sit outside that vantage, and they are the two that decide whether the governance story holds in production.
The first is path coverage. Policy travels with the mediated path, and only with it. An agent that holds a database credential of its own, a connection string in an environment variable, a service account inherited from the app it was bolted onto, never crosses the gateway. Its queries see whatever the database role permits, with no token budget, no record-level policy, no prompt-to-response audit trail. This is the same shape as the bypass we documented in governed metrics, where dbt's own MCP server ships text_to_sql and execute_sql beside the governed metric tools: the governed path and the ungoverned path coexist, and nothing at the gateway's altitude forces traffic onto the governed one. A control point you can route around is a convention, and conventions are exactly what agents, which take the path of least resistance through whatever credentials they find, do not reliably follow.
The gateway's span, drawn. Record-level policy and audit apply to the mediated path. The query inside the source, and any path that skips the connector, sit outside the bracket.
The second is what happens inside the source. A governed tool call still becomes a query, and the query executes on the database's side of the line. The gateway sees parameters in and records out; it does not see the plan the optimizer chose, the pages the query touched, the locks it took, or the load it put on the primary while producing those records. Record-level filtering decides what the agent may receive. It does not decide what the retrieval costs, and on the database side cost is where agent workloads bite: the same reasoning loop that is a well-behaved consumer of governed tools can be a pathological consumer of the database underneath them. The gateway's cost instrumentation, token budgets and the 178x model spread, meters the model side of the transaction. The source side has no meter at this altitude, an asymmetry we walked through in AlloyDB's agentic architecture, where isolation converts runaway agent reads from an outage into an invoice. A connector gateway does not even get the invoice.
There is a quieter version of the same boundary in the context engine. A graph that improves through continued use is written by usage, and usage now includes agents. Definitions imported from dbt carry whatever review dbt enforced; knowledge accumulated from conversational corrections carries the authority of whoever happened to correct. Those are different provenance classes, and an agent consuming the graph cannot tell them apart unless the graph says. We flagged the unlogged version of this problem in MCP's instructions field, where servers write into the model's context with nobody recording what was written. CData's audit trail is a genuine answer for the request path. Whether the knowledge graph itself gets the same treatment, validated entries distinguished from absorbed ones, is the question the early access program should be asked.
The bundle is the news
CData is a connectivity company, and to CData's credit it is explicit about limits: the context engine is positioned alongside data catalogs, not as a replacement, and record-level enforcement is scoped to what its connectors mediate. What makes the launch worth a competitive-map entry is the bundle. Gateways used to sell enforcement and catalogs used to sell meaning; Connect AI Gateway sells both from one vendor at one control point, and it landed within days of Google, Cockroach, and Neon shipping agent-facing database capacity as platform table stakes. The industry is converging on the same conclusion from two directions: agents need governed access and resolved meaning together, and whoever supplies them from one place owns the conversation. The altitude question, connector or data layer, is where the offerings will actually differ.
Where Datapace fits
Connect AI Gateway governs the connection; the database's side of the line is where Datapace works. Datapace is building the context layer between your databases and your AI: resolved meaning validated by the people who own the data, the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. If your agents reach the database through more paths than one gateway can see, that is the conversation to have: book a call.
Sources
- CData, Connect AI Gateway product page (components, "policy at the model, the tool, and the record", early access September 29 2026, 98.5% vs 65 to 75%, 178x cost spread).
- CData press release via Yahoo Finance, CData Launches Connect AI Gateway, September 29, 2026 (one control point, entitlements enforced at the source down to the record, context engine description, Amit Sharma quote).
- SiliconANGLE, CData's AI gateway governs agents' access to enterprise data, September 29, 2026 (row and column enforcement, audit trail, dbt and Power BI definition reuse, context graph portability, Forshaw and Davis quotes, catalog positioning, 378-query test).
- CData, CData Expands Connect AI press release, March 9, 2026 (350+ connectors, per-user authentication with native source-system permissions at runtime, benchmark origin).
- Enterprise Management Associates, CData Connect AI Gateway Puts Context and Enforcement at the Data Connection, Herb Blecher, September 29, 2026 (impact brief, editable knowledge graph framing).