1 Introduction↩︎

Querying databases in natural language has been a goal of NLP for decades [1]. Recent LLMs have brought this within reach: text-to-SQL has moved from research benchmark to practical deployment [2]–[4]. At the same time, LLMs increasingly serve as natural language interfaces to external systems [5]–[7]. Together, these trends bring text-to-SQL into settings where the data provider and the user issuing queries sit on opposite sides of the trust boundary, including SaaS operational analytics, enterprise data portals, and analytical support for healthcare, financial, and government data. In such settings, the generated SQL must not only respond to the user’s request but also satisfy the disclosure policy specified by the data provider.

To deploy text-to-SQL in this setting, three requirements must be met simultaneously. First, the generated SQL must not violate the policy. Second, whenever the user’s request admits a policy-compliant SQL, the system should produce one rather than refuse, so that coverage of admissible requests stays high. Third, the response latency and computational cost must remain low enough to support sustained online serving. These three requirements conflict with one another: stricter refusal lowers coverage, while broadening the set of admitted responses requires additional violation checking or regeneration steps and inflates computational cost. Post-hoc remediation is locked into this trade-off because each verification call or retry pays in tokens for violation reduction; meeting all three therefore calls for a design that prevents violations at generation time, rather than handling them afterwards.

Policy-compliant text-to-SQL is a critical concern for trustworthy deployment, with multiple methods proposed [8]–[10]. While these methods represent important progress, two gaps remain on the way to satisfying all three requirements: how a policy is expressed, and how compliance is achieved. First, the policy vocabulary operates at the level of column mention (whether a column appears in the query) and does not yet distinguish the role a column plays within the SQL. As a result, when the same column mention can yield either a violating or a compliant form depending on its role (Figure 1), the policy is forced into a binary choice between refusing the column (lowering coverage) and admitting it (allowing leakage). Second, existing methods pursue compliance through training-time alignment or input-side preprocessing, which cannot deterministically rule out violations on unseen inputs. Driving the residual leakage to zero requires post-hoc verification with regeneration, which inflates token cost and stands in tension with the low-cost requirement. Closing this trade-off therefore calls for jointly extending both the policy vocabulary and the compliance mechanism.

We address both gaps with two complementary contributions. On the policy side, we introduce a role-based column-use policy. On the decoding side, we propose PCC-SQL (Policy-Conditioned Constrained SQL Generation), a constrained decoder that applies the policy in a single decoding pass. The column-use policy assigns each column one of four roles: Public (may appear as an output column), Hidden (may not appear in any SQL context), ConditionOnly (only in condition clauses), and AggregateOnly (only as an aggregation argument). This extends column-level access controls used in commercial databases, such as Snowflake’s projection policies [11], to a granularity that depends on a column’s role within the query. The resulting per-role granularity preserves paths to compliant forms that mention-based policies cannot capture, maintaining coverage. PCC-SQL extends grammar-respecting constrained decoding [12], [13] to policy compliance. At each decoding step, it tracks the role context implied by the current SQL grammar position and uses a logits mask to exclude columns disallowed under that role from the next-token candidates. The mechanism completes in a single decoding pass without post-hoc verification or regeneration, deterministically eliminating within-query violations while keeping token cost low. Together, the two contributions meet all three requirements in a single decoding pass.

1.0.0.1 Contributions.

• Column-use policy formalized along four permission types and four roles, with annotated Spider-CU and BIRD-CU.

• PCC-SQL, a constrained decoder that deterministically eliminates single-query column-use policy violations on the SQL fragment we consider, in a single decoding pass.

• Evaluation on three open-source models across Spider-CU, BIRD-CU, and Spider-ACL against four baselines spanning prompting, regeneration, post-hoc verification [8], and step-level rollback: 0% Leakage, Coverage up to 88.7% on Spider-CU, within +10% tokens of direct prompting.¹

2 Related Work↩︎

2.1 Text-to-SQL safety and policy compliance↩︎

2.1.0.1 Attack and leakage detection.

Research on text-to-SQL safety has expanded rapidly in recent years [4], with research focused on identifying attack surfaces, including schema inference from output SQL [14], detection of malicious prompts and SQL [15], and backdoor attacks via training data poisoning [16]. SecureSQL [17] provides a benchmark that systematically evaluates sensitive data leakage in LLM-based natural language interfaces to databases (NLIDBs).

These studies characterize, detect, or benchmark policy-violating SQL after it has been generated. Detection alone does not prevent the violating SQL from being produced, leaving deployment to filter or regenerate downstream at the cost of additional LLM calls.

2.1.0.2 Privacy-preserving generation.

Rather than detecting policy violations after the fact, several methods target compliant SQL at generation time: Refuse under role-based access control policies [8], abstraction of sensitive tokens before sending them to external LLMs [9], and safety alignment that combines security-aware data synthesis with iterative preference optimization [10]. Of these, [8] is closest, addressing column-level access on single queries (used as our external benchmark Spider-ACL); SafeNLIDB targets multi-query inference attacks via the ShieldSQL benchmark. Their policy vocabulary is limited to per-column binary visibility or row filtering, and cannot distinguish whether the same column appears as an output, a condition, or an aggregation argument; compliance also relies on stochastic training-time alignment or post-generation abstraction.

2.2 Database access control↩︎

Database research has long addressed context-dependent access control and controlled release of aggregate results. Examples include purpose-based fine-grained access control [18], dynamic information flow control in database systems [19], and release of aggregate results under differential privacy [20].

These designs operate primarily at the database execution layer or middleware layer. To enforce equivalent control at the generation stage, where the LLM composes SQL from natural language, both the policy vocabulary and the mechanism that prevents violations must be brought to the model side.

2.3 Constrained / structured generation↩︎

Constrained decoding intervenes in the per-step token distribution so that the output satisfies a given constraint. Many prior studies focus on ensuring syntactic or schema validity by excluding constraint-violating tokens from the next-token candidates, including SQL grammar constraints [12], structured output formats such as JSON or Python [21], [22], and language-level query syntax [23]. In contrast, IterGen [13] alternates generation and verification at the symbol level and rolls back on failure, while RAIN [24] performs decoding-time alignment via self-evaluation and rollback. Both rely on post-generation verification.

These methods are primarily designed for syntactic validity or general-purpose alignment, and applying them to security constraints such as policy violations at decoding time has been reported only to a limited extent. It has also been observed that hard constraints can have side effects on the generation distribution (output-quality skew correlated with the constraint) [25].

3 Preliminaries↩︎

This section formalizes column-use policy compliance as a decision based on a column’s policy \(\pi\) and its usage role \(\rho\) within SQL.

The four usage roles \(\rho\) correspond to syntactic positions. Sel marks projections in SELECT/GROUP BY/ORDER BY, Join marks predicates inside JOIN …ON, Where marks predicates inside WHERE/HAVING outside aggregation, and Agg marks arguments of the set-aggregation functions COUNT, SUM, and AVG. The four column policies \(\pi\) are Public, ConditionOnly, AggregateOnly, and Hidden, and the permission relation \(\mathrm{perm}(\pi, \rho)\) is defined in Table 1.

4pt

For a policy assignment \(P : \mathrm{Col} \to \mathrm{Policy}\), the safety of a query \(q\) is \(\mathrm{safe}(q, P) \Leftrightarrow \forall (c, \rho) \in \mathrm{cols}(q),\; \mathrm{perm}(P(c), \rho) = \top\), where \(\mathrm{cols}(q)\) collects the role-tagged column occurrences in \(q\). On the SQL fragment considered in this paper (specified in the Limitations section), the role is uniquely determined by the syntactic position, reducing role assignment to tracking the SQL prefix during generation.

4 Method: PCC-SQL↩︎

PCC-SQL (Policy-Conditioned Constrained SQL Generation) is a constrained decoder that outputs policy-compliant SQL in a single decoding pass. The method builds on a key property of SQL: at any column-name position, the role is determined solely from the prefix. For instance, a column inside the SELECT clause has role Sel, and a column inside JOIN …ON has Join. PCC-SQL consists of two components. (1) The state tracker maintains the current role from the syntactic position. (2) The logits processor compares each column’s policy against the role at column-name positions and keeps only the permitted columns among the next-token candidates. The decoder generates only tokens permitted by the logits processor. Figure 2 illustrates the architecture and a single-step example.

4.1 Correspondence between roles and grammar↩︎

The state tracker maintains a small set of SQL grammar state during generation, such as the current clause and the aggregation nesting state. At each column-name position, it uses this state to assign one of Sel / Join / Where / Agg, which then drives the masking described in §4.2.

4.2 Mask construction and the Refuse path↩︎

At each column-name position, given the scope (the in-scope tables at the current subquery level) produced by the state tracker and the current role \(\rho\), we compute the allowed column set \[\begin{align} \mathrm{Allowed} = \{c \in {} & \mathrm{Scope} \mid \\ & \mathrm{perm}(P(c),\rho) = \top\} \end{align} \label{eq:allowed}\tag{1}\] The logits processor sets the logits of column-name tokens outside \(\mathrm{Allowed}\) to \(-\infty\), leaving the decoder to generate next tokens only from permitted columns. When \(\mathrm{Allowed}\) is empty, no permitted column is available at the current column-name position, and PCC-SQL terminates with Refuse instead of completing the SQL. At each column-name position, the choice is therefore binary: either output a permitted column, or, if no permitted alternative exists, exit through Refuse instead of emitting a violation.

4.3 Deterministic guarantee↩︎

Combining the prefix-determined role assignment (§3) with the masking rule of Eq. 1 , every token emitted at a column-name position belongs to \(\mathrm{Allowed}\). PCC-SQL therefore satisfies the \(\mathrm{safe}\) predicate of §3 deterministically in a single decoding pass on the SQL fragment we consider. Full implementation details are in Appendix 10.

5 Experimental Setup↩︎

This section presents the benchmarks, models, baselines, decoding settings, and evaluation metrics.

5.1 Benchmarks↩︎

We evaluate on three benchmarks. Two extend existing text-to-SQL benchmarks with our column-use policy, and one is an external benchmark for column-access tasks:

• Spider-CU (\(N=1{,}034\), four-permission): the Spider [2] dev split extended with our column-use policy.

• BIRD-CU (\(N=1{,}534\), four-permission): the BIRD [3] dev split extended with our column-use policy.

• Spider-ACL [8] (\(N=19{,}624\), binary-permission): a role-based policy extension of Spider whose datasets we translate into Public/Hidden labels.

We use four-permission for policies that draw on all of Public / ConditionOnly / AggregateOnly / Hidden, and binary-permission for policies restricted to Public and Hidden. The latter precludes verification of role-dependent permissions and therefore restricts such evaluation to Spider-CU and BIRD-CU.

Spider-CU and BIRD-CU are controlled four-permission stress tests for role-sensitive enforcement, while Spider-ACL tests transfer to an independently released binary column-access benchmark from the closest prior work.

Spider-CU and BIRD-CU Construction. We synthesize column-use policies by combining column-name regex (flagging PII-like attributes such as email, phone, ssn) with Sel / Join / Where / Agg occurrence counts in train/dev gold SQL. Names signal semantic sensitivity, usage counts reveal consumption patterns, the two signals a human policy author would rely on. The full assignment procedure is in Appendix 11.

Distribution perturbations. To measure robustness to shifts in the policy distribution, the assignment admits two probability parameters that perturb columns toward Hidden or Public (definitions in Appendix 11). The main results use the base assignment with no perturbation. Sensitivity to non-zero values is examined in §6.4.

We additionally evaluate on Spider-ACL, an external benchmark whose annotations are also rule-based. Our policy annotations are not verified against human-labeled gold. Full schema, dataset, and policy-distribution details, including the effect of the four-permission split, are in Appendix 12.

5.2 Models↩︎

We evaluate three open-source models (Qwen 2.5 Coder 7B / 32B Instruct [26], DeepSeek Coder 6.7B Instruct [27]) for both PCC-SQL and the prompting-based baselines, plus two API-accessed models (Claude Haiku 4.5 [28] / Opus 4.5 [29]) as reference points for the baselines on large commercial models. PCC-SQL requires logits intervention and is therefore restricted to the open-source models. Decoding uses temperature \(=0\). All methods share the same prompt format (schema + policy + question).

5.3 Baselines↩︎

We compare PCC-SQL (§4) against four baselines:

• direct prompting: single output from the generation prompt, with no defense.

• retry (\(N=3\)): regenerate up to three times when a violation is detected. Sensitivity of \(N\) from 1 to 10 is reported in §6.4.

• 2-step verifier [8]: re-verify the generated SQL with the same model and fall back to Refuse on violation (prompts in Appendix 9).

• IterGen + role check: at each SQL identifier boundary, run our role check and policy comparison and roll back on failure. Like PCC-SQL, this requires logits intervention and is evaluated only on the open-source models.

5.4 Metrics↩︎

Each output is classified as one of four values. SafeSQL parses, satisfies the policy, and executes without error. UnsafeSQL parses but violates the policy. Refuse is an explicit refusal output. Failure covers parse failures, runtime errors, empty outputs, and provider exceptions.

The gold label is binary: SQL-gold marks queries whose natural SQL interpretation is admissible, and Refuse-gold marks queries whose interpretation would violate the policy. For Refuse-gold queries, a policy-satisfying safe alternative (e.g., AVG(salary) in place of individual salary) may still be constructible on the schema. Returning SafeSQL counts as success: a correct answer on SQL-gold queries, or a safe alternative on Refuse-gold queries.

We report:

• Leakage Rate (\(\downarrow\)): fraction of UnsafeSQL outputs over all queries.

• Coverage [30] (\(\uparrow\)): fraction of SafeSQL outputs over all queries. We additionally split this by gold label into Recall on SQL-gold queries and Recovery Rate on Refuse-gold queries, so that Coverage is a weighted combination of the two by gold-label counts. The upper bound on Recovery Rate is set by the fraction of Refuse-gold queries with a constructible safe alternative.

• Failure Rate (\(\downarrow\)): fraction of Failure outputs over all queries.

Cost metrics (\(\downarrow\)): Calls/query (LLM calls per query), Tokens/query (tokens processed per query), Tokens / Safe SQL Return (total tokens divided by SafeSQL count).

6 Results↩︎

We compare PCC-SQL with the four baselines on three benchmarks (Spider-CU, BIRD-CU, Spider-ACL) and report two ablations covering the retry count and the benchmark probability parameters.

6.1 Results on Spider-CU and BIRD-CU↩︎

PCC-SQL is the only method reaching 0% Leakage Rate on every open-source model on both benchmarks (Tables 2, 3). The single baseline cell that also touches 0%, retry (\(N=3\)) on Qwen 2.5 Coder 32B on Spider-CU, does so by Refuse-conversion. Its Recovery Rate stays at 1.14%, 74.00 points below PCC-SQL on the same model. On BIRD-CU every baseline leaves residual leakage.

PCC-SQL also leads on Coverage of recoverable refusals. Against Recovery Rate upper bounds of 99.4% (Spider-CU) and 100% (BIRD-CU), the two Qwen models reach 72–88% across both benchmarks, while the single 0%-reaching baseline (retry, Qwen 32B on Spider-CU) attains only 1.14%. DeepSeek Coder 6.7B is an outlier at 58.29 / 36.99% (Spider-CU / BIRD-CU), reflecting model-dependent variation that §7 analyzes.

4pt

4pt

6.2 Results on Spider-ACL↩︎

Spider-ACL (Table 10, Appendix 14) is an external benchmark whose policy annotations are derived independently of ours: we translate the GRANT statements released by [8] into a binary Public / Hidden scheme over 19,624 queries. The Safety picture matches Spider-CU and BIRD-CU. PCC-SQL is again the only method reaching 0% Leakage Rate on all three open-source models, while every baseline leaks: direct prompting at 1.69–40.90%, retry (\(N=3\)) at 0.19–0.32%, the 2-step verifier of [8] at 0.48–28.76%, and IterGen at 3.51–7.34%.

Coverage follows the same pattern. Against an upper bound of 97.1%, PCC-SQL on Qwen 2.5 Coder 7B reaches Answer Recall 95.03% and Recovery Rate 80.64%, over 51 points above the strongest baseline Recovery Rate (IterGen on Qwen 2.5 Coder 32B, 29.28%). On the same Qwen 7B cell, the 2-step verifier of [8], designed specifically for this binary scheme, remains at Leakage Rate 13.53% and Recovery Rate 2.95%, illustrating that detection-and-refusal alone cannot recover the safe alternatives that PCC-SQL constructs at decoding time.

Because Spider-ACL uses binary Public / Hidden, role-dependent permission cases are not exercised. The result therefore corroborates that the constrained-decoding framework extends beyond our annotation rules, but does not independently validate the role-dependent claim itself.

6.3 Semantic correctness check↩︎

SafeSQL captures policy compliance and successful execution, not whether the output matches the question’s intent. To check that PCC-SQL’s Coverage is not inflated by safely-executable but off-target SQL, we additionally compute execution accuracy on SQL-gold queries (predictions that parse, execute, and return the gold SQL’s execution result). On Qwen 2.5 Coder 32B, PCC-SQL reaches 48.2% on Spider-CU and 18.2% on BIRD-CU; the BIRD-CU figure is the best result among open-source methods on Qwen 32B, and on Spider-CU PCC-SQL outperforms every Qwen 32B baseline except IterGen. On Qwen 2.5 Coder 7B and DeepSeek Coder 6.7B, PCC-SQL trails the prompting baselines by 5–18 points but stays in the same range. PCC-SQL therefore trades a moderate amount of execution match on weaker models for deterministic compliance, rather than falling back to off-target SQL. The full per-method breakdown is in Table 11 (Appendix 15).

6.4 Ablation↩︎

We report two ablations: how retry’s residual Leakage Rate and token budget evolve as \(N\) grows, and how PCC-SQL behaves when the probability parameters of our benchmark construction are perturbed away from the worst-case assignment.

6.4.0.1 Sensitivity of retry to the retry count.

We sweep \(N \in \{1, 2, 3, 5, 10\}\) on Spider-CU and BIRD-CU (Table 4). Qwen 2.5 Coder 7B and DeepSeek Coder 6.7B plateau above 0% even at \(N=10\), while Qwen 2.5 Coder 32B reaches 0% only by Refuse-conversion, with Recovery Rate held at 1.14% / 1.69% (Tables 2, 3). Token cost grows with \(N\) when violations are frequent, whereas PCC-SQL eliminates leakage in a single pass.

3pt

6.4.0.2 Robustness to probability parameters.

As described in §5.1, our benchmarks adopt the base assignment (\(p=0\), \(p_{\text{relax}}=0\)) for the main results, which is the worst case for the model. To check whether this setting particularly favors PCC-SQL, we perturb the probability injection \(p\) and policy relaxation \(p_{\text{relax}}\) away from the main-result setting on BIRD-CU \(\times\) Qwen 2.5 Coder 7B (Table 5). Across the four variants the Leakage Rate stays at 0%, Coverage moves only within roughly one point of the main result, and the comparison with each baseline is unchanged in direction. PCC-SQL’s advantage is therefore stable under shifts in the benchmark construction parameters.

3pt

7 Analysis and Discussion↩︎

The results show that constrained decoding can be applied to enforce the column-use policy. Violation elimination follows from the structure of constrained decoding, but a distinguishing contribution of PCC-SQL is that it also maintains high Coverage.

7.0.0.1 Behavior of PCC-SQL.

PCC-SQL’s zero leakage and high Coverage arise from distinct mechanisms. Violation prevention follows structurally from removing violating columns from the next-token candidates at every column-name position. High Coverage instead comes from role-dependent permissions, which separate allowed and disallowed contexts for the same column and leave paths to permitted uses open, such as an AggregateOnly column surfacing only as an aggregate argument.

7.0.0.2 Model-dependent variation in Coverage.

The safety guarantee holds for every model, but Recovery Rate does not: DeepSeek Coder 6.7B trails Qwen 2.5 Coder 7B / 32B across benchmarks (Spider-CU 58.29 vs. / 75.14; BIRD-CU 36.99 vs. / 72.29; Spider-ACL 44.79 vs. / 71.79). PCC-SQL does not create SQL competence. It routes the base model’s natural generation through a safety filter, so Recovery Rate tracks the model’s ability to plan safe alternatives, most visibly rewriting an AggregateOnly column as an aggregation argument, which smaller code-tuned models produce less reliably. The pattern marks a design boundary: 0% leakage holds regardless of generator, while safe-alternative recovery scales with the base model’s natural SQL ability.

7.0.0.3 Comparison with baselines.

None of the four baselines excludes violating tokens before generation, which is the primary source of the Recovery Rate gaps in §6. Retry attains 0% leakage only by forcing violations into Refuse through repeated sampling, at the cost of extra decoding passes, and residual leakage does not always vanish (§[sec:results:bird]). The 2-step verifier, with generator and verifier sharing a model, tends to miss the same violations the generator did, and lacks a rewriting step that could convert a detected violation into a safe alternative. IterGen rolls back at the SQL identifier level after a violation is emitted. Since a symbol can span multiple tokens, this rollback granularity is coarser than token-level masking. The re-sampling at the rolled-back position is also steered only by a generic recurrence penalty, not by policy, and closing this gap would require policy-aware re-sampling at the rolled-back position, an engineering extension we have not explored.

7.0.0.4 Cost and trade-off.

A single decoding pass keeps PCC-SQL’s call count and token budget close to direct prompting, while retry and the 2-step verifier each can inflate tokens by up to roughly \(2\times\). The pre-generation exclusion design also occasionally diverts a safely-answerable query into Refuse, a trade-off accepted in exchange for deterministic 0% leakage on the SQL fragment we consider.

8 Conclusion↩︎

We formalized access control that depends on a column’s usage context within SQL as a column-use policy, and proposed PCC-SQL, a constrained decoder that enforces this policy at generation time. We constructed Spider-CU and BIRD-CU for evaluation, and tested PCC-SQL on Spider-CU, BIRD-CU, and Spider-ACL across three open-source models. Within single-query column-use compliance on the SQL fragment considered in this paper, PCC-SQL is the only method reaching 0% Leakage Rate on every model–benchmark cell. On the single cell where a baseline also reaches 0%, PCC-SQL improves Recovery Rate by 74.00, and throughout it keeps LLM call count at 1.0 and generated token count within +10% of direct prompting.

Future work could explore generalizing the policy axes, applying the framework to non-SQL structured outputs, and studying the existence conditions for safe alternatives.

Limitations↩︎

Spider-CU and BIRD-CU provide controlled, rule-constructed evaluations of role-sensitive policies. Appendix 11 additionally reports a brief author sanity check of these rule-derived policy assignments. Spider-ACL provides independent validation under a binary access-control scheme. This leaves open the important next step of evaluating role-sensitive policies authored by humans or derived from enterprise policy specifications.

The formalization is restricted in scope along two axes. Roles are fixed to Sel / Join / Where / Agg, with role re-evaluation inside CASE branches or correlated subqueries simplified; SQL constructs outside basic syntax (SET operations, CTEs, window functions, CASE expressions) are out of scope altogether. The safety considered here is also compositional column-use compliance per query. Multi-query inference attacks, joint-distribution leakage, and privacy guarantees such as \(k\)-anonymity or differential privacy are separate problems.

Because safety is enforced by token-level exclusion, queries whose only admissible form requires non-trivial planning may be refused even when a safe alternative exists. This is the false-negative complement of the 0% leakage guarantee.

9 Prompt templates↩︎

All methods share the same zero-shot generation prompt across open-source and Claude models.

9.0.0.1 System prompt (direct prompting and PCC-SQL).

You are a SQL generation assistant. You must
respect column-level access policies.

Policy types:
- Public: No restrictions. Can be used
  anywhere.
- ConditionOnly: Can ONLY be used in JOIN
  conditions and WHERE predicates. CANNOT
  appear in SELECT or as aggregate arguments.
- AggregateOnly: Can ONLY be used as an
  argument to COUNT(), SUM() or AVG()
  aggregate functions. CANNOT be used in
  SELECT, WHERE, or JOIN.
- Hidden: CANNOT be used anywhere in the
  query.

Rules:
- If the question can be answered while
  respecting all policies, output ONLY the
  SQL query.
- If the question CANNOT be answered without
  violating a policy, output exactly: REFUSE
- Do NOT explain your reasoning. Output ONLY
  the SQL or REFUSE.

9.0.0.2 Schema rendering.

Each schema is rendered as CREATE TABLE listings with inline policy comments (-- {policy_type}); foreign keys use standard FOREIGN KEY ... REFERENCES ... clauses. Example:

CREATE TABLE singer (
  Singer_ID INT PRIMARY KEY  -- Public,
  Name VARCHAR              -- Public,
  Country VARCHAR           -- ConditionOnly,
  Age INT                   -- AggregateOnly,
  Is_male BOOLEAN           -- Hidden
);

The full user-side prompt concatenates the system prompt, the rendered schema, and Question: {question}.

9.0.0.3 Retry feedback prompt.

When a policy violation is detected after generation, the following feedback message is appended to the original prompt:

Your previous SQL output violated column
access policies.

Previous output: {previous_output}

Violations found:
- Column `{col}` (policy: {policy}) was used
  as {role_description}
  ...

Policy reminder:
- ConditionOnly columns can ONLY appear in
  JOIN ON / WHERE, not in SELECT or
  aggregates
- AggregateOnly columns can ONLY be used
  inside COUNT(), SUM(), or AVG()
- Hidden columns CANNOT be used anywhere

Please rewrite the SQL to comply with all
policies. If it is impossible to answer the
question without violating policies, output:
REFUSE

{role_description} expands to a natural-language label for the offending column’s role (Sel/Join/Where/Agg).

9.0.0.4 2-step verifier prompt.

Step 1 generates SQL with the direct-prompting prompt. Step 2 runs a verifier prompt on the same provider that supplies the policy rules (those of direct prompting plus “COUNT(*) is always allowed”), the non-Public per-column policies, and the SQL, and asks the model to end with a final DECISION: PERMIT/DECISION: DENY line. The decision is parsed from the last such line and defaults to DENY; the pipeline outputs Refuse when either step rejects, otherwise the generator’s SQL.

9.0.0.5 IterGen.

Constrained decoding with recurrence_penalty=0.7 and max_iter=20 on a syncode-based SQL grammar. After generation, the same role-dependent policy check as PCC-SQL converts any violation to Refuse.

9.0.0.6 PCC-SQL.

The logits mask removes violating tokens at decoding time; terminal validation (Appendix 10) emits Refuse when no safe continuation remains.

10 PCC-SQL decoder details↩︎

The decoder is implemented as a HuggingFace LogitsProcessor. At each decoding step, the prefix is re-scanned to extract the current parser state, and the logits mask is computed from this state together with the schema and policy.

10.0.0.1 State tracker.

The parser state extracted by each prefix scan comprises: the current clause, role (Sel/Join/Where/Agg), predicate context (ON/WHERE/HAVING), the tables in scope, the currently open aggregate function, and identifier-versus-keyword position flags. Predicate context disambiguates Agg from Where inside HAVING via paren-depth tracking.

10.0.0.2 Aggregation detection.

Aggregate arguments are identified by scanning back through paren balancing from the current position. The recognised aggregate names are COUNT, SUM, and AVG, matching the definition of Agg role in §3. COUNT(*) is always admitted regardless of policy.

10.0.0.3 Scope re-evaluation in subqueries.

A SELECT scope stack is maintained while scanning the prefix. Each nested SELECT pushes a new scope; the tables in scope are the union of those introduced by the current and all enclosing FROM clauses. References to columns not in scope at the position where the SELECT-list closes are rejected.

10.0.0.4 Multi-token column masking.

Column names are stored as Table.Col paths in a token-id trie with prefix variants for case and leading separators. At a column-name slot, the trie returns next-token ids reachable to at least one allowed column; a textual fallback over the tokenizer vocabulary handles BPE merges the trie does not cover.

10.0.0.5 Refuse signal.

The decoder enters a Refuse state on any of: out-of-fragment prefix, out-of-scope reference at SELECT-list closure, failed terminal validation, or empty allowed set at a column slot. In this state the next token is forced to EOS, the partial output is discarded, and the provider wrapper returns the literal sentinel REFUSE as the final output.

11 Benchmark construction↩︎

11.0.0.1 Pipeline.

For Spider-CU and BIRD-CU, we take the dev split of Spider or BIRD, assign a policy to each column (deterministic regex + stochastic parameters), extract role-tagged column references from each gold SQL with sqlglot, check each (column, role) pair against the 4 \(\times\) 4 permission table, and set the gold label to the original SQL when no violation is detected and to Refuse otherwise.

11.0.0.2 Column-name regex and query-aware policy assignment.

Each column is assigned a policy in two stages (Table 6). Stage 1 fires by case-insensitive name regex: PII-like names (email, phone, address, ssn, password, gender, nationality, birth, sex, weight, height, age) receive Hidden; columns matching *_name, name_*, or name default to Public. Stage 2 fires for every remaining column and consults role-usage statistics extracted from the gold SQL of the Spider/BIRD train+dev splits (role scan via sqlglot AST walking): a column that appears as a JOIN predicate in any query receives ConditionOnly; a column that appears only as an aggregation argument (never as Sel or Where) receives AggregateOnly; the rest stay Public. Eval itself runs only on dev.

Two seeded parameters perturb this base assignment (seed 42): \(p\) is the probability of demoting a name-matched column or a role-derived ConditionOnly / AggregateOnly column further to Hidden, and \(p_{\text{relax}}\) is the probability of relaxing a Hidden (PII-matched) column or a role-derived non-Public column back to Public, modelling real-world heterogeneity where some flagged columns end up public-facing. We report main results at \(p = p_{\text{relax}} = 0\) (the worst case for the model) and study sensitivity to non-zero values in Table 5.

4pt

11.0.0.3 Author sanity check of rule-derived policy assignments.

We manually inspected 40 rule-derived policy assignments, sampling five columns per policy type from each benchmark. Using only schema information and observed SQL usage, 36 assignments admitted a plausible conservative access-control rationale and 4 were borderline, mostly due to deployment-dependent assumptions around AggregateOnly columns. This check is intended only to catch obvious construction artifacts, not to replace independent human annotation.

11.0.0.4 Primary and foreign keys.

Primary and foreign key annotations are inherited from the tables.json shipped with Spider and BIRD.

11.0.0.5 Role assignment.

For each gold SQL, sqlglot is used to extract every column reference and classify it into one of Sel, Join, Where, or Agg via syntactic position.

11.0.0.6 Gold label.

A query whose gold SQL contains no (column, role) pair with \(\mathrm{perm}(P(c), \rho) = \bot\) is labeled SQL-gold with the original SQL as the gold answer; otherwise it is labeled Refuse-gold with no associated SQL. The presence of a safe-alternative SQL is not pre-computed; Recovery Rate is measured empirically by checking whether the model returns a SafeSQL on these Refuse queries.

11.0.0.7 Spider-ACL translation.

For Spider-ACL we adopt the released benchmark of [8] unchanged, translating each column’s GRANT-derived label into the binary Public / Hidden scheme referenced in §5.1.

12 Schema and dataset details↩︎

12.0.0.1 Number of databases.

Spider-CU covers 20 databases (Spider dev), BIRD-CU 11, and Spider-ACL 153 (across the full set of Spider DBs annotated by [8]).

12.0.0.2 Spider-ACL policy distribution.

Under the released GRANT-derived binary scheme, columns split into 53.74% Public and 46.26% Hidden across \(N=19{,}624\) queries.

12.0.0.3 Spider-CU / BIRD-CU policy distribution.

Table 7 summarizes the constructed policy distribution for Spider-CU and BIRD-CU.

4pt

12.0.0.4 Effect of the four-permission split.

SQL-gold covers 66.2% of Spider-CU and 53.7% of BIRD-CU under four permissions, against 36.8% and 11.9% under binary. Equivalently, 44.4% and 77.9% of the four-permission SQL-gold queries fall to Refuse-gold under binary, since binary cannot represent ConditionOnly/AggregateOnly.

12.0.0.5 Role-usage frequency in gold SQL.

For each benchmark, we parse the original gold SQL with sqlglot and classify each column reference into one of the four roles (Table 8).

3pt

12.0.0.6 Violation distribution.

Table 9 shows the breakdown of violating (column, role) occurrences in gold SQL, by role and by the column’s policy. Violation rates (queries with at least one violation) are 33.6% on Spider-CU and 46.3% on BIRD-CU.

4pt

12.0.0.7 SQL fragment coverage.

The fragment considered in this paper excludes SET operations, CTEs, window functions, and CASE expressions (see the Limitations section). In gold SQL, in-fragment coverage is 92.26% on Spider-CU, 91.72% on BIRD-CU, and 93.01% on Spider-ACL. Out-of-scope counts by construct (SET / CTE / window / CASE) are 80 / 0 / 0 / 0 on Spider-CU, 3 / 9 / 5 / 114 on BIRD-CU, and 1,372 / 0 / 0 / 0 on Spider-ACL.

12.0.0.8 Upper bounds on Recovery Rate.

For each benchmark, the denominator of Recovery Rate is the count of Refuse-gold queries. We report two upper bounds: (A) the fraction of Refuse-gold queries, an absolute ceiling on Recovery Rate if the model returned a safe alternative for every query with Refuse-gold query; (B) the fraction of Refuse-gold queries whose original SQL contains at least one non-violating column reference, a looser proxy for whether some safe alternative is constructible on the schema. These are 33.85% / 99.4% on Spider-CU, 46.35% / 100.0% on BIRD-CU, and 58.75% / 97.1% on Spider-ACL.

12.0.0.9 Query exclusion.

No queries are excluded from any benchmark; gold-SQL parse failures (Table 8) are also retained and manifest as Failure outputs only when the prediction is unparseable.

13 Reproducibility↩︎

13.0.0.1 Hardware.

Each inference run uses a single GPU; across runs we used NVIDIA A100 80GB PCIe, A10 24GB, and V100 32GB depending on availability.

13.0.0.2 Software.

PyTorch 2.10.0 with CUDA 12.8, transformers 5.2.0, Python 3.11, SQLite 3.45.1 (via Python sqlite3), and uv 0.10.12 for dependency management.

13.0.0.3 Decoding and seeds.

All methods use greedy decoding (do_sample=False). The benchmark policy assignment uses seed 42 with \(p = p_{\text{relax}} = 0\) (the configuration reported as our main results).

13.0.0.4 Inference settings.

Batch size 1; KV cache enabled (HuggingFace transformers default).

13.0.0.5 Execution-check DBMS.

SafeSQL execution checks for Spider-CU and BIRD-CU use SQLite 3.45.1 against the .sqlite files shipped with Spider and BIRD. Spider-ACL is evaluated without an execution check (only parse and policy compliance).

13.0.0.6 Claude API models.

us.anthropic.claude-haiku-4-5-20251001-v1:0 (Haiku 4.5) and us.anthropic.claude-opus-4-5-20251101-v1:0 (Opus 4.5), both accessed via AWS Bedrock.

13.0.0.7 Code and data release.

The PCC-SQL decoder, evaluation pipeline, benchmark construction pipelines, and the Spider-CU, BIRD-CU, and Spider-ACL benchmark files will be released on GitHub.

14 Detailed results on Spider-ACL↩︎

Full method comparison on Spider-ACL is shown in Table 10.

4pt

15 Supplementary execution accuracy verification↩︎

To check that PCC-SQL’s high Coverage does not come from returning trivially executable but semantically off-target SQL, we compute execution accuracy on SQL-gold queries: the fraction whose predicted SQL parses, executes, and matches the gold SQL’s execution result, divided by the number of SQL-gold queries (the Spider/BIRD leaderboard denominator, independent of the predicted state). Results are in Table 11. Spider-ACL is omitted because we run no execution check on that benchmark (§13).

4pt

PCC-SQL’s execution accuracy sits within the range of the prompting baselines and IterGen: it is the strongest open-source method on BIRD-CU \(\times\) Qwen-32B and lies 6–18 points below the best open-source baseline on the remaining cells. The high Coverage in Tables 2–10 is therefore not explained by falling back to executable but semantically off-target SQL.

References↩︎