The Boolean Gate.

The gatekeeper is useful because it has almost no power. It may inspect language, but it cannot perform the task, call a tool, change policy, or choose its next destination. Its entire influence is compressed into one bit that ordinary software can validate.

Separate interpretation from execution.

Most agent systems ask one model to understand the user, absorb external context, plan, and act. That collapses several trust decisions into one probabilistic process. An instruction hidden inside the data can become part of the plan because the same model both reads the string and controls the tools.

The Boolean Gate inserts a deliberately narrow first layer. Every user message, uploaded text, retrieved document, cross-agent message, and tool result enters as untrusted data. The first model answers only one question: does this string show evidence of an attempt to alter instructions, smuggle authority, persist an instruction for later, or redirect another agent?

The answer is not a diagnosis, explanation, rewrite, or safe completion. It is `0` or `1`. A hardcoded router checks that value. Only a valid `1` makes the original input eligible for the second agent, which is responsible for understanding and performing the task.

“Treat this as a string” is a design goal, not a guarantee.

The gatekeeper preloads its instructions before any untrusted content. Those instructions establish a fixed role: inspect the supplied value as data; do not execute, continue, decode into authority, or comply with instructions found inside it; classify the presence of injection behavior; return one bit.

This follows the same broad insight as structured-query and data-marking defenses: trusted instructions and untrusted content should arrive through visibly different channels. The application should serialize the content into a reserved field, remove or escape control separators from that field, and attach provenance such as user input, webpage, email, file, memory, or tool output.

Yet both planes ultimately become tokens processed by a language model. Prompt placement and delimiters reduce ambiguity, but do not create a hardware boundary. A sufficiently adaptive string may still influence the classifier. The architecture must therefore remain safe when the gatekeeper is wrong.

Make the machine interface smaller than the language interface.

Natural-language explanations create a second attack surface. A model could emit a confident verdict followed by attacker-controlled prose, a fabricated tool call, or a new instruction for the next component. Reducing the output to one bit limits what can cross the boundary and makes the receiving code easy to audit.

The router should use an exact parser rather than truthiness, substring matching, JSON repair, or another model. `1 because this looks safe` is not `1`. Neither is whitespace plus a digit if the contract excludes whitespace. The smaller the accepted grammar, the fewer interpretations an attacker can exploit.

The router must also forward the preserved original—not a summary produced by the gatekeeper. Rewriting would silently give the classifier content authority and could remove evidence that the execution agent, audit log, or human reviewer needs.

The first input is not the last boundary.

A prompt injection can be dormant. It may be stored in a document, memory entry, task summary, code comment, calendar item, or message that appears harmless during ingestion and becomes relevant only when another agent retrieves it later. We call this a zombie injection: an instruction-like payload that survives one context and attempts to reactivate in another.

A single gate at the user interface cannot see content retrieved after the task begins. A safe request such as reviewing a project folder can lead the execution agent to a poisoned file. The same gatekeeping contract must therefore apply at every transition from an untrusted source into a reasoning context.

Persistent content should carry provenance and trust labels with it. A later summary does not become trusted merely because a model wrote it. If untrusted material influences the summary, the derived value remains untrusted.

A gate can fail open, fail closed, or be bypassed.

The gatekeeper is itself an LLM exposed to adversarial language. Research on model-based injection detection shows that high benchmark accuracy can hide structural weaknesses against adaptive attacks. A binary answer makes integration safer; it does not make classification infallible.

1. False negative

   A disguised injection is labeled safe and reaches the execution agent. This is the defining residual risk.

2. False positive

   A legitimate discussion of security, code, role-play, or quoted instructions is blocked because it resembles an attack.

3. Classifier injection

   The inspection model follows language inside the string despite being told to treat it only as data.

4. Parser ambiguity

   Whitespace, prose, tool syntax, or multiple digits create an unintended branch unless the output grammar is exact.

5. Boundary bypass

   A safe initial prompt later retrieves a poisoned webpage, message, file, image, or memory that never passed through the gate.

6. Availability attack

   Very long, recursive, encoded, or adversarial inputs consume gate capacity or force repeated fail-closed decisions.

The label definition also matters. If `1` means “safe,” operators may treat it as permission for any downstream action. It should mean only “the classifier did not detect an injection under this policy and model version.” Absence of detection is not proof of benign intent, factual accuracy, or authorization.

Contain the classifier and the executor.

The first layer should be cheap, stateless, replaceable, and isolated. It should not know secrets or see task-agent credentials. Logs should capture the model and policy version, provenance, input hash, result, latency, and parser outcome without unnecessarily retaining sensitive content.

1. No capability

   The gatekeeper receives no tools, credentials, memory write access, private context, or network path. Its only channel is one bit.

2. Fresh context

   Each classification begins from the same trusted instruction block with no attacker-controlled conversation history.

3. Structured input

   The router supplies provenance and content in distinct fields and escapes reserved separators before inference.

4. Exact output

   A strict parser accepts only 0 or 1. Timeouts, extra text, refusals, exceptions, and unavailable models resolve to the safe branch.

5. Independent execution policy

   A pass is eligibility, not authorization. The task agent still operates under least privilege, action checks, and user confirmation.

6. Repeated gates

   External documents, tool results, retrieved memory, and cross-agent messages are inspected at every trust-boundary crossing.

The execution agent remains inside a separate security envelope. Tools should enforce schemas, identities, destinations, and permissions in code. High-impact actions require confirmation that describes the actual operation. A missed injection should encounter a second boundary it cannot talk its way through.

For higher-risk systems, the Boolean Gate can become one signal in an ensemble: deterministic pattern checks, content provenance, a specialized classifier, rate limits, and policy evaluation can converge on the routing decision. The final branch should still be made by code.

Test the bit, the route, and the eventual action.

Evaluation must include clean requests that discuss attacks, multilingual and encoded inputs, fragmented instructions, long benign documents, adversarial suffixes, indirect injections, and payloads that persist through storage and retrieval. Attackers should receive feedback and adapt, because a static test set rewards memorization.

A useful benchmark reports more than classifier accuracy. It measures the cost of false positives, the rate of malformed outputs, latency under load, route correctness, downstream task completion, and the blast radius of a false negative.

Research behind the architecture.

1. StruQ: Defending Against Prompt Injection with Structured Queries

   Chen et al., 2024. Separates trusted prompts from untrusted data through a secure front end and structured instruction tuning.

2. Defending Against Indirect Prompt Injection Attacks With Spotlighting

   Hines et al., 2024. Uses delimiting, data marking, and encoding to preserve the provenance of untrusted content.

3. The Instruction Hierarchy

   Wallace et al., 2024. Trains models to prioritize privileged instructions over conflicting lower-trust inputs.

4. Defeating Prompt Injections by Design

   Debenedetti et al., 2025. CaMeL separates control and data flow and enforces capabilities around a potentially vulnerable model.

5. How Not to Detect Prompt Injections with an LLM

   Schulhoff et al., 2025. Demonstrates why strong detector results can fail under attacks designed for the detector’s mechanism.