Column-level permissions for AI database agents: protect sensitive fields before the model sees them
The fastest way to leak sensitive data through an AI database agent is to expose columns the model never needed.
Most teams think about table access first: can the agent query customers, invoices, events, tickets, or users?
That is necessary, but not enough. The risky fields are often inside otherwise legitimate tables: email, phone, address, notes, internal flags, health data, payment references, tokens, raw payloads, and free-text support history.
Column-level permissions make the safe surface explicit before the model ever sees a result.
Table access is too broad
A user may ask, “Which enterprise accounts are at renewal risk?”
The agent may need account name, renewal date, plan, health score, usage trend, and owner. It probably does not need billing contact email, private notes, contract attachment IDs, or support transcripts.
If the MCP database server exposes the raw table, the model has to behave perfectly every time. That is not a security boundary.
Related: Data minimization for AI database agents.
Start with approved projections
The safest pattern is to expose approved views or projections instead of raw tables.
For example, an account_health view can include the fields needed for business analysis while excluding private notes, direct identifiers, and operational secrets. The model gets a useful business object, not a dump of every column engineering ever added.
Related: Approved views for AI database agents.
Separate identity from analysis
Some questions need aggregate trends, not row-level identity.
If the user asks for churn drivers by segment, the answer may only need counts, percentages, and grouped reasons. Returning raw customer emails is unnecessary risk.
Column policy should support modes like aggregate-only, pseudonymized, masked, and privileged identity lookup. The agent should not decide that boundary from vibes.
Related: Result redaction for AI database agents.
Make sensitive fields impossible to select
Relying on the prompt to say “do not select secret columns” is weak.
The database credential, view layer, or MCP execution policy should enforce which columns can be selected. If a query requests a blocked field, the tool should return a structured refusal that explains the allowed alternative.
Related: Scoped credentials for MCP database servers.
Audit what was exposed
Every answer should be traceable to the fields that were actually returned.
A useful audit record includes user identity, role, source object, selected columns, masked columns, blocked columns, policy version, row count, query hash, and request ID.
That turns privacy review from guesswork into evidence.
Related: Audit-ready MCP database workflows.
Where Conexor fits
Conexor is MCP infrastructure for connecting AI clients to databases and APIs. Production AI database access needs scoped credentials, approved views, result redaction, column policy, and audit trails — not just natural-language SQL.