Why 11 of 18 Text-to-SQL Agents Broke Least-Privilege Rules

TL;DR: Eleven of 18 text-to-SQL agents broke least-privilege rules, even though valid credentials can mask unsafe behavior. Enforce least privilege continuously at query time through dedicated identities, scoped objects, runtime checks, full logging, and isolated recovery.

Key Takeaways: - A successful login proves authentication, not task-appropriate behavior. - Six query-time gates narrow blast radius before execution. - Shadow-mode enforcement turns denials into tested operational policy.

Eleven of 18 text-to-SQL agents broke least-privilege rules. The uncomfortable implication is that a valid database login can look healthy while the agent's effective behavior is not.

A successful connection and an approved database role can both look green while the generated query crosses a business boundary.

The role may permit valid reads, yet the agent can combine them into an operation the operator never intended. A connection test is therefore weak evidence for least privilege.

Use the text-to-SQL agent security checklist to review intent, not merely grants.

The evaluated set included 11 agents that broke least-privilege rules. The research does not provide a definitive cause for that specific split.

It instead points to missing governance and visibility, scope creep, and absent behavior checks. It also identifies teams delaying tighter controls because they fear permission errors, operational cost, and service interruption.

That is a recurring pattern, not a causal verdict. The same warning appears in why you can't govern AI you can't see.

Individually authorized capabilities can compose into an operation beyond the operator's intent. Missing runtime checks let that scope creep pass unnoticed.

Nothing in that sequence is inherently AI-specific. A person with the same state file and permissions could have caused harm, minus the pause to notice. Automation removes that pause.

Document the intended policy for one sensitive query:

Compare that policy with the SQL the agent would execute. If credential checks pass while behavior fails, the enforcement point must move closer to the query.

Static grants are necessary, but they lose the race against changing agent behavior.

A static grant can describe several individually valid reads. An agent can compose those reads into an outcome beyond the operator's intent.

Even with authorized permissions, scope creep and missing behavior checks can produce inappropriate behavior. This is why least-privilege architecture for AI agents must bind identity to a business task.

The visibility gap is deeper than database logs. Teams need to correlate: - The end-user request and stated business task - The agent, service identity, credential, and token usage - The normalized generated SQL and referenced objects - The operation class, policy decision, and execution outcome

Authentication logs prove that a credential was used. They cannot show whether the query matched the user's intent.

This compounds the problem described in your AI agent reaches every system it can touch. Reachability without intent becomes operational blast radius.

Teams often delay tighter grants because permission errors interrupt reporting workflows. They also fear the support load and cost of recovering failed queries.

The answer is progressive enforcement, not indefinite broad access. Observe one data domain, refine false denials, and then enforce it.

Automated backups were deleted together with the database in the cited risk. Recovery failed because the same destructive path could reach both systems.

A backup must therefore use a separate identity with separate permissions. Keep the protected copy beyond the reach of infrastructure-destructive credentials.

Restore access should be granular to the row or object. That lets teams recover only what the agent affected.

Build a blast-radius worksheet for every sensitive schema. It should list: - Direct and inherited grants - Reachable views and functions - Backup identities and storage paths - Data affected by one request - Separate recovery and revocation controls

The answer isn't replacing database grants with prompt instructions. It is enforcing intent through several independent control layers.

Least privilege must become a continuous control around intent and execution. A one-time grant list cannot decide whether the current task deserves every inherited permission.

Apply six gates in sequence:

1. Dedicated identity: Bind one database identity to one agent use case.
2. Scoped resources: Expose only approved schemas, views, and objects.
3. Validated operations: Parse and restrict the generated SQL.
4. Task-to-object authorization: Match the request with approved business objects.
5. Runtime behavior checks: Detect scope creep, excessive reads, and repeated attempts.
6. Isolated recovery: Keep backups outside the agent's destructive reach.

For every request, resolve five policy questions: - Who is acting? - What business task was requested? - Which objects are relevant? - Which operation is allowed? - Which rows or objects may be returned?

This turns query-time authorization for text-to-SQL agents into a concrete decision chain.

Least privilege also requires governance and visibility into token usage. Authentication shows that a credential was used, not whether the agent stayed within its task.

Verified agentic semantic-model research observed an approximately 20% average SQL accuracy increase across four data sets over an LLM-only baseline.

Accuracy helps the agent produce executable SQL. It does not determine whether that SQL should be permitted.

The semantic model should become the intent layer, not the security boundary. It can map questions to approved metrics and relationships. Query parsing, database grants, and runtime policy must enforce the decision independently.

Create a policy matrix with one row per agent use case. Include: - Identity and execution pool - Approved views and objects - Allowed operations - Row or object scope - Prohibited behavior - Required logging fields - Revocation procedure

That enforcement envelope only works when it becomes executable policy rather than another slide in a security review.

Connecting the model is easy. Building the control boundary before connection is the harder work.

Give each agent use case a dedicated database identity and execution pool. In PostgreSQL, use a restricted group role and expose only purpose-built reporting views.

The database permission templates for AI agents should start by removing inherited access to base tables.

This assumes the named reporting views already exist. Provision the login secret separately, and let the controlled wrapper activate `text_to_sql_ro`.

A `SELECT` prefix is not a security control. Parse SQL into an abstract syntax tree before execution.

Allow one approved read statement or CTE. Reject multiple statements, writes, DDL, unknown functions, and references outside the object allowlist.

A read can still cross business boundaries, expose excessive rows, traverse an unsafe view, or invoke an unapproved function. Validate referenced objects and result scope as well.

Bind parameters, apply approved limits, and route every result through the same policy-aware path.

Use organization-approved timeouts and row limits. Use read-only transactions where the database supports them.

Use a backup account with its own identities. Keep the protected copy outside the reach of credentials that can destroy the infrastructure.

Restore only at row or object granularity. The backup should survive the failure it exists to address.

Pilot the envelope on one reporting use case. Start with one identity, a small set of views, an explicit function allowlist, and no raw-table access.

These controls become trustworthy only when teams can see attempted bypasses, not merely successful queries.

Strict policy without telemetry is a production incident waiting for a trigger.

Run the policy in shadow mode. Record which valid and invalid questions would have been denied.

Review false positives, then enforce by data domain. This reduces the downtime feared by operations teams without leaving permissions permanently broad.

Use the AI SQL governance checklist to make the decision chain explicit.

Correlate every request across the full execution path:

Without this correlation, your AI agent's audit trail goes dark exactly when investigators need it.

Redact literal values that may contain sensitive data. Preserve normalized query structure so engineers can investigate policy behavior.

Authentication alone cannot reveal inappropriate agent behavior. Governance needs both the database decision and the agent's resource usage.

Configure alerts for: - Write attempts and multi-statement SQL - Access to another business domain - Traversal toward base tables - Unusual result volume - Repeated policy retries - Abnormal credential or token use

Compare each signal against configured thresholds. Alerting on every query event only creates noise.

Maintain a boundary suite containing legitimate joins and aggregations. Add prohibited cross-domain reads, writes, function calls, multi-statement attempts, and base-table traversal.

Provide a kill switch and independently disableable credentials. Re-run policy tests whenever schemas, views, grants, or prompts change.

Review attempted denials weekly at first. Convert recurring false denials into safer views or clearer rules. Promote only tested capabilities from observation to enforcement.

Once least privilege runs continuously, its value appears in operational control rather than a one-time compliance check.

Bounded AI SQL turns least privilege from a review artifact into an operating property.

Security teams can explain why each query ran. Database teams maintain a smaller, more stable permission surface. Business teams keep natural-language analytics without inheriting unrestricted database access.

The result is not weaker analytics. It is analytics with a defined operating boundary.

Credential revocation, scoped execution, query-level decisions, and isolated backups reduce the consequences of a mistaken prompt, generated query, or compromised service identity.

A failure can remain local because permissions and recovery no longer share one destructive path.

Start with one sensitive data domain:

1. Define its approved views and boundary tests.
2. Run the policy in observation mode.
3. Review denials and operational impact.
4. Enforce the tested policy.
5. Expand only after the evidence stays clean.

For teams evaluating enterprise AI systems, this discipline separates durable operations from model demonstrations.

Levitation reports 300+ successful enterprise deployments across regulated industries and 98% client retention. It is trusted by Fortune 500 brands for enterprise AI systems in India, with systems still running in production 5+ years after deployment.

A typical deployment takes 3-6 months, compared with 18-24 months for in-house teams. These figures are evidence of delivery maturity and longevity. They do not retroactively prove every deployment used this exact least-privilege architecture.

The differentiator is not SQL generation. It is useful SQL inside a boundary the CTO can explain, test, and revoke. Can your team prove that boundary for every request?

The verified research does not establish one cause for the exact 11-of-18 result. It identifies a recurring pattern: least privilege fails without governance and visibility into token usage.

It also fails when authorized scope expands, behavior checks are missing, or teams delay tighter controls because they fear downtime and operational cost.

No. A read-only credential prevents many writes but does not determine whether a `SELECT` is limited to the business objects a user should see.

Add purpose-scoped views, row or object restrictions, query validation, runtime behavior checks, and auditable execution.

Audit the complete path from user intent to generated SQL and database execution. Role grants alone are insufficient.

Confirm dedicated identities, approved objects, validated operations, runtime checks, correlated logs, revocation controls, isolated backups, and tests for legitimate and unauthorized questions.

Semantic models can improve SQL correctness, but accurate SQL can still be unauthorized. Verified research observed an approximately 20% average accuracy increase across four data sets.

Security still requires independent permission, query-validation, and behavior-enforcement layers. Can your team explain why each query matched the user's intended object and row scope?