Parameters bind values in a query. They generally do not stand in for SQL identifiers such as table or column names. PostgreSQL's dynamic SQL guidance shows quoting identifiers separately from binding data values. If a tool builds SQL by concatenating an untrusted identifier, parameterizing the customer ID does not make the query structure safe. Quoting the identifier correctly addresses syntax injection, but it still may allow the agent to choose a table it should never read. Those are two separate checks.

I would not give the model arbitrary table names. Define a small allowlist of logical datasets and operations, such as customer_invoices with a fixed query shape, typed filters and bounded result size. The tool maps a dataset enum to a vetted physical table or view. It authorizes the active user and tenant against that dataset and applies row-level scope inside the database or an equally robust service boundary. If a genuinely dynamic identifier is necessary, resolve it against a trusted catalog, quote it with the database driver's identifier API, and still enforce permissions and resource limits. Never take a model-generated string as authority merely because it looks like a valid table name.

I would trace the actual SQL emitted for a normal request, a malicious name, a quoted mixed-case identifier and a table in another tenant's schema. Check the database role too. If the service account can read every table, a perfect input validator becomes the only barrier after one coding mistake. Narrow privileges and approved views reduce the blast radius. Do not let an agent write a WHERE tenant_id = ? clause as its only tenant defense if it can choose the rest of the SQL. Keep audit metadata for dataset, principal, purpose and rows accessed without copying entire private results into traces.

The interviewer may say a safe identifier-quoting function solves injection. It solves one part. An agent can still ask for payroll instead of invoices if both are valid identifiers. A new tool field can bypass the old authorization check covers a new tool field bypassing an old authorization check. This case explains why the shape of a seemingly read-only SQL tool should be constrained before you even reach the model's selected arguments.