Five read-only guardrails
01

Identity: dedicated read-only account

02

Scope: database, table, column allowlist

03

Statement: parse and block danger

04

Resource: scan, concurrency, timeout

05

Audit: question, query, result, version

Database permission is the final boundary

Ambiguity, prompt injection, or generation error can affect a model. The connection itself should have no write, DDL, grant, or admin permissions.

Prefer read replicas, governed views, or query services to protect production load and sensitive raw fields.

Parse before execution

Keyword filters are bypassed by comments, dialects, and nesting. Parse statement type, targets, functions, subqueries, and multiple statements, denying what cannot be safely understood.

Restrict accessible objects and relationship paths to an allowlist.

Limit resources and results

Set scan, row, duration, concurrency, and cost limits and inspect plans before execution. Offer aggregation or smaller time windows when a request is too broad.

Give detail exports and large queries separate approval.

Bind cache to access

Cache keys include user, organization, project, scope, semantic, and policy versions. Revoke cached and shared results after access changes.

Audit the question, query, identity, cutoff, policy decision, and summary without duplicating full sensitive output.

Use adversarial acceptance

Test writes, deletes, system tables, large scans, cross-database access, comment bypass, dangerous nested functions, and stale cache after revocation.

AskTable.ai data connection and access controls can participate; dialects, proxy behavior, limits, and audit fields require deployment confirmation.

Public references

Ready to help your team start?

Talk through a real scenario and see how AskTable.ai can fit your business.

Book a demo