ChatGPT Enterprise database connection: architecture for governed internal data access
An enterprise team rarely needs ChatGPT to "access the database."
It needs specific employees and workflows to answer approved questions from current internal data, without exposing unrelated tables or turning a conversational interface into an invisible administrator.
That makes the connector only one part of the architecture. Identity, capability design, data scope, execution policy, and evidence have to travel with every request.
Layer 1: resolve the human and agent identity
Every request should begin with an authenticated user, an organization or tenant, an agent or session identity, and the policy context that authorizes the task.
A shared database credential loses that chain. Prefer short-lived or tightly scoped service identities and retain the initiating user in the audit context even when the database sees a service role.
Layer 2: expose approved business capabilities
Do not begin with "run any SQL." Begin with the decisions employees need to make: summarize account usage, explain revenue movement, find overdue invoices, or compare operational performance.
Each capability should define required parameters, permitted dimensions, maximum period, tenant scope, result shape, and whether clarification is required.
For broader exploratory work, keep a separate governed query tool with stricter limits.
Layer 3: connect to read-only data products
Approved views or semantic models should encode joins, metric definitions, sensitive-field exclusions, and row-level scope. The database role should be able to read those products and fail against raw or unrelated objects.
This keeps business meaning close to the data boundary instead of asking the model to rediscover accounting or operational policy from table names.
Related: Semantic layers for AI database agents.
Layer 4: control query execution
Before execution, resolve the database, approved view, tenant, date range, expected result size, and risk class. Apply statement timeouts, row limits, scan or cost budgets, cancellation, and bounded retries.
The final SQL or tool parameters should be bound to that plan. A reconnect, parameter change, or schema migration must not silently change what was approved.
Related: MCP read-only database access.
Layer 5: return evidence with the answer
The result should include source, metric or schema version, explicit period, tenant or entity, filters, freshness, row count, truncation, and a query or trace identifier.
ChatGPT can summarize the result, but the receipt should remain available to the user and the audit system. That is how a confident sentence becomes a reviewable business answer.
Related: Audit-ready MCP database workflows.
Keep write actions on a separate path
Reading an account summary and changing an account are different authority classes.
If the workflow later needs to create a ticket, adjust a forecast, or update a record, expose a separate action with validation, idempotency, preview, approval, and compensation. Do not let mutation inherit trust from the read-only conversation.
Concrete example: customer revenue review
- A finance user asks why enterprise recurring revenue changed this quarter.
- The connector resolves the user, legal entity, quarter, currency, and approved metric version.
- A read-only tool queries the governed revenue-movement view.
- Execution limits cap time and result size.
- The result returns movement categories plus source, freshness, filters, and query ID.
- ChatGPT summarizes expansion, contraction, and churn without changing the reporting scope.
- A follow-up drill-down reuses the same entity, period, currency, and metric version.
Roll out one bounded workflow first
Start with one question whose source, owner, metric definition, and acceptable freshness are known. Build negative tests for missing tenant scope, excluded fields, oversized periods, stale schemas, and attempted writes.
Expand only when the evidence shows that the access boundary and answer contract behave predictably.
The broader workflow pattern is described in ChatGPT database query workflows.
Where Conexor fits
Conexor provides MCP infrastructure for connecting ChatGPT and other AI clients to databases and APIs through governed tools. The connector can remain simple because identity, scope, query policy, and evidence are explicit parts of the workflow.