ChatGPT enterprise API database connection: preserve user identity end to end
A ChatGPT enterprise API database connection can authenticate successfully and still lose the identity that matters.
The employee signs in to the company application. The application calls an AI service. The AI service invokes a database tool using one shared credential. By the time SQL runs, finance, support, and operations all look like the same service account.
That shortcut makes the first demo easy. It makes least privilege, revocation, tenant isolation, approvals, and incident reconstruction much harder.
Separate service identity from user authority
The connector needs its own workload identity so systems can authenticate the service. That identity should not automatically define which business data every user may see.
Carry two distinct contexts:
- workload identity: which application, deployment, and environment is making the request;
- delegated user context: which employee, tenant, role, and approved purpose authorized this operation.
The database boundary can then evaluate the intersection of both. A trusted application is not permission to answer every employee's question.
Define the identity chain before choosing tools
Map the complete path:
employee -> enterprise app -> AI runtime -> MCP tool -> database role/viewAt every hop, document the authenticated subject, token audience, tenant, environment, expiry, scopes, and correlation ID. Decide which claims may be forwarded and which must be derived again from a trusted directory or policy service.
Do not copy a broad upstream bearer token into every downstream system. Prefer short-lived, audience-bound credentials or a token exchange that produces only the authority required by the database tool.
For the wider scope model, see scoped database access for AI agents.
Keep tenant and role outside model-controlled arguments
A tool may accept a date range, metric, customer segment, or sort order. It should not trust the model to provide tenant_id, database environment, effective role, or policy version.
Those values come from authenticated context and are applied by the server. If the conversation asks to switch tenants or use an administrator role, the tool must treat that as a new authorization request rather than another parameter.
This is one reason approved operations and views are safer than exposing arbitrary SQL. The model selects a bounded capability; the server supplies the identity boundary.
Enforce access below the prompt
Prompt instructions are useful guidance, not authorization. Use controls the model cannot rewrite:
- separate database roles for approved workflows;
- row-level security or tenant-scoped views where appropriate;
- column allow-lists and result redaction;
- statement timeouts, row limits, and result-byte limits;
- read-only transactions for analytical tools;
- separate mutation tools with validation, idempotency, and approval.
The effective permission should be the narrowest intersection of user, tenant, application, tool, and environment policy.
See the approved-views pattern for a concrete database boundary.
Make revocation take effect quickly
A user can leave a team, lose access to an account, or move between tenants while an AI session remains open. Long-lived conversation state must not preserve old authority.
Use short-lived delegated context and reauthorize at tool execution. Bind any approval to the user, operation, normalized parameters, target resource, policy version, and expiry. A previous answer or approval is not a permanent capability.
Caches also need identity and policy in their keys, plus a live authorization check for sensitive operations. A cached result created under yesterday's role must not survive today's revocation. Related: ChatGPT database connector cache invalidation.
Concrete example: enterprise support review
A support manager asks ChatGPT which enterprise accounts have repeated priority incidents this month.
The application authenticates the manager. The tool receives a trusted organization ID, support role, production-read environment, and a policy version. The model supplies only the reporting window and approved grouping.
The server queries a support-safe view. It excludes private notes, credentials, payment fields, and accounts outside the manager's region. The result returns aggregates first and requires a fresh authorization decision before record-level drill-down.
If the same prompt comes from a sales user, the operation either returns a differently scoped result or refuses. The wording is identical; the authority is not.
Return identity and policy evidence
The model does not need raw tokens, but operators need enough evidence to review the operation:
{
"operation": "priority_incident_summary.v4",
"principal": "directory-user-reference",
"tenant": "trusted-tenant-reference",
"effective_role": "support_manager_read",
"policy_version": "support-prod.v18",
"scope": {"region": "eu", "environment": "production"},
"rows": 12,
"truncated": false,
"trace_id": "..."
}Use stable references rather than copying personal details into every trace. Audit records should connect the decision without becoming a second data leak.
For the broader evidence design, see audit-ready MCP database workflows.
Test identity failures, not only valid users
- Run the same prompt as two users in different tenants.
- Remove a role while an AI conversation remains open.
- Replay an expired delegated token.
- Send a token intended for another audience.
- Ask the model to override tenant or environment scope.
- Reuse a cached result after an entitlement change.
- Retry a timed-out mutation and verify idempotency.
- Reconstruct the final answer from identity, policy, tool, and database evidence.
Where Conexor fits
Conexor provides MCP infrastructure for connecting AI clients to databases and APIs through governed tools. Preserving user, tenant, role, and policy context turns an enterprise ChatGPT database connection from a shared technical credential into a reviewable business-access workflow.