ChatGPT enterprise database connection: separate discovery from execution credentials
The credential that helps ChatGPT discover a database should not automatically be able to query its production data.
Combining discovery and execution in one service account feels convenient: fewer secrets, fewer grants, and one connection test. It also creates an unnecessary escalation path. A metadata refresh, indexing job, or compromised discovery component inherits the same data access as a live user request.
For a ChatGPT enterprise database connection, treat discovery and execution as two distinct trust boundaries.
Discovery and execution solve different problems
Discovery answers questions about the approved surface: which views exist, what columns and types they expose, which descriptions are current, and which operations the connector may advertise.
Execution answers a user's bounded business question against a specific environment, tenant, role, time range, and policy version. It may return sensitive values even when it is read-only.
The permissions, cadence, failure modes, and evidence therefore differ. Keeping the identities separate makes those differences enforceable rather than aspirational.
Give discovery a metadata-only projection
The discovery identity should see only objects that the AI workflow may use. Prefer an approved catalog or explicitly granted metadata views over unrestricted inspection of the entire server.
- Expose approved schemas, views, columns, types, and safe descriptions.
- Hide system objects, unrelated schemas, sensitive comments, sample values, and secret-bearing configuration.
- Deny table reads and arbitrary function execution.
- Record the database, environment, schema version, discovery time, and catalog digest.
- Fail closed when the approved surface cannot be verified.
More detail is available in the MCP schema-discovery permissions contract.
Give execution a narrow runtime role
The execution identity should be able to run only approved read operations for the intended environment. Use reviewed views or stored operations, database-enforced tenant boundaries, statement and row limits, read-only transactions, and a restricted network path.
User, tenant, purpose, and environment must come from authenticated runtime context. They should not be inferred from prompt text or inherited silently from an earlier conversation turn.
For identity propagation, see preserving user identity through a ChatGPT database connection.
Promote a schema snapshot, not a credential
Discovery can produce a signed or checksummed schema snapshot containing approved objects, types, descriptions, policy references, and freshness. Review or automatically validate that snapshot, then promote it to the runtime tool registry.
Execution consumes the promoted snapshot but never receives the discovery credential. It verifies the snapshot digest and refuses a query when the runtime object no longer matches the approved contract.
This creates a useful invariant: metadata can move from discovery to execution, but authority cannot.
Separate every environment
Development, staging, and production should not share either identity. Use distinct secrets, database roles, network routes, catalog snapshots, and audit destinations. Bind the expected environment into the connection configuration and verify it after authentication.
A staging discovery job must not inspect production. A production execution service must not fall back to staging because a hostname or secret was misconfigured. Test both failures explicitly.
Rotate and revoke independently
Discovery often runs on a schedule. Execution runs on user demand. Their credentials should have different lifetimes, rotation windows, and incident playbooks.
If the discovery identity is suspected, revoke it without taking down already approved read operations. If the execution identity is suspected, stop database answers while preserving the ability to inspect the approved catalog safely. Avoid shared secret files and shared connection pools that collapse the separation.
Use the MCP database credential rotation runbook for the operational sequence.
Keep evidence for both planes
Discovery evidence should include identity, source environment, approved scope, schema version, object count, exclusions, freshness, and snapshot digest.
Execution evidence should include authenticated user and tenant, runtime role, operation version, normalized inputs, policy decision, source object, row and byte counts, truncation, freshness, and trace ID. Neither log needs raw secrets or unrestricted result payloads.
The two records should meet at the promoted snapshot digest. That lets a reviewer prove which catalog authorized a specific query.
Test the separation, not just the login
- Attempt to read an approved table with the discovery identity.
- Attempt to enumerate an unapproved schema or sensitive column description.
- Give execution a stale snapshot and change an underlying type.
- Try to use a staging identity against production.
- Revoke discovery and verify approved execution behavior remains explicit.
- Revoke execution and verify no metadata path can substitute for it.
- Attempt a cross-tenant query through an approved view.
- Reconstruct one answer from the execution trace and snapshot digest.
A successful connection test proves only that a credential works. These tests prove that each credential cannot do the other one's job.
Where Conexor fits
Conexor provides MCP infrastructure for connecting ChatGPT and other AI clients to databases and APIs through governed tools. Separating discovery from execution keeps catalog freshness, runtime identity, least privilege, and audit evidence visible as the connection moves into enterprise use.