Most prompt-injection material is written for the pre-launch stage: sanitize input, add a safety layer, run a red-team exercise. That advice is correct but incomplete. The problems that show up months into production are usually not dramatic jailbreaks. They are template interpolation bugs, retry storms, cache stampedes, and slow prompt bloat — operational failures that surface as a cloud bill before they surface as a security alert.

This article covers the production mechanics: how injection actually reaches the model, what it costs, how to measure it, and how to harden a service without rewriting your prompt pipeline.

Why injection is a cost problem, not just a security problem

Prompt injection is usually framed as an attacker overriding system instructions. In production, the more common and more expensive version is simpler: user-controlled text is interpolated into a prompt template without escaping, and the model treats part of that text as instructions.

Three cost mechanisms follow from that:

1. Retry amplification. A malformed or contradictory prompt can cause the model to produce output that fails downstream validation, triggering retries. Each retry re-sends the full prompt. If the prompt has grown large, each retry is expensive.
2. Cache invalidation and stampedes. If the cache key is derived only from the user message and not the rendered prompt, a single injected instruction can produce many distinct cache misses for what is logically the same request.
3. Prompt bloat. Prompts accumulate feature flags, context, and metadata over time. Every added token is paid on every request and every retry.

None of these are visible in a flame graph that only tracks API calls. They show up in token accounting and in downstream error rates, which is why instrumentation has to be designed deliberately.

How template interpolation becomes an injection vector

The attack surface is the gap between "user data" and "instructions." Most LLM frameworks represent a prompt as a string. There is no structural separation between the two, so any templating engine that treats certain characters as syntax can be abused.

A minimal example. Suppose a service renders a prompt from a template like this:

SYSTEM_PROMPT = """
You are a financial assistant. Answer concisely.
User session: {{session_id}}
User message: {{user_message}}
"""

If user_message is interpolated with a naive str.format() or an unescaped template engine, a user message containing {{...}} can be interpreted as template syntax rather than text. The rendered prompt then contains whatever the engine substituted, and the model — which has no way to distinguish "instructions" from "data" — may follow it.

Two failure modes are worth separating:

• Template syntax injection. The templating engine itself evaluates user input. This is a code-execution-adjacent bug in your rendering layer, independent of the LLM.
• Instruction confusion. The template renders correctly, but the model cannot tell the difference between your system instructions and quoted user text, so it follows the user text. This is a model-behavior issue and cannot be fully fixed by escaping.

The first is a bug you can fix. The second is a property of the model you have to design around.

A worked example: tracing one injected request

This is an illustrative walkthrough, not a measurement from a specific deployment. The numbers are chosen to make the arithmetic visible.

Assume a service with the following stated parameters:

• System prompt: 300 tokens.
• Per-request context (session metadata, feature flags): 200 tokens.
• User message: 50 tokens.
• Output: 150 tokens on a normal response.
• Retry budget: up to 3 attempts.
• Model pricing assumption: $0.50 per 1M input tokens, $1.50 per 1M output tokens (illustrative only — substitute your provider's published rates).

Normal request cost:

input  = 300 + 200 + 50 = 550 tokens
output = 150 tokens
cost   = (550 * 0.50 + 150 * 1.50) / 1_000_000
       = (275 + 225) / 1_000_000
       = $0.0005

Now suppose an injected instruction causes the model to emit a verbose, malformed response that fails downstream JSON validation, triggering all 3 retries. Each retry re-sends the same 550-token input, and each attempt produces 1,200 output tokens because the injected instruction asked for verbosity:

input  = 550 * 3 = 1,650 tokens
output = 1,200 * 3 = 3,600 tokens
cost   = (1,650 * 0.50 + 3,600 * 1.50) / 1_000_000
       = (825 + 5,400) / 1_000_000
       = $0.006225

That is roughly 12x the normal cost for a single request. At 100,000 requests per day, if even 0.5% of requests hit this path, the daily delta is:

100,000 * 0.005 = 500 affected requests
500 * ($0.006225 - $0.0005) = 500 * $0.005725 = $2.86/day

Small, but the point is the multiplier, not the absolute number. Substitute your own traffic and pricing. The mechanism is what matters: retries multiply input cost linearly and output cost linearly, and both are paid again on every attempt.

How to actually measure this

Do not trust a benchmark table from an article. Instrument your own service. The signals that matter:

• Tokens per request, split by input and output. Most providers return usage in the response object. Log it. Aggregate per route and per prompt version.
• Retry count per request. Count retries as a first-class metric, not just a log line.
• Rendered prompt hash. Hash the fully rendered prompt (after interpolation) and log it alongside the request. This lets you correlate cost spikes with specific prompt versions.
• Cache hit rate per prompt hash. If the same logical request produces different rendered prompts, your cache key is wrong.
• Downstream validation failure rate. If your service parses model output, track parse failures. These are the retry trigger.

A minimal instrumentation pattern:

import { createHash } from 'crypto';

function hashPrompt(renderedPrompt) {
  return createHash('sha256').update(renderedPrompt).digest('hex');
}

// after rendering, before calling the model
const promptHash = hashPrompt(renderedPrompt);
metrics.increment('llm.request', { prompt_hash: promptHash });

Compare the distribution of prompt_hash values for a fixed input across a day. If a single input produces many hashes, something is interpolating non-deterministic or user-controlled content into the prompt.

Step 1: Stop interpolating untrusted text into templates

The first fix is structural. Do not pass user text through a templating engine that evaluates syntax. Use a rendering approach where user content is inserted as data, not as template source.

A safe pattern is to build the prompt from typed parts rather than string formatting:

function buildPrompt({ systemText, sessionId, userMessage }) {
  return [
    { role: 'system', content: systemText },
    { role: 'user', content: `session_id=${sessionId}\nmessage=${userMessage}` }
  ];
}

Here userMessage is a value in an object. No template engine parses it. If your provider supports structured message arrays (most do), use them — they are the closest thing to a structural boundary between instructions and data.

If you must use a template engine, choose one that separates logic from data and does not evaluate user-supplied strings as template source. Avoid str.format() and f-strings for user-controlled content. If you use Jinja2, ensure user input is passed as a variable, not concatenated into the template string.

Step 2: Validate prompt variables with a schema

Schema validation catches type confusion and unexpected shapes before they reach the renderer. In Python, Pydantic is a common choice; in TypeScript, a schema validator such as a runtime type library works. The point is not the library — it is that every variable entering the prompt has a declared type, length bound, and allowed character set.

from pydantic import BaseModel, Field, constr

class PromptVars(BaseModel):
    user_message: constr(max_length=500)
    session_id: constr(min_length=8, max_length=64, pattern=r'^[A-Za-z0-9_-]+$')

Note that constraining user_message to alphanumerics will break legitimate use cases (users paste code, JSON, and non-Latin scripts). A better approach is to allow the full character set but treat the content as data — never as template source — and add a separate detection layer for suspicious patterns.

Step 3: Version prompts and detect drift

Prompts change. Feature flags, A/B tests, and gradual rollouts all mutate the rendered prompt. Without versioning, you cannot attribute a cost or behavior change to a prompt edit.

The mechanism: compute a hash of the rendered prompt at build time for each known-good configuration, store the expected hash, and compare at runtime or in CI. A mismatch is not necessarily an error — it may be a deliberate change — but it should be visible.

name: Prompt Hash Check
on:
  pull_request:
    paths:
      - 'prompts/**'
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: node scripts/hash-prompt.js
        env:
          GOLDEN_HASH: ${{ secrets.PROMPT_GOLDEN_HASH }}

The script should fail the build if the rendered prompt hash differs from the golden hash without an accompanying change to the golden hash file. This makes prompt changes reviewable, which is the actual goal.

Step 4: Budget retries by tokens, not attempts

Retry budgets expressed as "3 attempts" do not bound cost, because each attempt can vary in size. Budget by tokens instead.

class TokenBudget {
  private remaining: number;
  constructor(maxTokens: number) {
    this.remaining = maxTokens;
  }
  tryConsume(tokens: number): boolean {
    if (tokens > this.remaining) return false;
    this.remaining -= tokens;
    return true;
  }
}

const budget = new TokenBudget(2000);
let attempts = 0;
let response;
while (attempts < 3) {
  response = await model.generate(prompt);
  const used = response.usage.total_tokens;
  if (!budget.tryConsume(used)) break;
  if (isValid(response)) break;
  attempts++;
}

This bounds worst-case spend per request regardless of how verbose the model becomes. Set the budget based on your p99 normal usage, not your average.

Step 5: Fix the cache key

If the cache key is derived only from the user message, two requests with the same user message but different rendered prompts will collide — or, worse, a single injected instruction will produce many distinct cache entries for the same logical request.

The cache key should incorporate the rendered prompt hash, not the raw input:

const cacheKey = `llm:${hashPrompt(renderedPrompt)}`;

If you need per-user isolation (for privacy or rate limiting), salt with a user identifier, but keep the prompt hash as the primary component. This prevents cross-user cache pollution and makes stampedes visible as a spike in distinct keys.

Failure modes to design for

Silent behavior drift. An injected instruction may not crash anything. It may change output length or format subtly. If your metrics only track latency and success rate, you will not see it. Track output token count per prompt hash and alert on distribution shifts.

Cache stampede from identical errors. If many requests fail the same way, they may all miss the cache and hit the model simultaneously. Add jitter to TTLs and consider a short-lived negative cache for known-bad prompt hashes.

Prompt leak via transparency instructions. If your system prompt says "answer transparently" or "explain your reasoning," a user can ask the model to reveal its instructions. Remove instructions that invite disclosure, and treat the system prompt as a secret you do not rely on for security.

Feature flag bloat. Every flag added to the prompt is a new interpolation point and a new token cost. Move dynamic configuration out of the prompt and into a structured context object if your provider supports it, or into a separately rendered block that is clearly delimited.

Unicode homoglyphs. Character-class filters that block { and } can be bypassed with visually similar characters. If you filter, normalize Unicode first (NFKC), then apply the filter. Note that normalization alone does not solve instruction confusion — it only closes the syntax-injection path.

When this hardening is not worth it

• Static prompts with no user-controlled interpolation. If nothing in the prompt comes from user input, template injection is not applicable. Instruction confusion still is, but the operational cost is lower.
• Very low traffic. If you serve a few thousand requests per day, the absolute cost of retry storms is small. Measure first.
• Managed gateways with server-side prompt handling. Some managed LLM gateways handle prompt assembly and injection mitigation server-side. If you are not assembling the prompt yourself, some of these controls are not yours to implement — but you should still validate what the gateway guarantees.
• Teams without security capacity. Sandboxing and schema validation add maintenance surface. If you cannot maintain it, start with instrumentation and a token budget, which are lower-cost and still catch the expensive failure modes.

FAQ

Does escaping braces prevent prompt injection? No. Escaping prevents template syntax injection, which is one class of bug. It does not prevent instruction confusion, where the model follows user text because it cannot distinguish it from system instructions. Escaping is necessary but not sufficient.

Do managed LLM APIs protect against this? Provider-side safety layers reduce some classes of attack, but they operate on the final prompt. If your own rendering layer interpolates user input as template source, that bug happens before the provider sees anything. Provider-side protections do not fix client-side rendering bugs.

How do I test for template injection in my own service? Send a request whose user field contains a string that looks like your template syntax, such as {{variable}} or {key: value}. Then inspect the rendered prompt — not the model output. If the rendered prompt contains substituted content rather than the literal characters, your renderer is evaluating user input.

What is the single highest-value change? Instrumenting rendered-prompt hashes and token usage per prompt version. Without that, you cannot tell whether a cost change is caused by traffic, prompt bloat, or a specific injection path. Everything else is guesswork until you can measure.

Do this in the next 30 minutes

Open your prompt rendering code and find the function that produces the final prompt string. Add one line: hash the rendered prompt and log the hash alongside the request's token usage. Deploy it to staging, send a request containing {{x}} in a user-controlled field, and check whether the hash changes compared to the same request without those characters. If it does, your renderer is treating user input as template source, and that is the first thing to fix.

Related reading

• Prompt injection: what breaks first in prod
• Defending APIs Against Amplification, Stuffing and Smuggling
• AI errors hide in plain latency