CONNX puts legacy databases behind MCP—but “read access” still needs a production boundary
Version 15.0 packages OAuth, optional Vault-backed source credentials and SQL guidance into a containerized MCP server. Teams should verify what the Community Edition actually prevents before connecting an agent.
Software AG’s October release gives enterprise teams a direct way to put CONNX-connected data behind an AI-tool interface. CONNX 15.0 adds an MCP Server Community Edition that can run as a container and expose remotely accessible MCP over streamable HTTP or HTTPS.
That matters because CONNX is positioned around access to legacy, relational and other data sources, plus virtualization and replication. The MCP server therefore is not merely another chatbot connector: it can become a new route from an agent to systems that were previously reached through desktop tools, dashboards or integration pipelines.
The release separates two authentication hops
The release highlights list OAuth between the MCP client and the CONNX MCP server. Authentication from CONNX to the underlying data sources can use Vault, but that integration is optional.
Operators should model those as separate trust boundaries. OAuth answers which client may call the MCP endpoint. Source credentials determine what the resulting session can do inside each connected database. A successful OAuth check does not, by itself, prove least privilege at the database hop.
“Read access” is the starting claim, not the finished control
Software AG describes the Community Edition as providing read access to CONNX data sources. The announcement does not spell out whether that guarantee is enforced by the MCP tool surface, the CONNX layer, source-account grants, SQL parsing, or some combination of them. It also does not publish limits for row counts, query cost, timeouts or concurrent requests.
Before production use, teams should test the boundary with the actual source identity: attempt writes and DDL, invoke stored procedures, query sensitive system catalogs, and run deliberately expensive reads. Database-native read-only grants and workload controls should remain the backstop until the vendor documents stronger enforcement.
The SQL skill needs its own regression set
The package also includes a “CONNX SQL expert skill” intended to improve an LLM’s use of CONNX SQL. That is useful for dialect guidance, but it introduces another versioned behavior surface. Teams should keep a small golden set covering joins, date handling, null behavior and source-specific syntax, then rerun it whenever the server image or skill changes.
The practical rollout sequence is straightforward: pin the container image; require OAuth; prefer Vault-backed source credentials; give those credentials database-native read-only rights; cap query cost and duration; and log the client identity, source identity and executed SQL together. CONNX 15.0 supplies the connection path. Production safety still depends on proving what happens at both ends of it.
sources
- October 2026 Product Release: CONNXtechcommunity.softwareag.com
comments · 0