Structured Command Construction¶
A command-construction method — instantiates Data-Control Boundary Inertization
Assembles a command as typed structure with untrusted values in explicit operand slots, so no command string is ever formed for them to inject into.
Rather than concatenating a command as text, you build it as a typed in-memory structure — an argument vector, a query-builder object, a request or tool-call with named fields — in which each element is placed into a declared role. The defining idea is that the dangerous surface is removed at its source: because operand positions are inherent in the structure, an untrusted value dropped into one cannot spill into command grammar, since there is no command string for it to break out of. This is the complement to Parameterized Interpreter Call: where that method delegates channel separation to the interpreter's binding interface, structured construction is what you reach for when the target has no such interface — an operating-system process, a filesystem path, an HTTP request, an agent tool call.
Example¶
A media backend runs a converter on user-uploaded files. The naive version builds a shell string, convert <userfile> out.png, so a filename such as photo.png; rm -rf /tmp/work smuggles in a second command. The structured version builds an argument vector — ["convert", userfile, "out.png"] — and executes the program directly, with no shell in between. The filename, however it is punctuated, arrives at the converter as a single argument in an operand slot; there is no shell to notice the ; because none is invoked. Element zero is the program (control); the rest are data operands, each placed by its role. And the exact vector that will run is an object the service can inspect and log before executing — the handoff is explicit, not buried in an opaque assembled string.
How it works¶
- The command is represented as a structured object — argv array, query builder, typed request — and never as concatenated text.
- Each element is inserted by role: verb/command, operand, option. The structure itself carries the data/control distinction, so no downstream parser has to infer it.
- Execution is handed to the program or endpoint directly, without an intervening string-splitting shell or interpreter that could re-lex the structure.
- Because the action is an object, it can be recorded and reviewed as the exact handoff — which verb, which operands — before it fires.
Tuning parameters¶
- Shell avoidance — exec the target directly with an argument vector versus routing through a shell. Direct exec removes the entire shell-metacharacter surface; a shell buys convenience (globbing, pipes) by reintroducing a string interpreter.
- Builder versus raw structure — using a typed query/command builder library versus hand-assembling elements. A builder enforces role placement and encodes options safely; raw assembly is lighter but easier to get wrong.
- Option constraint — how strictly option flags (which are themselves control) are limited to a fixed set. User input should choose among preset options, never supply raw flag text.
- Handoff-record granularity — whether the constructed command object is logged (verb plus operand shape) for audit. Finer records aid forensics; too much can capture sensitive operand values.
When it helps, and when it misleads¶
Its strength is that it eliminates the string-concatenation surface injection depends on, and it works for targets that offer no parameter binding at all — shells, paths, HTTP APIs, agent tool calls — which makes it the standard defense against OS command injection.[1] Its subtle failure mode is argument injection: an operand that is itself interpreted as an option (a value beginning with - read as a new flag, or a converter flag that in turn takes a filename), so role placement must extend to separating operands from options, not just the program from its arguments. The classic misuse is building the structure correctly and then flattening it back into a shell string "just to add a pipe" or "just for logging," reintroducing precisely the surface that was removed. The discipline is to keep the command a structure end to end, run it without a shell, and constrain option positions to an allowlist.
How it implements the components¶
data_control_role_classifier— every element enters the command in a declared role (verb versus operand versus option), so the structure carries the data/control classification instead of leaving a parser to guess it.explicit_handoff_record— the assembled command object is the explicit, inspectable statement of what action will run with what data, replacing an opaque concatenated string in which the data-to-action handoff is invisible.
It does not provide the interpreter-side binding channel (safe_interpreter_interface, channel_separation_boundary) — that is Parameterized Interpreter Call; nor does it render untrusted markup inert (sandbox_or_isolation_boundary), which is Template or Markup Sandbox.
Related¶
- Instantiates: Data-Control Boundary Inertization — realizes the archetype's rule that a conversion from data to action must be built as visible structure, not spliced text.
- Consumes: Parameterized Interpreter Call — where the target interpreter offers a binding interface, the constructed command hands off through it rather than being serialized to text.
- Sibling mechanisms: Parameterized Interpreter Call · 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: Control, Automation & Runtime
Rationale: Structured Command Construction operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it assembles a command as typed structure with untrusted values in explicit operand slots, so no command string is ever formed for them to inject into.
Independent corroboration: The frozen evidence defines Structured Command Construction as 'Assembles a command as typed structure with untrusted values in explicit operand slots, so no command string is ever formed for them to inject into', so its operative form is Control, Automation & Runtime.
Nearest alternative: Monitoring, Sensing & Alerting — Structured Command Construction includes features of ongoing observation, sensing, or alerting that detects and surfaces state without itself executing the response, but its defining operation is a live operational control that automatically routes, enforces, adapts, or responds during execution.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Typed commands with separated operands prevent injection.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: assembles a command as typed structure with untrusted values in explicit operand slots, so no command string is ever formed for them to inject into.
- Security Studies & Intelligence Analysis — Untrusted values cannot become executable syntax.
Review resolution: The blind reviewers agree that computer_science is the primary origin and differ only on alternate origin disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain single_lineage because the combined evidence shows one traceable formative lineage. The broader reach of specialized records portability separately from historical provenance; encyclopedia_synthesis=false preserves the affirmative synthesis judgment where either reviewer identified one.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
Use structured construction when the target has no binding interface (shells, paths, tool calls); use Parameterized Interpreter Call when the interpreter provides one. The two compose cleanly: build the command as structure, then execute it through a binding interface when one exists.
References¶
[1] OS command injection is catalogued as CWE-78; the standard mitigation is to pass arguments as a vector directly to the executed program rather than constructing and invoking a shell command line, so no shell interpreter is present to re-split the input. registry ↩