TL;DR: Both involve untrusted input being treated as instructions. Parameter binding keeps values from changing a fixed SQL statement's syntax; prompt labels guide model behavior, while application services must independently enforce access, audience and action rules.
How to approach it
Identify the source author, intended task and consequence before comparing mechanisms. Ask whether the model only drafts an answer or can also read private records and act. Explain what parameter binding guarantees, where that guarantee ends and what the model-facing design must enforce elsewhere. Treat the rubric below as site-authored practice guidance, not an employer's scoring system.
A strong answer
Consider a fictional document-review service. An authorized reviewer asks it to compare submissions against fixed criteria. A submission's author can edit the source document but cannot change the criteria, access other submissions or choose an external delivery audience. A source passage attempts to redirect that comparison. That is a prompt-injection attempt; whether it changes the result or causes disclosure needs observation.
The shared pattern is input being treated as something with greater authority than intended. The mechanisms differ. OWASP's SQL guidance, checked November 2026, recommends separating statement structure from bound values. A correct binding prevents that value from changing SQL syntax. It does not make concatenated structural fragments safe or decide whether a matching record belongs in the caller's permitted result.
Model APIs can preserve message roles and applications should prevent source text from becoming trusted configuration. The model still interprets the content. Delimiters and learned instruction priority can help, but a well-formed model output is not proof of permission. Avoid claiming every model architecture is identical or that useful architectural controls are impossible.
Source document
Author supplies evidence
Model result
Score or action proposal
Application check
Criteria, grant and audience
Reviewed result
Evidence and observed effect
Identify source authority
The document author may submit evidence but cannot redefine the task or grant access to other records.
| Proposed control | Property to test | Remaining boundary |
|---|---|---|
| Bind a search value in a fixed SQL statement | The value cannot change the statement syntax | Caller and object authorization |
| Mark a submission as source data | The model more reliably keeps it in the intended role | Independently enforced task and resource policy |
| Require a typed comparison result | Output has the required structure | Evidence, criterion integrity and permitted audience |
| Check the current task at the resource service | The requested read is within the grant | Downstream disclosure and other reachable services |
For the review service, preserve the criteria in controlled configuration. The author may supply evidence but cannot publish a new criterion merely by claiming authority in the document. Show reviewers source locations and uncertainties; check whether quoted evidence supports the score. Citations make a decision inspectable, not automatically correct. Human review needs an actual opportunity and basis to challenge the result.
If delivery is added, bind the material and recipients to current authorization. A verified address identifies a destination; it does not permit receiving every record. Existing scoped authority can support an automatic status message. A new or materially changed action may require approval. Review generated links, previews, exports and saved drafts as output paths too.
Measure source ingestion, forbidden proposals, service decisions and effects separately. A blocked read demonstrates one tested control; an accepted operation with a missing final receipt remains unresolved. Include legitimate comparisons and allowed changes of presentation so that the defense does not win by refusing all work. Run tests only in an authorized isolated setting with synthetic data and effect sinks.
What interviewers probe next
- “Would escaping or adding data tags fix it?” Describe the interpreter property being claimed. Tags can help a model identify source roles; they do not authorize resources or prove that source instructions cannot influence an answer.
- “What if the source contains hidden text?” Inspect the actual extraction, rendering or vision input. Hidden text does not reach every parser, and visible text can also redirect a task.
- “What if a person makes the final decision?” Assess evidence quality, reviewer authority and where the draft was already exposed. Review can reduce errors without certifying every result.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
The fictional review service compares submitted documents against controlled criteria. A document author can edit only their own submission.
Start here
The model returns the required fields but gives unsupported scores. Did the output schema work?
What property does the schema validate?
The schema may have enforced structure while the evaluation failed on evidence or criteria. Test those separately; a valid field layout does not make its values true.
Carry it forwardShape and supported meaning are separate claims.
Weak answerCalling the schema useless or treating it as proof of correctness.
Constraint changes
A reviewer may read all submissions. May a draft to one author include another submission?
Is processing access also a release grant?
No, not from read permission alone. Check the intended recipient and material against disclosure policy. Broad reviewer access does not transfer to every output audience.
Carry it forwardTrace permission through the destination.
Weak answerUsing read access as the sole delivery check.
Constraint changes
The service blocks an attempted read, but the model already had the private text. What remains?
Which paths can still expose existing context?
The denied read does not remove data already in context. Review the permitted processing scope and all generated, stored and rendered destinations; preserve evidence of any earlier exposure.
Carry it forwardA successful downstream check does not undo an earlier boundary failure.
Weak answerCounting the denied read as proof that no disclosure was possible.
Now defend it
What would make the comparison convincing?
Name the exact property of each control, show an allowed and denied case, and separate observed effects from model proposals and missing evidence.
How it's scored
Weak: Calls either problem universally solved or impossible, and relies on formatting, filtering or a stronger prompt as the permission rule.
Hire: Explains scoped parameter binding, source authority and model behavior, then puts the relevant read or effect check in an independently enforced service.
Strong Hire: Separates permitted processing from disclosure, tests valid work and observation gaps, and explains the trusted inputs and coverage of the proposed control.
Common mistakes
- Treating valid SQL syntax or valid JSON as evidence of authorized access.
- Assuming every imperative sentence is an attack, including legitimate user requests.
- Declaring text-only ranking errors harmless because no tool ran.
- Giving a document author control over the policy used to judge that document.