Masked Extracts or Local Draft Models: A Debate for Agent SQL Placement

A platform team watched a checkout report stall after an agent rewrote a revenue query during a release review. The statement joined three large tables and omitted a selective predicate, so the planner chose a broad scan. An engineer cancelled the statement before it held locks, then recorded the draft path rather than the model brand. The remaining decision was where the next draft should run, and which data could leave the production boundary.

That incident is a composite scenario for this debate, not a measured outage report from a named company. It still matches a pattern that shows up whenever agents draft SQL against live catalogs without a placement rule. Better language models do not, by themselves, decide whether schema text may cross a network boundary. Software controls around placement, redaction, and rehearsal still determine whether a fluent draft is acceptable to run.

Two credible positions

Position A sends a masked catalog extract to a free hosted model, then rehearses the returned SQL on a free disposable server. Position B keeps all draft generation on a local model that remains inside the team trust boundary. That position uses an external server only as an execution witness that is loaded with synthetic rows. They disagree about which artifact may move, and about which system may see real object names.

Position A argues that hosted models often draft more fluent SQL when prompts include current table names and key relationships. A masked extract can remove row samples, comments, and high-sensitivity column names before that hosted call. A free server then provides an isolated planner and a permission set that production roles do not share. The claim is that separation of draft generation from production execution reduces lock risk more than an unrehearsed local draft.

Position B argues that column names, check constraints, and relationship graphs can still reveal product structure even after row samples are removed. A local model can read the live catalog through an internal tool and never transmit that text. The free server, if used at all, should receive only synthetic identifiers and the candidate statement. The claim is that an execution witness does not require the drafting model to sit outside the boundary.

Evidence that can actually be checked

Neither position is universally cheaper, safer, or more accurate, and this article does not report a benchmark. The useful evidence is qualitative and checkable by each team against its own written catalog policy. Hosted draft quality matters only when the team is allowed to export a defined schema subset. Local draft quality matters only when the team can actually run a model beside the catalog.

Rehearsal value depends on whether the disposable server has similar indexes, not on whether the server was free. The table below compares those placement inputs without ranking any vendor, model family, or hosting plan. Availability of a free hosted model and a free server can make Position A practical for unclassified practice catalogs. That availability does not change a contractual ban, and it does not prove that masked names are harmless.

Decision input	Favors masked hosted draft	Favors local draft model	Reject both external hops
Schema classification	Names are internal but not regulated	Names reveal unreleased product scope	Any catalog text is barred from export
Prompt contents	Row samples already stripped	Catalog text never leaves the host	A useful draft would require samples
Planner fidelity	Synthetic server can mirror indexes	Local database already mirrors indexes	No safe mirror exists this week
Bad-join failure cost	Rehearsal can catch it before production	Local explain can catch it before review	Write access cannot be prevented
Operational constraint	Hosted call and server are available now	Local model is maintained by the team	External terms are unacceptable

A placement workflow with numbered checks

The workflow below is a concrete placement procedure for the debate, and it can be run on an unclassified catalog. Each numbered step produces an artifact that a reviewer can inspect without trusting the agent's explanation. Commands are patterns for PostgreSQL-style rehearsal, and they should be adapted to the server version in use.

1. Classify the catalog extract before any prompt is built, and mark each table as exportable, mask-required, or local-only.
2. Build the extract from catalog metadata only, keeping names, types, and declared keys while dropping comments and sample values.
3. Score the extract with an automated gate that fails on missing labels, sensitive classes, or literals copied from logs.
4. Choose hosted placement only when the gate passes and a reviewer can read the exact payload before the call.
5. Rehearse on a disposable server with synthetic rows, a read-only role, and an explain plan captured before execution.
6. Record the model placement, extract hash, server identity, and explain output beside the statement hash for later review.

Artifact: a gate, a role, and four checks

The following Python is a proposal for the gate in step 3, and it is not a production policy engine. It has not been executed against a private catalog for this article, so teams should treat the output as a starting check. A passing result means the payload avoided three obvious failures, not that the schema is safe to export.

import re
from hashlib import sha256

SENSITIVE = {"email", "phone", "ssn", "api_key"}
LITERAL = re.compile(r"[A-Z0-9._%+-]+@[A-Z0-9.-]+\\.[A-Z]{2,}", re.I)

def gate(columns, payload):
    missing = [c["name"] for c in columns if "class" not in c]
    leaked = [c["name"] for c in columns if c.get("class") in SENSITIVE]
    literals = LITERAL.findall(payload)
    ok = not missing and not leaked and not literals
    digest = sha256(payload.encode("utf-8")).hexdigest()
    return {"ok": ok, "missing": missing, "leaked": leaked, "digest": digest}

A passing gate is necessary but not sufficient, because the rehearsal role still needs a database-side boundary. On PostgreSQL, a reviewer can create a read-only role and inspect the plan without granting write rights. The statements below are a pattern for a disposable server, not a claim that every host uses the same defaults. Replace the dates and table names with fixtures that contain no production values before anyone runs them.

CREATE ROLE agent_reader NOLOGIN;
GRANT CONNECT ON DATABASE rehearsal TO agent_reader;
GRANT USAGE ON SCHEMA public TO agent_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO agent_reader;
SET ROLE agent_reader;
EXPLAIN (FORMAT TEXT)
SELECT o.id
FROM orders AS o
JOIN payments AS p ON p.order_id = o.id
WHERE o.created_at >= DATE '2026-10-01';

PostgreSQL documents EXPLAIN and privilege rules in the current official reference, which is the primary source for those commands. A team should read that version's pages before copying the grants, because default privileges can differ by release. If the disposable server cannot host a faithful index set, label the plan as a syntax witness rather than a cost forecast.

Run four checks before anyone trusts the helper, and record the returned dictionary rather than a screenshot of a chat. These checks are expected behaviors for the proposal, not a transcript of an executed private run. Keep the fixture columns small enough that a reviewer can compare the dictionary with the source list by eye.

1. Pass a payload that lists only exportable columns with classes present, and expect the ok flag to be true.
2. Fail a payload that includes a column classed as email, and expect that column name to appear under leaked.
3. Fail a payload that contains an email literal in the text, and expect the gate to reject that payload.
4. Fail a column entry that omits its class field, and expect that column name to appear under missing.

Where a free practice surface fits

Some teams lack a maintained local model, yet they still need a place to practice agent SQL without touching production. In that setting, MonkeyCode's free model access and free server option can serve as the practice surfaces for that gated path. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Readers should confirm current terms before relying on either surface, because this article does not treat availability as permanent.

This article does not name models, quotas, hardware, or duration, because those facts were not supplied as stable specifications. A free option can lower the cost of trying the workflow on an unclassified catalog that already passed the gate. It cannot replace the classification gate, and it should not be treated as a permanent control boundary. If the gate fails, the reviewer keeps the draft local and still uses an isolated database for the explain step.

Limitations and who should skip this

Masking column names does not anonymize a schema, because unique table names can reveal a launch, a partnership, or a fraud rule. Position A is therefore unsafe for catalogs whose names are themselves confidential, even when row samples never appear in the prompt. A free server with empty statistics will mislead cost comparisons, so its plan cost should not be treated as a production forecast. The sample gate also misses many secret shapes, including internal identifiers that do not resemble email addresses.

Teams should not use the hosted path when contracts forbid external inference or when classification labels are incomplete. They should also skip that path when the agent can obtain write credentials on any reachable database. This debate is the wrong tool if a human acceptance step cannot be staffed for every promoted statement. An automated promotion from a fluent draft to production sits outside the decision rule that follows.

Decision rule

Reviewers should choose the masked hosted draft only when three conditions hold together for that candidate statement. Every referenced object must be classified exportable before the payload is assembled for a hosted call. The gate report must show no sensitive columns and no literals, and the rehearsal server must stay isolated from production. Choose the local draft model when any object is local-only, or when the team cannot review the exact payload before the call.

Reject both external hops when write access cannot be prevented or when no faithful non-production mirror exists. The rule prefers the stricter placement whenever the evidence is mixed, incomplete, or still waiting on classification. Fluency is not evidence of safety, and a free practice surface is not evidence of an acceptable boundary. The recorded extract hash, role grant, and explain output are the acceptance package that later reviewers should trust.

If review notes already capture plans but not placement, add the extract hash before the next agent SQL change. That single field makes the debate auditable, whether the draft model ran locally or on a free hosted practice path. Teams with an export clearance can compare both placements on fixtures and keep the stricter result when the plans disagree.