Control Data Boundary Enforcement

Keep untrusted content inert by making control authority travel only through separated, authenticated, typed, and least-privileged control paths.

Control/Data Boundary Enforcement addresses a specific kind of boundary failure: data reaches an interpreter that can treat it as instruction. The mistake is often described with domain names such as prompt injection, SQL injection, command injection, code injection, formula injection, or template injection. Those names differ by interpreter, but the abstract structure is the same: untrusted content escapes its intended data role and acquires control authority.

The solution is not merely to filter suspicious strings. The robust intervention is to make the distinction between data and control structural. Control must come through a trusted, authenticated, auditable path. Untrusted content must travel through data channels where it is encoded, typed, quoted, parameterized, or otherwise made inert. Any interpreter that still handles untrusted content should have limited capabilities and should be followed by a separate effect gate before protected state changes.

Problem Pattern

The pattern appears when three conditions coincide. First, an untrusted source can provide content. Second, that content is placed into a context with interpretive semantics: a database query, shell command, markup renderer, spreadsheet, prompt, configuration parser, policy engine, workflow engine, or tool-using model. Third, the interpreter has authority: it can read secrets, mutate records, call tools, execute commands, change policy, or disclose protected information.

A design is fragile when it asks the interpreter to infer which parts of a mixed channel are instructions and which are data. In a formal language, this often happens through string concatenation, unsafe escaping, or context changes. In LLM and agent systems, it happens when retrieved or user-supplied text is placed near system instructions and then the same model is allowed to call tools or act on private state. In workflow systems, it happens when log entries, messages, tickets, or configuration fields later feed automation.

Core Intervention

The intervention has four commitments:

1. Separate authority-bearing control from ordinary content. The system should know which sources are allowed to issue instructions and through which paths.
2. Make untrusted content inert. Parameter binding, contextual encoding, quoting, typed message envelopes, and non-executable slots keep data from becoming syntax.
3. Bind provenance and trust level across transformations. Content does not become trusted merely because it was stored, retrieved, summarized, logged, or passed through another system.
4. Gate effects separately from interpretation. Even if an interpreter proposes an action, a policy and capability layer should decide whether the effect is allowed.

This is why generic input validation is not enough. A value can be well-formed and still become dangerous when inserted into a different syntactic context. The boundary has to be preserved at the point of interpretation and at every representation transition.

Key Components

Component	Description
Control/Data Boundary Map ↗	The map identifies all places where content can approach authority. Obvious examples include database queries and shell commands; less obvious examples include spreadsheet exports, rendered logs, prompt contexts, template engines, workflow rules, and configuration loaders. Without this map, teams secure the front door while secondary interpreters remain exposed.
Trusted Control Channel ↗	A trusted control channel carries instructions from sources that are authenticated, authorized, versioned, and auditable. It is not just a string labeled trusted; it is a different path with different permissions, validation rules, and accountability. Signed configuration updates, typed tool calls, approved deployment workflows, and role-scoped administrative APIs are examples.
Untrusted Data Channel ↗	An untrusted data channel can carry rich content, but it cannot issue commands. A document may be evidence. A user message may express an intent. A form field may contain text. None of these should automatically become tool authority, query syntax, policy mutation, or executable markup.
Input Inertization Layer ↗	Inertization changes how content is represented so the receiving interpreter cannot treat it as control. Parameterized queries, prepared statements, command builders, contextual HTML encoding, JSON field binding, spreadsheet-safe export, and prompt role separation are all examples. The exact mechanism depends on the target context.
Typed Parse Contract ↗	A typed parse contract defines what fields exist, what role each field plays, and which operations are allowed. It replaces free-form concatenation with explicit structure. The strongest form is not "this string looks safe," but "this value can only occupy this data slot."
Provenance and Trust Binding ↗	Trust level should travel with the content. A web page quoted in a summary is still untrusted web content. A user-provided ticket description remains user-provided after storage. A model output derived from untrusted text should not become a trusted instruction merely because it was generated internally.
Effect Allowlist and Least Privilege ↗	An interpreter should not have more power than the task requires. If it must process untrusted content, it should have limited tools, limited data access, constrained network access, and a separate effect gate. A confused model or parser should not be able to turn a boundary mistake into a high-impact action.

Common Mechanisms

Parameterized query APIs and prepared statements are canonical mechanisms in database contexts. They make the query structure fixed and bind user values separately. Command builders do the same for shell or automation contexts. Contextual output encoding protects rendering contexts such as HTML, URLs, JSON, logs, and spreadsheet exports.

Schema-validated message envelopes help in distributed systems because they label the role and trust level of each field. Capability-scoped tool gateways help in agentic systems because they keep tool authorization outside the natural-language context. Taint tracking, static analysis, and adversarial boundary tests help find paths where untrusted content can reach interpreter sinks.

Sandboxed execution is valuable when interpretation of untrusted code or formulas is intentional, but it is not the whole archetype. Sandboxing reduces blast radius; Control/Data Boundary Enforcement preserves the invariant that ordinary data should not become control without explicit authorization.

• Capability-Scoped Tool Gateway
• Command Builder Interface
• Contextual Output Encoding
• Injection Boundary Red-Team
• LLM Instruction/Data Boundary
• Parameterized Query API
• Prepared Statement
• Sandboxed Execution Environment
• Schema-Validated Message Envelope
• Taint-Tracking Analysis

Parameter Dimensions

Important design dimensions include interpreter type, authority level, trust source, representation format, effect severity, reversibility, and whether interpretation is intentional or accidental. A low-impact rendering context may only need contextual encoding and safe display. A high-impact AI agent with private tools needs role separation, capability gates, least privilege, audit logs, and adversarial testing.

Another dimension is where separation happens. Early validation is useful, but late binding at the actual interpreter is usually safer. The closer the mechanism is to the control context, the less likely a later representation change will invalidate the protection.

Invariants to Preserve

The central invariant is simple: untrusted content remains data unless a trusted, authorized control path deliberately promotes it. That promotion must be explicit, scoped, auditable, and constrained by policy. If a system cannot explain where promotion occurs, who authorized it, and what authority it grants, the boundary is not yet well designed.

A second invariant is context preservation. A value safe in one context may be unsafe in another. A comment safe in a database field may become active in HTML. A log safe as text may become active when exported to a spreadsheet. A retrieved document safe as evidence may become dangerous if placed in an agent's instruction context.

Neighbor Distinctions

Boundary Permeability Control is broader: it governs what may cross boundaries in general. Domain–Codomain Delimitation defines valid input and output ranges. Closure-Preserving Operation preserves invariants under operations. Sandboxing contains execution. Least-Privilege Access Design scopes permissions. Control/Data Boundary Enforcement uses pieces of all of these, but its distinctive target is the moment untrusted content acquires instruction authority.

Examples

A web form that uses prepared statements is a straightforward example: the user name may contain surprising characters, but it is bound as a value, not query syntax. A log viewer that escapes active markup before display is another: stored text stays text when a human opens it. A tool-using assistant that treats retrieved documents as evidence but routes tool calls through a separate policy layer is a modern example: web text can inform the response but cannot command the assistant to exfiltrate data.

Non-Examples

A wrong value that causes a wrong calculation is not this archetype unless the value becomes control. A legitimate administrator using an approved console is trusted control-channel use. A spam filter or content moderator may handle harmful content, but the content remains content. A sandbox that catches a malicious script after it was intentionally accepted for execution may support the archetype, but it is not a substitute for preserving the data/control boundary.

Quality and Review Notes

This draft is intentionally named for the solution pattern rather than the failure prime. The queue target, Data-Control Plane Breach, is best represented as the failure condition that motivates Control/Data Boundary Enforcement. Future queue item control_data_channel_confusion should probably be merged or aliased into this draft unless human review finds a distinct intervention pattern.

Compression statement

When a system interprets external content in the same syntactic or semantic space as commands, a hostile or malformed datum can become a control act. The intervention is to replace content-sensitive separation with structural separation: data is encoded, quoted, typed, parsed, and provenance-bound as data; control is accepted only from trusted channels; and any interpreter that must touch untrusted content has sharply limited authority.

Canonical formula: untrusted_content + shared_data_control_syntax + interpreter_authority -> unauthorized_effect; structural_channel_separation + inert_encoding + typed_parse_contract + least_privilege -> data_remains_data

Related Abstractions

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (6)

• Capability Separation: Issuance is restricted to a privileged party while verification is open, tied by a forgery-prevention mechanism.
• Control / Data Channel Confusion: A receiver interprets attacker-controlled data as authoritative instructions because the protocol separates control from data by content inspection rather than by structure.
• Data-Control Plane Breach: Untrusted content crosses into the data channel un-inertised and an interpreter, operating correctly by its own rules, executes it as control, wielding the defender's authority for the attacker.
• Interface: A bounded, rule-governed surface across which two systems exchange information or control while hiding their internals, letting each evolve independently behind a stable contract.
• Principle of Least Privilege: Granting each component only the minimum authority its function requires bounds the blast radius of its compromise or error.
• Untrusted Input Execution: Attacker-influenced input crosses a data-to-control (or authority) boundary and a correctly-operating intermediary executes it with the intermediary's own authority, so the attacker borrows the defender's privilege without ever violating the intermediary's rules.

Also references 17 related abstractions

• Access Control: Restrict system access.
• Authority: The recognized, legitimate right to issue binding decisions within a defined scope, distinct from raw coercive force or mere persuasive influence.
• Boundary: Defines system limits.
• Channel: A bounded conduit between source and receiver whose capacity, alphabet, and noise profile are constitutive of what can cross it — a fact outside the channel's bandwidth, codebook, or noise floor is structurally inexpressible through it.
• Closure: Ensures operations remain within a set.
• Containment: Holding a hazard, process, or agent within a deliberately maintained perimeter to prevent its spread or uncontrolled interaction with the surroundings.
• Controlled Reentry: Re-establishing a suspended activity or state through staged, monitored steps with the capacity to abort, because returning to normal is a separate engineered process and not a simple reversal of the exit.
• Data Integrity: Accuracy and consistency preserved.
• Data Leakage: Information that should have been unavailable at decision time crosses the firewall into calibration, inflating measured performance until deployment exposes the gap.
• Encoding And Decoding: The paired transformation by which content is converted into a transmissible code by an encoder and recovered from it by a decoder, with faithful round-trip conditional on a shared scheme.

▸ Show 7 more

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Prompt-Injection Hardening · domain variant · recognized

Separates user and retrieved text from system, developer, tool, and policy instructions in LLM or agent systems.

• Distinct from parent: It specializes the parent for LLM contexts where data/control separation must handle conversational roles, retrieved context, and tool calls.
• Use when: Natural-language context can affect tool use, disclosure, policy decisions, or privileged actions; Retrieved documents or user messages may contain adversarial instructions.

Code-Injection Prevention · domain variant · recognized

Prevents untrusted values from becoming executable program, query, shell, template, or script syntax.

• Distinct from parent: It is the classic software-security form of the broader data/control boundary pattern.
• Use when: String construction feeds an evaluator, compiler, interpreter, template engine, shell, browser, or query processor.

Configuration or Policy Injection Prevention · domain variant · candidate

Prevents data fields, labels, logs, or tenant-provided configuration from modifying policy, routing, permissions, or control-plane behavior.

• Distinct from parent: It emphasizes administrative and infrastructure control planes rather than local command or prompt interpretation.
• Use when: Configuration, policy, routing, or automation layers ingest values from users, tenants, logs, telemetry, or external systems.

Markup and Formula Injection Prevention · domain variant · recognized

Prevents text inserted into documents, spreadsheets, pages, or logs from being interpreted as markup, formulas, links, or commands when later opened.

• Distinct from parent: It highlights delayed interpretation through rendering, export, and viewing tools.
• Use when: Data is exported, logged, displayed, or stored in a medium that has executable or active syntax.

Near names: Data-Control Plane Breach, Control / Data Channel Confusion, Untrusted Input Execution, Prompt Injection, SQL Injection, Command Injection.