Prompt Injection: The Complete Defense Guide

Prompt injection is OWASP's #1 LLM risk. The bug: LLMs can't tell instructions from data. Everything in the context window looks the same to the model.

This guide covers the full threat surface, defense layers across four phases (input, runtime, output, operational), and a practical policy flow. Scope: runtime prompt injection only. Model poisoning (training-time attacks) is a different threat model. Malicious content in RAG results is covered - that's indirect injection.

Sections

• Threat surface - attack vectors + evasion techniques with example payloads
• Defense layers - 11 layers across 4 phases (input, runtime, output, operational)
• Policy flow - 8-step implementation checklist
• What honest defense looks like
• Where Swiftward fits

Threat surface

Two dimensions: how the attack arrives (vector) and how it hides (evasion). Any vector can use any evasion technique. The "Defended by" column maps to defense layers below.

Attack vectors

Evasion techniques

Defense layers

11 layers, 4 phases. Input tries to catch attacks before the LLM. Runtime limits damage when detection fails. Output catches what got through. Operational keeps defenses current. Layer IDs (L1-L11) are referenced from the threat table above.

Policy flow (implementation checklist)

8 steps covering all 4 phases. Each maps to defense layers above.

What honest defense looks like

Nobody is 100% proof against prompt injection. OWASP says it directly: LLMs have no built-in concept of "trusted prompt" - the application must impose trust boundaries.

The defensible claim: reduce attack surface on input, bound blast radius at runtime, catch what got through on output, trace every decision.

Same model as traditional security. You don't claim your firewall stops 100%. You have layered defenses, you detect and respond, and you can show exactly what happened and why.

Where Swiftward fits

Implementing all 11 layers in application code means building detection pipelines, state tracking, and audit trails from scratch. Then evolving them as new attacks emerge - safely. That's where most teams get stuck.

Swiftward is a policy engine that orchestrates all four defense phases as declarative YAML policy. You define rules, Swiftward handles evaluation, state, and traces. New attack vector? Update a rule, backtest against historical traffic, shadow-test on live, enforce when confident, roll back if wrong. On-prem, single binary.

• Input detection - Unicode normalization, encoding decoding, pattern matching (500+ phrases, 10+ languages), fuzzy matching, pluggable ML classifiers (Prompt Guard, Prompt Shields, custom)
• Output validation - role alignment, canary tokens, PII/toxicity/content scanning, format checks
• Runtime containment - tool allowlists, parameter schemas + bounds, rate/spend limits, HITL gates
• Per-user escalation - bucketed counters, escalating response rules (warn → throttle → block → alert)
• Full decision trace - every signal, score, rule, action logged. Replay any past decision
• Safe deployment - backtest → shadow-test → enforce. Update rules in minutes, not sprints
• On-prem - data never leaves your infrastructure

signals:
  injection_scan:                        # L1-L3: normalize, patterns, ML
    udf: guardrails/prompt_injection
    params:
      text: "{{ event.data.prompt_context }}"
      normalize: true
      motifs: true

  output_scan:                           # L7-L8: role alignment, canary
    udf: guardrails/output_policy
    params:
      response: "{{ event.data.response }}"
      canary_token: "{{ event.data.system_canary }}"

rules:
  block_injection:                       # Input phase
    condition:
      path: "signals.injection_scan.score"
      op: gte
      value: 0.8
    effects:
      verdict: rejected
      state_changes:
        change_counters: { injection_attempts: 1 }
      actions:
        - action: security_alert

  block_output_violation:                # Output phase
    any:
      - path: "signals.output_scan.canary_leaked"
        op: eq
        value: true
      - path: "signals.output_scan.role_aligned"
        op: eq
        value: false
    effects:
      verdict: rejected

  throttle_repeat_attacker:              # L9: behavioral tracking
    condition:
      path: "state.entity.counters.injection_attempts_window_10m"
      op: gte
      value: 3
    effects:
      verdict: rejected

trace_id:       tr_ai_20260218_014
policy_version: agent_guardrails_v3

SIGNALS
+ injection_scan: score=0.82, matches=[instruction_override, system_manipulation]
  ml_score=0.91
+ output_scan: canary_leaked=false, role_aligned=true

RULES
[P100] block_injection          MATCHED  (0.82 >= 0.8)
[P90]  block_output_violation   SKIPPED
[P80]  throttle_repeat_attacker SKIPPED  (attempts_10m: 1 < 3)

VERDICT: REJECTED  |  Source: block_injection
COUNTERS: injection_attempts += 1
ACTIONS:  security_alert (OK)