Your enterprise AI should not turn every employee into one database user

An employee signs in to an enterprise app.

The app calls an AI service.

The AI service queries the database with one shared service account.

By the time SQL runs, finance, support, and operations all look identical.

That makes the first demo easy. It makes least privilege, revocation, tenant isolation, and incident reconstruction much harder.

An enterprise AI database connection needs two separate identities:

• the workload identity of the application
• the delegated authority of the user

The effective permission should be the narrowest intersection of user, tenant, application, tool, and environment policy.

Keep tenant, role, and environment outside model-controlled arguments. Derive them from authenticated context. Reauthorize when the tool executes, because users can lose access while a conversation remains open.

Do not forward one broad bearer token everywhere. Use short-lived, audience-bound credentials or token exchange for the specific downstream tool.

And test the failures:

1. run the same prompt for two tenants
2. remove a role mid-conversation
3. replay an expired token
4. send a token to the wrong audience
5. ask the model to switch environment or tenant
6. reuse cached data after revocation

The model does not need raw credentials. Operators do need a trace that connects user reference, tenant, effective role, tool version, policy version, normalized inputs, database boundary, and final answer.

Shared infrastructure is fine. Shared authority is not.

Full guide: ChatGPT enterprise API database connection: preserve user identity end to end