ChatGPT Enterprise database connection: retain evidence without retaining the data
An audit log should explain what happened.
It should not quietly become a second database containing every row the AI was allowed to see.
That distinction matters when a ChatGPT Enterprise database connection moves from a demo to recurring internal use. Teams need evidence for access reviews, incidents, debugging, and control testing—but duplicating raw results into prompts, traces, approval tickets, and logs creates more copies to govern.
Separate execution evidence from business data
Start by dividing the record into two layers.
Execution evidence describes identity, policy, tool, normalized request, source, timing, limits, decision, and outcome shape. Business data is the row-level content returned by the source.
Most routine reviews need the first layer. They rarely need the second. Record that 84 rows and 12 fields were returned from an approved customer-health view under policy version 17; do not automatically copy all 84 rows into the trace.
For the surrounding architecture, see ChatGPT Enterprise database connection architecture.
Define the minimum useful receipt
A useful receipt can contain:
- authenticated user, service, tenant, and delegated workflow identity;
- client, MCP server, tool, policy, schema-context, and metric-definition versions;
- normalized filters, time range, purpose, and approved operation;
- database, environment, approved view or operation, and source freshness;
- row count, field count, bytes, truncation, redaction, and partial-result state;
- query or operation fingerprint without embedded literals;
- policy decision, approval reference when required, and structured error;
- start, finish, duration, trace ID, and evidence integrity reference.
This is enough to answer many important questions: Who asked? What authority applied? Which source and definition were used? Were limits enforced? Was the result complete? Can the event be correlated with database-native evidence?
Keep sensitive literals out of fingerprints
A normalized query fingerprint should remove or tokenize literal values before storage. Email addresses, account numbers, search terms, free-text notes, and identifiers can remain sensitive even when the SQL text looks harmless.
Do not assume hashing solves the problem. Low-entropy values can be guessed, and a stable unsalted hash can become a cross-system identifier. Use purpose-specific keyed transforms only when correlation is necessary, rotate keys deliberately, and avoid storing the original value beside the token.
Redact before the model and before the log
Redacting a transcript after generation is late: the model context already contained the value. Redacting a dashboard while the underlying trace still stores the value is cosmetic.
Apply column allowlists, approved views, aggregation, masking, and row limits before results enter model context. Apply a separate logging policy before tool inputs, outputs, exceptions, and traces are persisted.
The query layer and telemetry layer should each fail closed when their redaction policy cannot classify a field.
Related: ChatGPT database query data minimization.
Use retention classes, not one global number
Different evidence has different operational value. Define retention by class:
- security evidence: identity, authorization, policy decision, target, and integrity reference;
- reliability evidence: tool version, duration, retries, limits, and structured failures;
- approval evidence: proposed operation digest, approver, scope, expiry, and execution receipt;
- debug samples: short-lived, explicitly captured, redacted content with restricted access;
- business exports: governed as business records outside the generic AI trace.
Do not make raw result retention the default merely because storage is cheap. The default should be enough metadata to investigate, with narrowly authorized content capture for a defined case and expiry.
Make deletion propagate
A deletion workflow should cover primary traces, search indexes, analytics copies, exception payloads, replay fixtures, support tickets, and downstream exports created by the AI workflow.
Keep a map of evidence stores and their identifiers. Test that deletion removes content while preserving a minimal tombstone when the organization needs to prove the deletion workflow ran. Backups need a defined expiry and restore procedure that does not silently reintroduce deleted debug data.
Preserve replay without preserving raw rows
Reproducibility does not always require the original result set. Preserve the tool and schema contract, normalized inputs, versions, policy decision, result shape, invariants, and a controlled reference to source-native evidence.
For deterministic tests, use synthetic or approved fixtures that preserve edge cases without copying production records. If an incident requires a raw sample, capture it through a separate workflow with purpose, scope, reviewer, access control, and automatic expiry.
Correlate with database-native evidence
The AI-layer receipt should link to evidence generated below the model: database role, connection identity, approved operation or query fingerprint, timing, affected or returned row counts, timeout, and server-side audit reference.
Neither layer is sufficient alone. The AI layer explains intent and policy. The database layer proves what reached the data system.
See audit-ready MCP database workflows.
Concrete example: customer health review
A customer-success leader asks ChatGPT to summarize accounts at renewal risk. The connector calls an approved aggregate view with authenticated region scope.
The receipt stores the user and region, operation name, normalized date window, source-view version, freshness timestamp, policy version, 37 returned accounts, selected field names, redaction policy, no truncation, and a trace reference. It does not store account names, contact details, notes, or the generated narrative.
If a disputed recommendation needs investigation, a reviewer can authorize a short-lived redacted sample for the relevant accounts. That sample expires independently from the long-lived execution receipt.
Evidence-boundary test checklist
- Put an email address and account ID in a filter and inspect every log.
- Trigger a database exception containing a value from the query.
- Return an oversized result and verify counts without stored content.
- Capture an authorized debug sample and verify automatic expiry.
- Delete a subject or account and trace every derived copy.
- Restore a backup and verify deleted debug data is not made active again.
- Rotate a correlation key and verify old and new tokens do not leak identity.
- Reconstruct an event from AI-layer and database-native evidence.
Where Conexor fits
Conexor provides MCP infrastructure for connecting ChatGPT and other AI clients to PostgreSQL, MySQL, SQL Server, and APIs through governed tools. Teams can use narrow operations, scoped identities, query controls, and result receipts while keeping their evidence and retention policy aligned with the business workflow.