Least-Privilege Data Access for AI Tools: Views, Redaction, Row Limits

"Which tables does the AI see?" If the answer is "all of them," you have two problems: a privacy surface you cannot defend and an accuracy problem you cannot fix. Every unnecessary table is both a row of customer data exposed to a third-party API and another chance for the model to join the wrong thing.

Least-privilege data access — exposing the minimum data needed to answer the question — is simultaneously a privacy control and a quality control. This post shows what to expose, what to hide, and the mechanisms (views, redaction, row limits) that enforce it.

The short version: narrow the world, improve the answers

Least-privilege access means every consumer — human or model — receives the smallest data scope that suffices for its task. For AI analytics the consumer is unusual: it reads schemas to plan, samples rows to understand, and sends context to a third-party API to reason. Each of those three moments needs its own control.

What to expose: the analyst surface

Build a dedicated layer the AI reads instead of production tables:

This is the schema mapping idea enforced as access control rather than documentation: the definition of "revenue" is not just written down, it is the only revenue column the model can reach.

The three enforcement mechanisms

1. Views as the access boundary

The AI's credentials (service account, read-only role) grant SELECT on curated views and nothing else. Raw tables are simply not in its permission set — not hidden by prompt instruction, unreachable by construction. A model cannot leak a table it cannot query, and cannot join one it cannot see.

-- The AI role sees this. It cannot see raw_orders at all.
-- Grain fixed, PII tokenised upstream, history windowed,
-- ambiguous columns excluded by omission.

CREATE VIEW ai_orders_daily AS
SELECT
  DATE(order_created_at, 'Asia/Kolkata') AS day,
  channel,
  state_code,
  COUNT(*) AS orders,
  SUM(net_total) AS net_revenue,
  SUM(contribution_inr) AS contribution,
  COUNT(DISTINCT customer_token) AS customers  -- tokenised, not raw id
FROM internal_orders_enriched
WHERE order_created_at >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 400 DAY)
  AND order_status = 'delivered_paid'
GROUP BY 1, 2, 3;

2. Tokenisation at the boundary

Identifying values are replaced with stable placeholders before reaching the model, and restored on return — grouping, ranking and joining behaviour preserved, identity never transmitted. This is pseudonymisation with a purpose: the model can still answer "top segments by repeat rate" because equal customers map to equal tokens. (DataLens ships exactly this as the "hide identifying values" Privacy setting; the principle generalises to any AI data path.)

3. Row and byte limits as guardrails

Cap what any single turn can pull: bounded sample rows for context, hard byte-scan ceilings on generated queries, dry-run estimates before execution. Limits bound both the privacy blast radius and the cloud bill — the cost post's two-bill problem solved once, structurally.

What stays human-gated

Frequently Asked Questions

Doesn't hiding tables make the AI less capable?

Hiding raw tables while exposing curated views makes it more capable on real questions — the eval data consistently shows wrong-table and wrong-column errors dominating. The capability you lose is answering questions about internals nobody should ask in chat anyway.

How does this interact with bring-your-own-key setups?

Orthogonally and complementarily. BYOK controls where data goes (your contracted provider); least privilege controls what goes there. Either without the other leaves half the surface open — your provider with full prod access, or a least-privilege scope sent to an unvetted endpoint.

What is the smallest version of this a two-person team can do?

A read-only database role with access to five views, tokenised customer identifiers, and a byte-scan cap. An afternoon's work, most of it writing the views you needed for correct reporting anyway. The governance review can be a calendar reminder, not a committee.

Summary & Next Steps

Least privilege for AI analytics means curated views instead of raw tables, tokenised identity instead of raw PII, and caps plus logs instead of hope. It is enforced in database roles, not in prompts — and it improves accuracy at the same time as it reduces exposure.

• Use least-privilege access design as both privacy control and quality lever.
• Use golden-dataset evals to prove the narrowed world answers better.
• Use schema mapping so the curated surface stays documented as it grows.