💻 computer science

Don't Show What They Can't See: Authorization-First Schema Context for Secure Text-to-SQL

This paper proposes an authorization-first framework that enforces fine-grained access control during schema retrieval to prevent unauthorized database metadata exposure in LLM-based text-to-SQL systems, achieving zero unauthorized object leakage while maintaining retrieval utility and significantly reducing unauthorized SQL references.

Original authors: Jianan Jiang, Zhenxin Zhang, Yucheng Long, Zhihao Li, Yaqi Wu, Yu Wang

Published 2026-09-28

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Jianan Jiang, Zhenxin Zhang, Yucheng Long, Zhihao Li, Yaqi Wu, Yu Wang

Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a librarian who can instantly translate your spoken questions into precise library commands, finding exactly the books you need from millions of shelves. This is the promise of modern artificial intelligence systems that turn natural language into database queries. These systems rely on a detailed map of the library's contents—a list of every table, column, and connection between them—to understand what you are asking. In a secure environment, however, not every part of that map should be visible to every person. Just as a bank teller cannot see the vault codes for every account, a user should only see the parts of the database they are allowed to access. The danger arises when the system accidentally shows the entire map to the translator before it even begins to work. If the translator is tricked or manipulated, it might reveal the existence of secret tables or sensitive columns, giving an attacker a blueprint for a targeted attack, even if they never see a single actual record.

Researchers at Guangzhou University and Xidian University have developed a new way to handle this problem, ensuring that the translator only ever sees the parts of the map the user is allowed to see. Their approach flips the traditional order of operations. Instead of gathering all the information, filtering out the forbidden parts, and then asking the artificial intelligence to write the query, they first check the user's permissions. They build a small, safe version of the database map that contains only the tables and columns the user is authorized to touch. Only this safe, limited map is then shown to the AI system. This prevents the AI from ever knowing about the forbidden sections, so even if a malicious actor tries to trick the system into revealing secrets, there are no secrets in the context to reveal.

The team tested this method on a collection of 20 different databases containing 240 specific questions paired with different user roles. In the standard approach, where the system sees the full database map before filtering, the AI was exposed to an average of 35.5 unauthorized objects—like secret tables or hidden columns—every single time it processed a request. With the new "authorization-first" method, that number dropped to zero. The system successfully kept all unauthorized information out of the AI's view before it even started thinking. Crucially, this security did not come at the cost of performance. The system was just as good at finding the right tables and columns for the user's actual questions as the old method was. The researchers found that the only reason the old method sometimes failed to produce the right answer was that it had to work with a much larger, cluttered set of information, whereas the new method worked with a clean, relevant subset.

A key discovery in their work was understanding where mistakes still happen. Even with the new security, the AI occasionally wrote queries that mentioned things it shouldn't have. However, the researchers traced these errors and found they were not caused by the system leaking information. Instead, the AI was simply guessing or "hallucinating" the names of forbidden columns, inventing them out of thin air. This distinction is vital: it proves that hiding the forbidden information from the AI stops the direct leakage of secrets, but it does not stop the AI from making up names. Therefore, the new method works best when combined with a final check that validates the query before it runs, creating two layers of defense. One layer stops the AI from seeing the secrets, and the second layer stops the AI from accidentally using a made-up secret.

The study also looked at how the system handles confusing or abbreviated names often found in real-world business databases, where "customer risk score" might be written as "cust_rsk_scr." When the database names were clear and descriptive, the new system performed just as well as the old one. But when the names were shortened and cryptic, the system used a special technique to add plain-language descriptions to the safe map. This helped the AI understand what the short codes meant, improving its ability to find the right data by 11.5 percent compared to a system without those descriptions. This improvement only happened when the names were hard to guess, showing that the extra help is only needed when the map is difficult to read.

To ensure the system was truly secure, the researchers simulated attacks where a user tried to trick the AI into listing all the secret tables. In the old system, these attacks succeeded about half the time, revealing a significant portion of the hidden database structure. In the new system, the attacks failed completely. The AI, having never seen the secret tables, could not list them. The only information that leaked was common words that happened to appear in the system's general instructions, not the actual database secrets. This confirmed that the new method effectively blocks the path an attacker would use to map out a database.

The researchers acknowledge that their solution is a powerful step forward but not a complete cure-all. It prevents the AI from seeing secrets it shouldn't, but it cannot stop an attacker from guessing secrets based on public knowledge or from inferring hidden data from error messages. For this reason, the new method is designed to work alongside existing security checks, not replace them. By ensuring that the AI never sees the forbidden parts of the database in the first place, the system removes a major vulnerability. It creates a boundary where the AI can only work with what the user is allowed to see, making the entire process of turning questions into database commands much safer for organizations that need to protect sensitive information.

Technical Summary: Don't Show What They Can't See: Authorization-First Schema Context for Secure Text-to-SQL

1. Problem Statement

Large Language Model (LLM)-based Text-to-SQL agents rely on database schemas (tables, columns, and join relations) to understand user intent and generate queries. In enterprise environments with fine-grained access control, schema metadata itself can be sensitive. For instance, table names like employee_compensation or column names like fraud_score reveal internal business processes and data assets even without exposing actual data records.

Current Text-to-SQL systems typically provide the complete schema or retrieve relevant objects from the full schema space before adding them to the model context. This design assumes that schema metadata is universally visible, which is unsafe in multi-tenant or restricted-access environments. The core problem addressed is process-level schema exposure:

The Threat: If a complete or partially retrieved schema enters a lower-trust component (e.g., an external LLM service, a reranking module, or a component vulnerable to prompt injection), unauthorized identifiers and structural relations are disclosed.
The Limitation of Existing Defenses: Post-generation SQL validation and Database Management System (DBMS) access controls can block unauthorized queries from executing, but they cannot revoke schema information that the model has already observed. Once an unauthorized object enters the context, it can be exploited via prompt injection, role-playing, or multi-turn probing to reconstruct sensitive schema structures.
The Gap: There is a lack of mechanisms that enforce authorization before relevance retrieval, ensuring that unauthorized objects never enter the lower-trust pipeline.

2. Methodology: Authorization-First Framework

The authors propose an Authorization-First framework that constructs a compact, safe schema context by enforcing access control before any relevance computation occurs. The system operates under a threat model where retrieval, reranking, and generation components lie outside the trusted boundary.

2.1 Core Principles

Pre-Generation Confidentiality: Authorization is treated as a prerequisite for a schema object to participate in retrieval. The system constructs a user-specific authorized subspace ( $S_u$ ) before any query-dependent relevance scoring.
Provenance-Aware Inheritance: Security extends beyond base objects (tables, columns) to derived artifacts (semantic descriptions, join hints, SQL demonstrations). An artifact is visible only if all base objects it depends on are authorized. For example, a description of an authorized column cannot mention an unauthorized table.
Non-Revealing Abstention: If a request cannot be satisfied within the authorized subspace, the system refuses the request with a generic message ("The request cannot be completed within the current access scope") that is byte-identical regardless of the cause. This prevents the refusal behavior from acting as a schema-probing oracle.

2.2 System Pipeline

The framework consists of offline governance and online inference:

Offline Governance: The schema is atomized, and semantic descriptions are generated. Crucially, descriptions are generated from the target object and its own table only, never from the global schema, to prevent leakage of hidden identifiers. Provenance labels are attached to all artifacts.
Online Inference:
- Authorized Subspace Construction: Before processing the user question, the system filters the schema to create $S_u = \text{Authorize}(S, P(u))$ , where $P(u)$ is the user's policy.
- Restricted Retrieval: Table retrieval, column selection, and relation selection occur exclusively within $S_u$ . Unauthorized objects are absent from the candidate space, not just scored low.
- Permission-Safe Semantic Enrichment: To handle abbreviated enterprise identifiers (e.g., cust_rsk_scr), the system uses semantic descriptions as a fallback for retrieval. These descriptions are fused with identifier matching but strictly adhere to provenance rules.
- Satisfiability Gate: The system checks if $S_u$ (not just the retrieved top-K) covers the required entities and operations. If coverage is insufficient, a generic refusal is issued.
- Context Assembly: The final context is assembled from authorized tables, columns, relations, and derived artifacts.

3. Key Contributions

Pre-Generation Schema Confidentiality Framework: The authors isolate pre-generation schema confidentiality as a distinct objective from post-generation SQL authorization. They define a threat model for cross-boundary schema processing and introduce a process-level exposure metric. The proposed mechanism ensures unauthorized objects and their derived artifacts are removed before any relevance retrieval computation.
Empirical Evidence for Ordering and Defense-in-Depth: Through controlled experiments where the final prompts are byte-identical between the proposed method and a "retrieve-then-mask" baseline, the authors prove that eliminating process-level leakage is attributable solely to the ordering of authorization (pre-retrieval vs. post-retrieval). Furthermore, leakage-provenance analysis demonstrates that context minimization and post-generation validation mitigate orthogonal risks: full-schema contexts leak via direct injection, while residual leaks under the proposed framework originate solely from model hallucination.
Conditional Results on Semantic Enrichment: The paper establishes that identifier opacity is a precondition for the benefit of semantic enrichment. While enrichment yields no measurable gain on standard datasets with natural-language identifiers, it significantly improves schema recall and downstream accuracy on systematically abbreviated enterprise-style schemas.

4. Experimental Results

The framework was evaluated on an access-control-augmented Spider benchmark containing 240 question-role pairs across 20 databases and four permission tiers.

Process-Level Exposure: The framework reduced process-level schema exposure from an average of 35.5 unauthorized objects per request (in full-schema baselines) to 0. This was achieved at zero utility cost compared to a budget-matched "retrieve-then-mask" baseline.
SQL Leakage: Unauthorized SQL references were reduced from 0.546 (Full schema) to 0.115.
- The reduction from 0.546 to ~0.15 was driven by context minimization (smaller context size).
- The further reduction to 0.115 was driven by the satisfiability gate.
Leakage Provenance: Analysis showed that under the proposed framework, 100% of the unauthorized SQL references that did occur originated from model hallucination (guessing identifiers) rather than supplied context. In contrast, under full-schema baselines, 100% of leaks were copied directly from the context.
Prompt Injection Resistance: In a case study involving direct enumeration and role-play attacks, the framework reduced the recovery of unauthorized tables from 40–55% (Full schema) to 0.00% in obfuscated schema settings.
Semantic Enrichment Impact: On obfuscated schemas, semantic enrichment improved retrieval recall by +11.5 percentage points and SchemaF1 by +6.6 percentage points. On natural-language schemas, it showed no measurable gain.

5. Significance and Claims

The paper claims that authorization must precede retrieval to achieve process-level confidentiality in Text-to-SQL systems. The authors argue that post-generation defenses are insufficient because they cannot revoke information already observed by lower-trust components.

The significance of the work lies in:

Architectural Shift: Moving the security boundary from the SQL execution layer to the schema context construction layer.
Defense-in-Depth: Demonstrating that context minimization (preventing the model from seeing sensitive data) and SQL validation (preventing the model from executing unauthorized queries) address orthogonal risks and should be used together.
Zero Utility Cost: Proving that strict pre-retrieval authorization does not degrade retrieval utility or generation accuracy when compared to a baseline that retrieves the same amount of authorized data but does so after seeing the full schema.

The authors remain modest regarding limitations, noting that the framework does not prevent inference from public knowledge, database error messages, or statistical disclosure. They also acknowledge that the satisfiability gate is a heuristic and that the evaluation relies on synthetic policies rather than dynamic enterprise environments. The framework is presented as an information-minimization layer that complements, rather than replaces, existing SQL validation and DBMS access controls.