Positive Prompt Injection

Tekachew Ejeta · tekachew.ejeta@denovosecurity.com

A compliance-enforcement primitive for enterprise AI agents. A security gateway inserts authorized organizational policy into every agent's context inline, verifies whether the agent complied, and logs the result as evidence — turning the mechanism of prompt-injection attacks into a governance control that works even on agents the enterprise did not build.

The problem: agents act, but policy does not travel with them

Enterprises are deploying AI agents that read data, call tools, and take consequential actions on the organization's behalf. The agents multiply quickly, are often built by different teams or bought from vendors, and each carries its own prompt and configuration. There is no single place where the organization's rules — data handling, disclosure, prohibited actions, regulatory constraints — are applied to every agent consistently.

The gap is specifically at runtime. An organization can write a policy, but today that policy lives in documents and in the memory of whoever built each agent. Nothing enforces it on the actual model call that discloses data, makes a lending decision, or writes to an external system. When one agent's system prompt is wrong, outdated, or was never given the rule, the policy simply does not apply to that agent.

This matters because liability follows the deployer. Under the emerging US state AI frameworks, the obligations land on the enterprise using the AI to make or inform a consequential decision, not on the model provider. The enterprise is responsible whether or not each of its agents happened to be configured correctly. A control that applies policy uniformly, and produces evidence that it did, is therefore not a convenience — it is the mechanism that turns an undemonstrable claim of care into a defensible one.

The requirement that follows: a single enforcement point, in the request path of every agent, that applies the organization's current policy regardless of who built the agent, and records that it did.

The approach: positive prompt injection

Prompt injection is normally studied as an attack: untrusted content inserted into a model's context to subvert its behavior. Positive prompt injection uses the same mechanism for the opposite purpose. A security gateway, sitting inline in front of the model, inserts authorized organizational policy into the agent's context before the request reaches the model. The same technique that an attacker uses to break the rules is operated by the defender to enforce them.

The inversion is defined by four properties that separate it from an attack:

• Authorized. The injected content is the organization's own policy, written and version-controlled by its security or compliance team — not content arriving from an untrusted document or tool output.
• Signed. Each injection is cryptographically marked as gateway-origin, so it is distinguishable in the context, in the logs, and downstream from both the agent's own prompt and any attacker content. "Trust injected instructions" becomes "trust gateway-signed instructions," which is the distinction that keeps the technique from normalizing the attack it resembles.
• Verified. Injection alone only influences a probabilistic model; it does not guarantee behavior. So the gateway checks whether the agent actually complied, and logs the result. Enforcement comes from the loop around the injection, not from the injection by itself.
• Backstopped. For strict rules that must never be violated, injection is paired with a deterministic control at the gateway — block, redact, or escalate. Injection is the first line; the hard control is what makes a strict rule enforced rather than merely encouraged.

Stated precisely: positive prompt injection is a compliance-enforcement primitive in which the gateway injects authorized policy inline, verifies compliance, logs it as evidence, and backstops strict rules deterministically. It shifts the probability of compliance and produces the evidence of diligence. It does not, by itself, shift responsibility — that remains with the deployer and moves only through contracts.

Positive prompt injection shifts the probability of compliance and produces the evidence of diligence. It does not, by itself, shift responsibility.

What makes this more than a relabeling is the asymmetry it exposes. The prompt-injection literature treats the capability almost entirely as a threat to detect and prevent. Wielding the identical capability deliberately, safely, and measurably as a governance control is the contribution.

Architecture: the inject-verify-log loop

Every agent request passes through the gateway on its way to the model. The gateway reads the request, selects the policies whose trigger conditions match (by task type, data classification, target system, or jurisdiction), and prepends their signed instructions to the context. The model generates its response; the gateway inspects the output to verify compliance, applies a deterministic backstop if the policy requires one, and writes a signed, tamper-evident log entry recording which policy applied and whether the agent complied.

The request path, step by step

• Agent request. Any agent, built by any team or vendor, sends a request through the gateway.
• Inject policy. The gateway pulls the matching rules from the signed policy store and prepends them to the context.
• Model. The model generates its response.
• Verify and backstop. The gateway checks the output for compliance and blocks, redacts, or escalates where a strict rule requires it.
• Response and audit log. The response is released to the user or tool, and every outcome is written to the tamper-evident log.

Two design points carry most of the engineering weight. First, injected policy belongs in the stable prefix of the context. Model inference caches the keys and values for a shared prefix across requests, so a stable, front-loaded policy block stays in the cache and adds almost no latency or cost; policy injected dynamically in a changing mid-context position invalidates that cache and forces a full recompute on every call. Where and how stably policy is injected is therefore a cost decision as well as a correctness one.

Second, the policy store is the highest-value asset in the system and must be the most protected. A gateway that injects instructions into every agent is, mechanically, a prompt-injection engine; whoever controls the policy store controls every agent. The store is signed, version-controlled, and subject to provenance controls on anything that enters it — the same discipline applied to agent memory, turned on the gateway's own policy.

The residual-violation signal

Because the gateway controls the input (it injected a clear instruction) and measures the output (it verified compliance), every violation is now labeled: the model was told, and it still failed. This turns positive injection from a control into a measurement instrument, and the measurement is arguably the more valuable contribution.

The key metric is the residual violation rate: for a given policy and a given model, the fraction of applicable requests that violate the policy after the instruction was injected. It separates two failures that look identical from the outside:

• A policy with a near-zero residual rate is solved by instruction. Injection alone is sufficient; no further engineering is needed.
• A policy with a high residual rate is not solvable by a prompt. The model cannot or will not follow it reliably, and that rule needs a deterministic backstop.

That distinction is impossible to draw without running the experiment, and the gateway runs it continuously on real traffic. The practical consequences:

• It ranks backstop investment. Deterministic backstops are expensive to build, one per rule. The residual rate says which rules actually need one, so engineering goes where the risk concentrates rather than where it was guessed.
• It produces a per-model, per-policy risk map. Different models fail differently. Measured across every call, the gateway builds a matrix of which model violates which policy and how often — a procurement and deployment input backed by the organization's own data rather than a vendor's claim.
• It separates capability gaps from attacks. A policy violated at random is a capability gap, routed to prompt or model work. A policy violated only under particular inputs is likely an attack or an edge case, routed to the threat side. The pattern of violations tells them apart.

Most security tools report that something failed. The residual-violation signal reports what is structurally unsolvable by instruction, and therefore where the real work is — the difference between an alarm and a diagnosis. The empirical deliverable is a finding of the form: across N models and M policy categories, these categories are reliably instructable and these are not.

Threat model and limitations

The honest through-line is that every risk here is a version of the same fact: positive injection builds powerful central control, and powerful central control is a target. The mitigations follow from treating the gateway's own policy mechanism with the same rigor it applies to the agents it governs.

• The injection capability is itself an attack surface. Whoever controls the policy store can push instructions to every agent. The store must be the most protected asset in the system: signed, version-controlled, access-limited, and with provenance controls on anything that enters it. If policy is retrieved dynamically from a corpus, that corpus can be poisoned, which turns the defense into a distribution channel — so the dynamic variant inherits a stricter trust model than the static one.
• Enforcement is probabilistic, not deterministic. Injection influences a model; it does not bind it. Marketing it as a guarantee is both wrong and dangerous. Strict rules must be backstopped by deterministic controls, and the system should be described as shifting the probability of compliance plus producing evidence of diligence — never as a liability transfer.
• It can corrupt its own audit trail. If injected tokens are not cleanly tagged as gateway-origin, logs can no longer separate agent behavior from gateway-shaped behavior, muddying the observability the system depends on. Signing every injection is what prevents this.
• Normalization objection. A reviewer will note that teaching models to obey injected instructions is the confusion attackers exploit. The answer is that the gateway's injections are cryptographically distinguishable, so the model's rule becomes "trust gateway-signed instructions," not "trust any instruction in context." Getting that distinction right is the core design requirement.
• Precedence is untested. Injected policy and the agent's own instructions can conflict, and resolution order is model-dependent. It must be tested, not assumed.
• Latency and cost. Inline inspection and augmentation add tokens and a hop. Keeping policy in the cached prefix is what holds this cost down.

What injection cannot do is as important as what it can. It governs runtime behavior only. Process and governance obligations — periodic risk assessments, breach-notification windows, oversight boards, vendor audits — are not injectable; the gateway supports them by producing evidence, but does not perform them. And some threats sit outside the gateway's vantage point entirely, such as training-time model poisoning or social engineering of the human operator. A credible system marks which threats it enforces, which it merely observes, and which it does not reach.

Application to US AI compliance

US AI compliance is currently a state patchwork rather than a single federal regime, led by the Colorado AI Act, Texas TRAIGA, and California's AI provisions, layered over cross-cutting frameworks such as the NIST AI RMF and existing sector rules (HIPAA, GLBA/SOX, FCRA). Federal preemption of the state rules has been proposed but not settled. The design implication is to build to the recurring obligation categories, which persist across frameworks, rather than to any single statute.

Each obligation splits into a runtime behavior, which positive injection can shape, and a process obligation, which it cannot. The runtime slice maps directly to policy packs — reusable injection, backstop, and log bundles toggled per framework and routed by jurisdiction. The injectable obligations:

Because the frameworks are jurisdictional, injection can be keyed to jurisdiction: a Colorado resident triggers the CO disclosure rules, a Texas high-risk decision triggers the TRAIGA deployer constraints. One gateway applies the right jurisdiction's policy per request, which turns the patchwork from a liability into a feature. The non-injectable obligations — Colorado's annual risk assessments and 90-day notification window, TRAIGA's oversight boards and semi-annual audits — are served by the audit log as evidence, not by injection.

Conclusion and research agenda

Positive prompt injection reframes the most-studied attack against language models as a governance control. Operated by the defender, authorized, signed, verified, and backstopped, the same mechanism that subverts agents can enforce an organization's policy on every agent it governs — including agents the organization did not build, which is the property that makes it defensible. The feature leads with the conservative, static, human-authored policy case; the dynamic, generated variants are a later chapter to grow into once trust is established.

The honest framing is "steer, not guarantee." Injection shifts the probability of compliance and produces the evidence of diligence that the emerging US frameworks reward; it does not transfer liability, which remains with the deployer and moves only through contracts. Sold as provable diligence rather than a liability dodge, it attaches AI agents to a compliance budget that already exists.

The contribution worth pursuing in research is the measurement, not the mechanism. Three questions are open and valuable:

• Attribution of injected content. Making gateway injections cryptographically distinguishable from agent prompts and attacker content, so the model trusts signed instructions rather than any instruction in context — the distinction the whole approach rests on.
• The inject-verify-log loop as a detection primitive. Non-compliance after a known injection is a stronger, cleaner signal than non-compliance alone. Formalizing the residual-violation rate as a benchmark — which policy categories are reliably instructable across models, and which demand deterministic enforcement — is a genuine empirical result.
• Prefix-cache economics and side channels. Keeping policy in the cached prefix makes injection nearly free, but shared prefix caches open timing side-channels across requests. The economics and the leakage are two sides of the same mechanism and belong in the same analysis.

The short version: inject the policy, verify the behavior, log the evidence, backstop what matters, and measure where instruction fails. The measurement is what tells an organization where its agents can actually be trusted — and where they cannot.