Variables and Keywords

What it is

Variables and keywords describes a family of prompt injections that make a model behave like a small programming language. The attacker defines a placeholder, trigger word, or conditional rule and then asks the model to resolve it. A protected value may be framed as the value of {X}, or an innocuous keyword may be declared to activate a hidden instruction. The weakness is not the punctuation; it is the assumption that substitution is a neutral formatting operation.

This technique sits between natural-language prompting and programmatic behavior. It can appear in a direct message, a template, or content retrieved from elsewhere. A legitimate form may use placeholders every day, so disabling braces or keywords would be a poor defense. The application has to decide which values are available for the operation and whether the resolved output is allowed before it reaches a user or tool.

How it works

The attacker separates definition from execution. First they describe a variable or a trigger; then they ask the model to fill, print, or activate it. Filters that inspect each line or turn independently may never see the full request. The model’s ability to track state and follow exact formatting can work against it when the variable is assigned a sensitive value from context.

A template can make the request look routine: “complete the blank,” “render this field,” or “return the object with the named key.” The same approach can be nested in a code example or a fictional workflow. If a parser later treats the model’s output as a command, the substitution stage becomes a privilege boundary that has no independent authorization.

Why it works

Models are excellent at pattern completion and simulated state tracking. They have learned that a placeholder should be replaced and that a trigger should cause a defined response. The formal-looking syntax can make an unsafe request appear less like a request for a secret and more like a harmless transformation.

The model may also assume that a value visible somewhere in context is available for substitution. A downstream filter that checks only the literal user message will miss a secret introduced during generation. Conversely, a valid business template could be blocked if a detector treats every variable as hostile. The reliable solution is to carry data classification and authorization alongside the variable, rather than asking the model to infer them.

A safe, fictional example

The fictional Cobalt Catalog uses a local template for an invented product release: Project name: {{catalog_name}}. A reviewer asks the assistant to fill the placeholder with the public test value “Rain Finch.” In a second fixture, the same placeholder points to a protected internal note. The service is configured so the model sees only a redacted marker, and the template renderer refuses to substitute protected values.

The test also defines a harmless keyword, CHECK_FORMAT, that asks the assistant to verify punctuation. It confirms that the keyword cannot unlock a different record or tool. The lesson is that substitution and triggering need explicit scope; a placeholder is not a permission token.

How to spot it

Watch for braces, named fields, blank lines, “fill the gap,” “return only the value,” or instructions that define a keyword and immediately invoke it. Compare the values available in context with the user’s stated purpose. Repeated variants that change the placeholder name or syntax while seeking the same field are a useful signal.

Trace every stage: where a variable was introduced, where it was resolved, and which classifier or authorization check ran before and after resolution. Unexpected tool calls or sensitive output following a formatting request are stronger evidence than the presence of a particular delimiter.

Defensive controls

Use a real template engine with an allowlist of fields, typed values, and server-side authorization. Never let the model invent variable bindings or decide that a protected value is safe to render. Resolve public formatting in deterministic code, classify decoded or substituted content, and re-check before sending it to a tool or user. Keep sensitive values out of the model context when possible.

Test equivalent placeholders, blank styles, trigger words, nested definitions, and multi-turn setup against fictional data. Verify that a user can still fill permitted fields and that denied fields produce a useful safe response. Log variable names and decision metadata without recording sensitive values, and rate-limit repeated probes for alternate syntax.

Limits and nearby techniques

Instruction overriding asks the model to replace guidance directly; variables split the request into definitions and use. Sequences / delimiters make a block look like structured control data. Stored prompt injection can plant a variable rule in persistent context. Encoding may hide a variable name or value, but the transformation is the relevant mechanism there. A placeholder inside a retrieved document is an indirect delivery path. Keep the conceptual boundary clear so a template feature remains usable without becoming an authorization system.