Attack History

Threat Intelligence — Zscaler ThreatLabz

Zscaler ThreatLabz maps four distinct vectors in the agentic AI threat landscape. K9X Shield was designed to address each one architecturally — not with signatures, but with an extensible chain where each vector maps to one handler.

Unlike a human reviewer, an LLM has no inherent notion of trusted versus attacker-controlled content. It follows instructions regardless of their origin — unless architectural safeguards intervene. The payload walked through the front door as a document. That is what Satan tests.

Complete Check Inventory — Component × Threat Class

Every handler currently wired into the target pipeline's two VulnerabilityChain gates, which component owns it, and which named attack in this harness proves it holds. 13 checks total — 7 framework OOB, 6 Satan-local — plus Guardian as a cross-cutting semantic layer that wraps every agent regardless of chain position.

Out of scope by design — not runtime-checkable at the payload level: training-data/model poisoning (OWASP LLM04's non-session-state half), vector/embedding attacks (OWASP LLM08 — no RAG in this target), and misinformation/hallucination (OWASP LLM09 — a quality concern, not a security boundary).

Open-Closed Security — One New Threat, One New Handler

The Chain of Vulnerability Tests applies the GoF Chain of Responsibility pattern to security. Each handler inspects the payload for one class of threat. A new Zscaler ThreatLabz finding means one new handler. Nothing else changes.

ORCHESTRATOR appears twice below — it's the same object both times. It dispatches to Squad first, then evaluates the returned response later. The second box is not a separate "egress gate" component — it's the same Orchestrator, invoked a second time on the way out.

ORCHESTRATOR and AGENT each appear once in IN and once in OUT — same objects both times. ORCHESTRATOR dispatches to Squad on the way in, then evaluates the returned result on the way out. AGENT screens input before calling the LLM, then screens its own output before returning it.

Shared Responsibility — What the Framework Handles, What the SBB Owns

The diagram above is Satan's own target pipeline. A real solution built on K9-AIF (k9x.ai) — say, an insurance claims processor — looks the same from the outside:

Incoming claim document → Router → Orchestrator → Squad → LLM

The claims team writes ClaimsRouter(BaseRouter), ClaimsOrchestrator(BaseOrchestrator), a triage squad, and agents that call llm_invoke() — ordinary business logic. They never write a line of security code. This is a shared responsibility model: the framework and the solution team each own a different half of what makes the system secure.

Nothing in the left column is something the claims team opted into — it's inherited the moment their classes extend BaseRouter/BaseOrchestrator/BaseAgent, the same way logging or the event bus is. Satan attacks the exact same pattern a real solution would use — that's what makes a contained attack here evidence for a real solution, not just proof about a demo.

The Hardening Loop

Satan and Shield grow together. Every EVASION finding closes a gap in the framework — making it stronger for every solution built on K9-AIF.

Satan fires attack
  → Shield misses it        EVASION — gap found
  → new Check added to framework ABB
  → Satan fires again
  → Shield blocks it        BLOCKED — framework hardened
  → next attack class probes the next gap
  → repeat

The chain is open-ended by design. Zscaler's four vectors are not a ceiling — they are the current known surface. As agentic systems become more capable and more autonomous, the attack surface expands. Each new vector is one new handler. The chain does not need to be rewritten. It just needs one more link.

ABB / SBB — Framework Owns the Contracts

ABBs live in the framework. SBBs live in Satan. Every attack SBB extends BaseAttack. Every defence check extends BaseVulnerabilityCheck. The contracts belong to the framework — not to any one solution.

Check Execution — Sequence & Ownership

Every payload traverses four phases in strict order. A block at any phase terminates execution — downstream phases never run.

ABB / SBB Class Hierarchy

PlantUML source at diagrams/shield_class_small.puml (checks grouped into two boxes to keep this readable — the un-grouped version with each check as its own class is diagrams/shield_class.puml). Run ./diagrams/generate.sh to render PNG.

PNG not generated yet — run ./diagrams/generate.sh then reload

Target Pipeline — SBB Hierarchy

── PRE-AGENT ────────────────────────────────────────
DoclingExtractor              SBB utility
  naive regex | Docling OCR (optional)
  → populates extracted_fields

DocumentRouter                extends BaseRouter         (K9-AIF ABB)
  [PRE-AGENT Shield — VulnerabilityChain]
    InputSizeCheck            extends BaseVulnerabilityCheck
    PromptInjectionCheck      extends BaseVulnerabilityCheck
    FieldAnomalyCheck         extends BaseVulnerabilityCheck
      → BLOCKED here if any check fires

── INTELLIGENCE ─────────────────────────────────────
DocumentOrchestrator          extends BaseOrchestrator    (K9-AIF ABB)
  DocumentProcessingSquad     extends BaseSquad           (K9-AIF ABB)
    DocumentExtractionAgent   extends BaseAgent           (K9-AIF ABB)
    AuditAgent                extends BaseAgent           (K9-AIF ABB)

── POST-AGENT ───────────────────────────────────────
  [POST-AGENT Gate — Orchestrator Egress]
    Guardian Governance       semantic LLM evaluation
    SemanticDriftCheck        extends BaseVulnerabilityCheck
    ExecutionGuardCheck       extends BaseVulnerabilityCheck
      → BLOCKED here if response violates policy

── OUTPUT ───────────────────────────────────────────
  ⚠ FINDING — both gates passed — response exited pipeline