ChatGPT Enterprise database connection: run an access review that tests reality
An access review that checks only a group-membership spreadsheet can approve a connection that no longer exists—or miss one that is still usable.
A ChatGPT Enterprise database connection crosses several control planes: enterprise identity, ChatGPT workspace roles, connector policy, MCP tool exposure, database credentials, database grants, row-level policies, caches, and emergency procedures.
The review must test the effective path from a real user to a real result.
Map the complete access chain
For each production workflow, record the human user, organization and workspace role, authentication method, delegated or service identity, connector policy, exposed tools, database identity, approved objects, tenant scope, result handling, and evidence destination.
Do not collapse the chain into “the AI has read access.” Different users may share one database role while receiving different tool catalogs. A narrow connector policy may sit on top of a database credential with broad grants. Review both the effective path and the authority available if an intermediate control fails.
Start with the architecture in ChatGPT Enterprise database connection: governed internal data access.
Review people through business purpose
Every assignment needs an owner, approved purpose, scope, start date, review date, and expiry or removal condition. “Member of analytics” is not enough when one workflow serves finance close and another serves customer support.
Ask whether the user still performs the workflow, whether a narrower role now exists, and whether access was inherited through a group nobody owns. Sample real users and trace them through every layer instead of trusting a single export.
Separate delegated and service identity
Delegated identity preserves the human caller through policy and audit. Service identity can simplify operation but may hide which person initiated a request.
If a service identity is required, bind each call to authenticated user context, tenant, approved purpose, tool, and policy version. Confirm that the service credential cannot be reused outside the gateway and that database evidence can be correlated with the initiating user.
Compare the tool catalog with database authority
Export the tools and fields visible to each role. Then inspect the database grants, default privileges, inherited roles, SECURITY DEFINER functions, views, row-level policies, and search path behind them.
The catalog should be narrower than or equal to the approved database surface. A hidden tool is not a security boundary if the same credential can query the object through another operation.
Use role-based MCP database access to structure the comparison.
Test offboarding instead of checking configuration
Create a controlled user, establish an active conversation, issue a long-running request, and populate any relevant caches. Then disable the user and remove the role.
Verify new sessions, existing sessions, queued calls, retries, refresh tokens, connector caches, database pools, exports, and scheduled workflows. Record the maximum time until access is unusable at every layer.
A directory change is not complete revocation if a cached tool session can still execute.
Review emergency access as a separate product
Break-glass access needs a trigger, named approver, narrow scope, short lifetime, stronger authentication, visible banner, isolated credential, complete audit, and automatic expiry.
Exercise it. Request emergency access, approve it, run one bounded query, let it expire, and prove that the credential and active session no longer work. Review whether raw results entered an emergency ticket or chat channel with weaker retention controls.
Look for shadow paths
Inventory direct database clients, copied connection strings, local MCP configurations, notebooks, automation accounts, old connector versions, staging credentials that reach production, and exported result files.
An enterprise connector cannot govern a credential copied into a developer laptop. Reconcile secret-manager records, database login activity, connector inventory, and approved integrations.
Make evidence independently reviewable
For each sampled operation, an independent reviewer should be able to connect the human identity, workspace, tenant, tool and schema version, normalized inputs, database role, policy decision, source, row and byte counts, truncation, redaction, and final outcome.
Do not store the full result merely to prove that access occurred. Retain bounded metadata and references according to purpose. See evidence retention without retaining the data.
Concrete review: finance reporting
Finance has twelve approved users. The reviewer samples four, including a recent transfer. One user still inherits the workspace role but no longer owns reporting work. Another lost the connector role, yet an old service-token automation continues to run under a shared identity.
The team removes the stale membership, replaces the shared automation with workload identity, limits it to the approved revenue view, adds an owner and expiry, and tests revocation against active sessions. The review changes effective access—not just the spreadsheet.
Access-review checklist
- Map human, workspace, connector, tool, database, and result boundaries.
- Require an owner, purpose, review date, and removal condition.
- Compare visible tools with underlying database authority.
- Test offboarding across active sessions, caches, pools, and retries.
- Exercise emergency access through automatic expiry.
- Inventory direct and copied credential paths.
- Reconstruct sampled operations without retaining unnecessary data.
- Track remediation to effective closure.
Where Conexor fits
Conexor provides MCP infrastructure for connecting ChatGPT and other AI clients to databases and APIs through governed tools. An effective review should make user context, tool scope, database authority, query controls, and evidence visible as one access path.