Parameterized Interpreter Call¶
A safe-invocation method — instantiates Data-Control Boundary Inertization
Sends untrusted values to an interpreter through its binding interface so they travel in a separate operand channel and are parsed as data, never as command.
Instead of assembling a command string that mixes a fixed template with untrusted values and handing the whole string to an interpreter, you hand the interpreter a fixed command with placeholders plus the values separately, through the interpreter's own parameter-binding interface. The defining idea is that the safety is delegated to the interpreter: its parser compiles the command structure once, from trusted text only, and then slots the bound values into operand positions where they can no longer be re-read as syntax. A value like '); DROP TABLE ... bound as a parameter is just a string to match on, because the interpreter finished parsing before it ever saw that string. This is what separates the mechanism from Structured Command Construction, which builds the command as structure on the caller's side precisely for interpreters that offer no such binding interface.
Example¶
A support portal lets users search past tickets by keyword. The naive version pastes the keyword into a query string, so a keyword like x' OR '1'='1 changes what the query means. The parameterized version sends the database a fixed statement — SELECT ... WHERE subject LIKE ? — and the keyword as a bound parameter, separately. The database compiles the statement first, from the developer's trusted text alone, and only then binds the keyword into the ? slot as an opaque value. A user who types x' OR '1'='1 now searches for tickets whose subject literally contains those characters — an empty result, not a bypassed filter. The untrusted string still reached the interpreter, but it arrived after parsing was done, in a channel the parser treats as data. Nothing about the value can promote it to control.
How it works¶
- The command is written once as a static template with typed placeholders; that template text is trusted and contains no untrusted input.
- The interpreter parses and compiles the template into a fixed plan before any value is supplied — the plan's shape is frozen.
- Untrusted values are passed through the binding API into operand slots of the already-fixed plan, handled as literals of a declared type and never re-lexed as command syntax.
- The separation is enforced by the interpreter, not by escaping or filtering the value — no attempt is made to "clean" the input, only to keep it in its lane.
Tuning parameters¶
- Bind-vs-build boundary — which parts of the command are fixed template and which are bound values. Pushing more into bound operands shrinks the trusted-text surface; but structural choices (which table, which sort direction) can't be bound and need another control.
- Parameter type strictness — binding a value as an integer or date versus an opaque string. Tighter typing rejects malformed operands early; looser typing accepts more and leans entirely on the channel separation.
- Prepared-plan reuse — reusing a compiled statement across calls. Reinforces the "parse once" property and improves performance, at the cost of plan staleness on skewed data.
- Coverage discipline — whether every call site binds, or some legacy paths still concatenate. The guarantee is only as strong as the least-parameterized query.
When it helps, and when it misleads¶
Its strength is that it makes the data/control boundary a property the interpreter enforces, rather than a string-hygiene habit the developer must get right on every call — the standard first-line control against injection into a query language.[1] It fails exactly where the untrusted part is structural rather than a value: you cannot bind a table name, a column, a sort direction, or an arbitrary fragment of the command's grammar, so code that builds those from user input is unprotected no matter how many other parameters are bound. The classic misuse is the half-measure — parameterizing the obvious values while still concatenating an identifier or an ORDER BY clause, and believing the query is now safe. The discipline that guards against this is to keep untrusted input out of structural positions entirely (route it through an allowlist of permitted identifiers) and to treat any concatenation into a command as a defect, not a shortcut.
How it implements the components¶
safe_interpreter_interface— it is the safe interface: the binding API through which the caller reaches the interpreter without ever handing it a mixed command-plus-data string.channel_separation_boundary— the fixed statement travels in the command channel and the bound values in a separate operand channel; the boundary between them is maintained by the interpreter across the call.
It does not classify which fields are data versus control up front (data_control_role_classifier) or make the resulting action auditable as structure (explicit_handoff_record) — those belong to Structured Command Construction; nor does it validate the values against an allowlisted grammar, which is the Allowlisted Parser or Schema Validator.
Related¶
- Instantiates: Data-Control Boundary Inertization — supplies the interpreter-level channel separation the archetype relies on at the point of execution.
- Sibling mechanisms: Structured Command Construction · Contextual Output Encoding · Allowlisted Parser or Schema Validator · Capability-Scoped Tool Invocation · Content Security Policy or Execution Policy · Injection Payload Regression Tests · Least-Privilege Execution Context · Rejection or Quarantine Queue · Taint Tracking or Provenance Labeling · Template or Markup Sandbox
Editorial Notes¶
Form Classification¶
Form family: Structure, Architecture & Configuration
Rationale: The mechanism installs a fixed-plan separation between trusted command syntax and typed untrusted operand slots enforced by the interpreter.
Nearest alternative: Control, Automation & Runtime — The interpreter processes calls at runtime, but the primary form is the enduring command/data boundary architecture.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Parameterized Interpreter Call is most directly rooted in computer science and software engineering's formal and practical treatment of computation, interfaces, data, and reliable systems. The lineage fits its defining practice: Sends untrusted values to an interpreter through its binding interface so they travel in a separate operand channel and are parsed as data, never as command.
Related originating lineages:
- Security Studies & Intelligence Analysis — Parameterized Interpreter Call also draws materially on security and intelligence practice's adversarial testing, escalation, trust boundaries, and protected communications, which shaped this mechanism rather than merely adopting it as an application.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
Parameterization protects the interpreter it targets and no other. A value safely bound into a database call can still be dangerous when it later flows unescaped into HTML, a shell, or a model prompt — each interpreter needs its own boundary. The mechanism is per-sink, not a global cleanse.
References¶
[1] SQL injection is catalogued as CWE-89; parameterized queries (prepared statements) are its standard first-line defense precisely because they move untrusted input out of the parsed command text. The well-known limit is that identifiers and other structural elements cannot be supplied as bound parameters. registry ↩