Data Control Boundary Inertization

Keep untrusted content inert until a structural boundary, validation rule, and authority gate explicitly permit it to become control.

Essence

Data-Control Boundary Inertization solves the recurring problem in which content that should be treated as data is accidentally allowed to become instructions, policy, code, prompt, workflow control, or authorization. The archetype does not begin with the bad payload. It begins with the boundary: where can untrusted content cross from being something the system reads into something the system obeys?

The central move is to keep untrusted content inert until a deliberately designed gate changes its role. That means the system knows, before interpretation, whether a field is data, control, authority evidence, metadata, or a reference. It also means that any conversion from data into action is structurally visible. The receiver should not be discovering authority by re-parsing attacker-influenced content.

Compression statement

When a system must accept content from an untrusted or partially trusted source, do not let downstream interpreters discover by string re-parsing whether that content is data, command, policy, prompt, evidence, or authorization. Classify the role of each input before interpretation; carry untrusted material in an inert representation; pass it through structured, parameterized, or sandboxed interfaces; preserve origin and trust labels through transformations; and require an explicit policy verdict before any parsed result can trigger authority-bearing execution.

Canonical formula: accept(x from U) -> classify(role(x)) -> inertize(x, context) -> parse_under_contract(x) -> policy_verdict(parsed_x, origin, authority) -> execute only if allowed; otherwise reject/quarantine.

Structural problem

Many systems accept flexible inputs. Search boxes, filenames, message bodies, templates, spreadsheets, API requests, retrieved documents, forms, prompts, annotations, and workflow comments all look harmless when they are described as content. The risk appears when those same strings, documents, or objects are later interpreted by a component that can act: a database engine, shell, browser, model, document renderer, routing engine, policy evaluator, official workflow, or automation tool.

The intermediary may be operating correctly. The parser parses, the service uses its credential, the model follows the supplied instruction, the workflow executes the next action, and the official procedure accepts the submitted document. The failure is that the role of the input was not preserved. What entered as data crossed into control or authority without a deliberate conversion gate.

Intervention logic

The intervention has seven linked parts.

First, identify the interpreters. A design cannot protect a boundary it has not named. The relevant interpreters include obvious software interpreters, but also institutional interpreters: clerks, committees, approval workflows, agents, models, and templates that can convert content into action.

Second, classify roles before interpretation. Do not ask a downstream parser to infer from a shared string whether a part is data or command. Use typed fields, separate channels, schemas, explicit capabilities, or role-separated procedures so the role is already known.

Third, inertize content for the target context. Text that is inert inside a database parameter may not be inert inside an HTML page, shell command, prompt, spreadsheet formula, or policy expression. The representation contract must be contextual.

Fourth, use safe interpreter interfaces. Parameterized queries, structured command construction, typed tool calls, non-macro document modes, and schema-restricted workflows keep untrusted values from being stitched into executable forms.

Fifth, preserve provenance and trust state. If content began as untrusted, that fact should survive rendering, summarization, transformation, serialization, export, retrieval, and handoff.

Sixth, gate execution by policy and authority. A successful parse only proves that an input has a shape; it does not prove that the parsed result is authorized. Before acting, the system must check origin, scope, freshness, delegated authority, execution authority, and consequences.

Seventh, provide safe failure paths. If the role is ambiguous, the schema fails, the authority context is missing, or the representation cannot be made inert, the system must have an option other than permissive execution.

Key components

Component	Description
Untrusted Content Boundary Map ↗	This map records where content enters, where it travels, and where it might be interpreted. It should include visible entry points such as forms and APIs, but also secondary paths such as logs, notifications, dashboards, exports, reports, summaries, copied text, and retrieved context. Many data/control failures appear on the second or third use of content, not at first ingestion.
Data–Control Role Classifier ↗	The classifier states what role each input part is allowed to play. A comment may be data. A workflow state may be metadata. A signed request field may be authority evidence. A tool schema may be control. The point is not to invent a label taxonomy for its own sake; it is to stop attacker-controlled content from assigning itself a role.
Inert Representation Contract ↗	Inertness is contextual. A value can be safe as a database parameter and unsafe as a shell fragment. A string can be harmless as plain text and active as HTML, formula syntax, or a model instruction. The contract names how content remains data in each context: parameter binding, quoting, escaping, object wrapping, markdown restrictions, macro disabling, schema encoding, or sandbox packaging.
Safe Interpreter Interface ↗	A safe interface prevents uncontrolled concatenation. Instead of building a command by joining strings, the design passes a command name selected from an allowlist and values as typed arguments. Instead of assembling a policy from text, it passes structured claims to a policy evaluator. Instead of letting retrieved text modify agent instructions, it passes the text as evidence under a fixed tool policy.
Authority Context Gate ↗	Some inputs are dangerous because they can cause a system to spend authority. The authority gate asks whether the originator, request context, delegated scope, freshness, and execution authority justify the action. This component links the archetype to Principal-Bound Authority Mediation without making the two the same. The current archetype preserves data/control roles; principal-bound mediation resolves whose authority is being spent.
Provenance and Taint Record ↗	Trust state decays unless it is carried forward. Provenance labels, taint markers, source records, review states, and transformation histories prevent downstream stages from forgetting that content was untrusted. This is especially important when content is summarized, translated, embedded, exported, or mixed with trusted content.
Rejection or Quarantine Path ↗	A boundary design needs an answer for unsafe inputs. Rejection, quarantine, reduced-capability rendering, manual review, repair workflows, and evidence-only routing are all better than silently promoting ambiguous content into action.

Common mechanisms

Parameterized interpreter calls are a core mechanism because they separate the program from the value. SQL parameters, prepared statements, typed API calls, and safe command argument arrays all express the same structural idea.

Contextual output encoding is another common mechanism. The same untrusted value may need different treatment in HTML text, HTML attribute, URL, JSON, shell, SQL, markdown, PDF, spreadsheet, or prompt contexts. Escaping is only reliable when the context is known and stable.

Allowlisted schemas and parsers help when the safe structure can be stated. They reject unknown structure instead of attempting to recognize every malicious form. This is especially important for nested formats, documents, serialized objects, and policy expressions.

Sandboxing and least-privilege execution profiles help when some interpretation is unavoidable. They are not substitutes for data/control separation, but they limit the consequences of mistakes.

Taint tracking and provenance labeling help when content moves through many transformations. They make it possible to block unsafe use later even if the original ingestion point looked harmless.

Adversarial payload regression tests keep the boundary from decaying. Every parser, renderer, prompt assembly path, templating engine, and tool interface should have tests that show untrusted content remains data.

Parameter dimensions

The archetype varies along several dimensions.

The first dimension is the kind of interpreter: database, shell, browser, document renderer, model, policy engine, workflow engine, official procedure, laboratory robot, or human authority process.

The second is the role boundary: data versus command, content versus instruction, evidence versus rule, request versus authorization, parameter versus program, or document versus executable macro.

The third is origin trust: anonymous, authenticated but untrusted, partner-supplied, internally authored, machine-generated, delegated, or officially attested.

The fourth is transformation depth. Content that stays in one context is easier to protect than content that is stored, rendered, summarized, embedded, exported, indexed, retrieved, and reinterpreted.

The fifth is authority at stake. A renderer that can only display text has a different risk profile from an automation agent that can send email, transfer money, delete records, change entitlements, or move lab equipment.

Invariants to preserve

Untrusted content must remain data unless an explicit gate changes its role. Control channels must not be defined by syntax that untrusted data can imitate. A parsed structure must not become an authorized action merely because it parsed. Authority must be evaluated against the originator and action, not just the intermediary’s ambient permission. Provenance and validation state must survive handoffs. Ambiguous content must have a safe non-execution route.

Neighbor distinctions

Principal-Bound Authority Mediation is the closest queue-local neighbor. It asks whether a deputy may spend its authority for a particular originator and intent. Data-Control Boundary Inertization asks whether content is allowed to become control at all. A system often needs both. A cross-site request, tool-invocation prompt, or service-account workflow may need principal-bound mediation after data/control inertization determines what action is being requested.

Boundary Permeability Control decides what may cross a boundary. This archetype focuses on what role the crossing object is allowed to take after it crosses.

Sandboxing contains execution. This archetype tries to prevent unwanted execution and uses sandboxing when interpretation remains necessary.

Least-Privilege Access Design constrains the power of interpreters. This archetype constrains the path by which untrusted content can reach an interpreter or authority-bearing action.

Evidence-Bound Authentication verifies claims about identity or origin. Authenticated content can still be malicious, malformed, or unsafe to execute.

Grammar-Guided Structure Recovery helps parse structure. This archetype adds role, trust, authority, and execution gates around interpretation.

Examples

A database-backed search form uses bound parameters. The user text can change the search value but cannot add joins, predicates, drops, or unions. The query structure is control; the user input is data.

A deployment tool receives branch names from contributors. Instead of interpolating the branch name into a shell script, it passes it as a typed argument to a limited command under a constrained worker role. The branch name remains a value even if it contains characters that would be active in a shell.

A document-processing pipeline receives uploaded spreadsheets. It opens them in a non-macro conversion sandbox, extracts values into a safe intermediate representation, and requires review before formulas or scripts can be executed.

An AI research assistant reads web pages. Retrieved text is labeled as untrusted evidence. It may be summarized, quoted, or cited, but it cannot modify the system instruction, override tool schemas, or approve purchases. Tool calls require a separate policy verdict based on the user’s request and the tool’s capability scope.

A public agency receives forms from applicants. The applicant’s statements may be evidence, but they cannot rewrite eligibility rules, override deadlines, or command officials. Any procedural change requires a separate authority record.

Failure modes

The most common failure is context drift. A string escaped for one context is reused in another and becomes active. The mitigation is to treat inertization as target-context-specific.

Another failure is treating validation as permission. A well-formed request may still be unauthorized. The mitigation is a post-parse policy verdict.

A third failure is ambient authority. Even if content is partly controlled, the interpreter may run under a role so powerful that one missed boundary becomes catastrophic. The mitigation is least privilege and capability-scoped execution.

A fourth failure is the filter arms race. If the design is mostly a list of forbidden substrings, it is probably not implementing this archetype. Replace subtractive filters with typed structures, allowlisted grammars, and safe interpreter interfaces.

Implementation checklist

1. List all interpreters and authority-bearing actions that can see user, partner, retrieved, generated, or imported content.
2. Mark which inputs are untrusted, partially trusted, attested, internal, or privileged.
3. Classify each input’s permitted role before interpretation.
4. Replace concatenation into executable text with structured or parameterized calls wherever possible.
5. Define context-specific inert representations for every rendering, query, command, prompt, policy, and document context.
6. Add a post-parse policy gate before any action that spends authority.
7. Preserve provenance and trust labels across transformations.
8. Provide rejection, quarantine, reduced-capability, or review paths.
9. Run adversarial boundary tests and keep them with the interpreter or policy code.
10. Review the boundary whenever a new interpreter, tool, template, model, export path, or authority-bearing workflow is added.

Review note

This draft intentionally does not provide exploit recipes. Its purpose is to capture the cross-domain solution pattern: untrusted content must not be able to promote itself from data into control or authority. Security-specific implementations should be developed by qualified teams under the relevant threat model and safety constraints.

Common Mechanisms

• Allowlisted Parser or Schema Validator
• Capability-Scoped Tool Invocation
• Content Security Policy or Execution Policy
• Contextual Output Encoding
• Injection Payload Regression Tests
• Least-Privilege Execution Context
• Parameterized Interpreter Call
• Rejection or Quarantine Queue
• Structured Command Construction
• Taint Tracking or Provenance Labeling
• Template or Markup Sandbox

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 (7)

• Access Control: Restrict system access.
• Boundary: Defines system limits.
• Containment: Holding a hazard, process, or agent within a deliberately maintained perimeter to prevent its spread or uncontrolled interaction with the surroundings.
• 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.
• 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.
• Validation: Confirming that an artifact actually solves the intended problem in its real operational context, as distinct from confirming it was merely built to specification.

Also references 17 related abstractions

• Attestation: A verifiable, principal-binding, tamper-evident mark lets a third party confirm who committed to what.
• Authentication: Binding an asserted identity or origin to admissible evidence through a procedure that yields a verdict, before trust, access, or weight is granted.
• Authority: The recognized, legitimate right to issue binding decisions within a defined scope, distinct from raw coercive force or mere persuasive influence.
• Authority Handoff: A role with binding authority and attached state transfers between occupants without breaking either.
• Capability Separation: Issuance is restricted to a privileged party while verification is open, tied by a forgery-prevention mechanism.
• Conditional Access: A controller couples a desired item with an undesired one, leveraging access asymmetry to force acceptance of both.
• Confused Deputy: A privileged intermediary acts on its own authority while the intent originated with an outsider who lacks it, so authority is borrowed without intent being tracked.
• Data Integrity: Accuracy and consistency preserved.
• Delegation of Authority: Assign responsibility.
• Evidence: A defeasible, provenance-bearing relation between an observable trace and a hypothesis about an unobservable state.

▸ Show 7 more

Variants

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

Control/Data Channel Confusion Guarding · risk or failure variant · recognized

Prevent a shared channel from letting data tokens masquerade as protocol, query, shell, markup, or command tokens.

• Distinct from parent: This is the channel-confusion branch of the parent archetype.
• Use when: Control and data share a substrate; Role separation is marked by syntax that untrusted content can imitate.
• Typical domains: database queries, shell commands, network protocols, markup languages
• Common mechanisms: parameterized interpreter call, structured command construction, allowlisted parser or schema validator

Data-Control Plane Breach Prevention · domain variant · recognized

Prevent content arriving through a data plane from altering the control plane that governs interpretation, tools, routing, or policy.

• Distinct from parent: This is the architectural data-plane/control-plane branch of the parent.
• Use when: A control plane consumes or attends to data-plane content; The interpreter may execute directives embedded in retrieved, stored, or user-supplied content.
• Typical domains: agentic ai systems, workflow automation, service meshes, document processing
• Common mechanisms: taint tracking or provenance labeling, capability scoped tool invocation, content security policy or execution policy

Authority-Borrowing Input Execution Guard · governance variant · likely subtype

Guard the case where untrusted input causes a trusted intermediary to spend its own authority on the originator’s behalf.

• Distinct from parent: This branch overlaps strongly with Principal-Bound Authority Mediation.
• Use when: A deputy or intermediary can act with broader authority than the input originator; Input interpretation and delegated authority both matter.
• Typical domains: web security, api gateways, automation agents, organizational workflows
• Common mechanisms: capability scoped tool invocation, least privilege execution context

Near names: Injection Vulnerability, Untrusted Content Executed as Control, Input Sanitization, Command/Data Separation, Prompt Injection Guarding.