Skip to content

Mollywc/LZ2026

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

6 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

LZ2026 — Building AI Agents for ICS/OT Security

A Level Zero 2026 workshop. From zero to orchestrator in one build day.

Instructor: Clint Bodungen — Director, AI/ML Engineering · Arcova / ThreatGEN

This repo is the working environment and reference implementation that accompanies the Building AI Agents for ICS/OT Security workshop. It contains the workshop slides and workbook, a realistic Moxa MGate Modbus gateway configuration with intentional security issues, a CLAUDE.md orchestrator, and a production-pattern four-stage assessment pipeline (Sentinel → output-verifier → red-team → blue-team) that extends the workshop's capstone into a full adversary-informed, verified-control workflow.


What You'll Build

By the end of the workshop you'll have, on your laptop:

  • An agent with ICS/OT expertise baked in — a persona that thinks like an OT security analyst, not a generic IT code assistant.
  • Custom skills and slash commands — reusable playbooks (/compliance-check, /threat-brief, /cve-lookup) that apply consistent methodology on demand.
  • Multi-agent orchestration — parallel specialist subagents (ot-analyzer, cve-researcher, compliance-mapper) whose summaries merge into one unified assessment.
  • A three-tier memory architecture — working memory, curated knowledge (CLAUDE.md / MEMORY.md), and optional associative recall (vector search) — so your agent stops forgetting everything between sessions.
  • GitHub as the agent's task manager — repo + Project v2 board wired in, with a reusable gh-lz2026 skill so the agent reads issues, works them, and logs findings as comments.
  • Cloud and local model experience — run the same agent on Anthropic's API or fully air-gapped on Ollama with Gemma 4.
  • A Monday-morning framework you can deploy on real assessments the week after the workshop.

The Problem This Workshop Solves

The invisible crisis in ICS/OT security isn't vulnerabilities or APTs — it's institutional memory loss. Analysts rotate every 2–3 years. Contractors walk out the door with their expertise. Tribal knowledge evaporates the moment someone leaves. Every new hire resets to zero.

Your best analyst leaving is your biggest unpatched vulnerability.

Persistent, file-based agent memory fixes that. The architecture is open source, runs on commodity hardware, and changes how an OT team retains what it knows.


Who This Is For

  • ICS/OT security analysts and engineers who want hands-on agent-building experience.
  • Compliance leads (NERC CIP, IEC 62443, IEC 61511) who need reproducible, audit-ready assessment pipelines.
  • Architects evaluating air-gapped AI options for SCADA environments.
  • Anyone who has used a chatbot and wants to cross the line into agents that actually act — reading files, running tools, writing reports, accumulating knowledge.

Prior ICS experience helps but isn't required. Prior Claude Code experience is not required.


Prerequisites

Item Notes
Laptop with a terminal macOS, Linux, or Windows (WSL)
GitHub account Free tier is fine
Anthropic API key Get one at console.anthropic.com
Claude Code Installed during Lab 1
Ollama Installed during Lab 9 for local-model work

Workshop Structure

Five parts, one build day, 10+ labs plus a capstone.

Part 1 · Foundations (~2 hrs)

  • Lab 1 — Installing Claude Code, authentication, first conversation.
  • Lab 2 — Analyzing a realistic Moxa MGate Modbus gateway config; finding real ICS security issues.
  • Lab 3 — Writing effective system prompts; turning a generic model into a specialist via CLAUDE.md.
  • Lab 3B — Self-evolving identity: the agent rewrites its own CLAUDE.md to remember what it just learned.

Part 2 · Building Your Agent (~2.5 hrs)

  • Lab 4 — Creating custom subagents (.claude/agents/*.md) and skills (.claude/skills/*/SKILL.md). Workers vs. playbooks.
  • Lab 4B — Prompting Claude to scaffold its own agents, skills, and commands from a plain-English description.
  • Lab 5 — Custom slash commands with $ARGUMENTS and positional args.
  • Lab 6 — Subagent orchestration: parallel specialists merging into one unified report.
  • Lab 6C — GitHub Issues + Project Boards as your agent's task manager.

Part 3 · Memory and Persistence (~1.5 hrs)

  • Lab 7 — The memory problem; the three-tier architecture (working / curated / associative).
  • Lab 7BCLAUDE.md as orchestrator — air-traffic control for subagents, skills, and commands.
  • Lab 7C — File-based memory without a database: MEMORY.md + docs/ + memory/YYYY-MM-DD.md.
  • Lab 7D — Karpathy's Agentic Wiki pattern — compiling raw data into a queryable, agent-maintained knowledge base.
  • Lab 7E — Vector search options (rag-cli, knowledge-rag) without standing up MindStone.

Part 4 · Alternative Tools and Local Models (~1 hr)

  • Lab 8 — OpenCode: the open-source multi-provider alternative to Claude Code.
  • Lab 9 — Local models with Ollama + Gemma 4 for air-gapped environments.
  • Lab 9B — The agent ecosystem: Claude Code · OpenCode · LangChain · Pi AI · MindStone.

Part 5 · Capstone (~1 hr)

  • Lab 10 — Build your own agent. Pick one: Threat Analyst · Compliance Auditor · Incident Response Coordinator. 45 minutes.

What's in This Repo

LZ2026/
├── README.md                    ← this file
├── CLAUDE.md                    ← orchestrator / workflow spec
├── modbus-gateway.conf          ← sample Moxa MGate MB3660-8 config
│                                    (intentional security issues baked in)
├── docs/
│   ├── workshop/                ← slides + workbook (PDF)
│   ├── designs/                 ← system-design docs (Karpathy Wiki memory,
│   │                                vector memory)
│   ├── prds/                    ← product requirement docs for the above
│   └── plans/                   ← implementation plans (vector memory)
├── .claude/
│   ├── agents/                  ← Sentinel · output-verifier · red-team · blue-team
│   ├── agent-memory/            ← per-agent persistent memory
│   └── skills/gh-lz2026/        ← reusable GitHub repo + Project v2 skill
│                                    (pinned project/field/option IDs for
│                                     the LZ2026 board)
├── reports/                     ← job directories + final packages
├── prompts/                     ← session prompt archives (reference)
└── .gitignore

The sample modbus-gateway.conf is modeled on a real Moxa MGate MB3660-8 deployment (Substation 3, Turbine + SIS) with intentional ICS security issues — SIS on a shared gateway (IEC 61511 violation), network-writable safety coils and setpoints, default credentials, cleartext management, outdated firmware, default SNMP community strings, and more. It's the target artifact for Labs 2, 3, 4, and 6, and the reference asset the extended pipeline exercises end-to-end.

The prompts/ folder — the session-by-session build journal

The prompts/ directory is the clearest narrative of how this repo got built. Each file is a dated archive of the verbatim user prompts from one working session, annotated with the context/reason for each prompt and what it produced. Read in order, they trace the whole arc from "first ad-hoc assessment" to "fully wired, verified, four-agent pipeline":

File Session theme
2026-04-19_session-prompts.md Initial wiring — connecting the repo to GitHub and building the reusable gh-ops skill.
2026-04-19_modbus-gateway-assessment-prompts.md First ad-hoc ICS/OT review of modbus-gateway.conf (inline, pre-pipeline).
2026-04-19_sentinel-output-fix-session-prompts.md Debugging the Sentinel agent when it was returning metadata instead of the report body, and hardening the agent definition to persist output to disk.
2026-04-19_verifier-persistence-session-prompts.md Adding output-verifier as a mandatory checkpoint and making its reports a durable on-disk artifact.
2026-04-19_pipeline-buildout-session-prompts.md Comparing two Sentinel outputs against a ground-truth checklist, absorbing the sharper attack-chain style into Sentinel's spec, and building the red-team and blue-team agents + the full workflow in CLAUDE.md.
2026-04-19_modbus-gateway_session_prompts.md The first end-to-end run of the completed four-stage pipeline against modbus-gateway.conf, producing a full job directory under reports/.

These are effectively a replay tape of the workshop's patterns applied to a real build: system-prompt iteration, self-evolving identity files, subagent orchestration, verification discipline, and file-based memory. If you want to see what this way of working actually feels like turn-by-turn — including the interrupts, course corrections, and "no, do it this way instead" moments — the prompt archives are the best source in the repo.

How the workshop patterns show up in this repo

Workshop pattern (lab) Where it lives here
Custom subagents (Lab 4) .claude/agents/Sentinel, output-verifier, red-team, blue-team
Self-evolving identity (Lab 3B) CLAUDE.md — rewritten in-session multiple times as the pipeline grew; the prompt archives capture each rewrite
Subagent orchestration (Lab 6) The four-stage pipeline below, driven by CLAUDE.md
GitHub as task manager (Lab 6C) .claude/skills/gh-lz2026/ + Project #6 — two live epics (Karpathy Wiki memory · vector memory) with 36+ full child issues labelled and prioritized
CLAUDE.md as orchestrator (Lab 7B) The current CLAUDE.md is literally this — authority, canonical files, subagents, workflow, safety constraints
File-based memory (Lab 7C) .claude/agent-memory/<agent-name>/ per agent; MEMORY.md indexes with per-fact files
Karpathy Agentic Wiki (Lab 7D) docs/designs/wiki-memory-system-design.md + docs/prds/wiki-memory-prd.md — formal design to migrate memory to the three-layer wiki model
Vector search (Lab 7E) docs/designs/vector-memory-system-design.md + docs/prds/vector-memory-prd.md + docs/plans/vector-memory-implementation-plan.md — Voyage voyage-3-lite + sqlite-vec + auto-recall over all four Claude Code hooks

Extended Example — The Four-Stage Verified Assessment Pipeline

This repo goes beyond the workshop's capstone to demonstrate a production-pattern pipeline for ICS/OT security assessments. It wasn't designed up-front — it was built iteratively, each agent added to close a specific gap discovered while running the prior version. The session prompt archives (prompts/) are the best record of that build; in rough order:

  1. Sentinel first, as a single ICS/OT analyst agent (Lab 4 pattern).
  2. output-verifier added after Sentinel started returning metadata instead of the report body — verifier enforces both accuracy and persistence to disk.
  3. Sentinel's "Attack chain" section made a required output after comparing two Sentinel reports against a ground-truth checklist; the sharper of the two had a single linear intrusion narrative with concrete FCs + registers + wall-clock estimate, and that style was promoted into the spec.
  4. red-team added to layer MITRE ATT&CK TTP-chain mapping onto verified findings (Enterprise + ICS, looked up live from attack.mitre.org).
  5. blue-team added to evaluate and expand Sentinel's mitigation recommendations against authoritative sources (NERC CIP, IEC 62443/61511, NIST CSF/SP 800-82, CISA, MITRE D3FEND, vendor hardening guides).
  6. A verification checkpoint after every producing stage — the full workflow, per-job directories, manifest pin, and source allow-list discipline wired into CLAUDE.md.

The resulting pipeline:

Sentinel (assessment)
    ↓ checkpoint — output-verifier
Red-team  (MITRE ATT&CK TTP-chain annex — Enterprise + ICS, live from attack.mitre.org)
    ↓ checkpoint — output-verifier
Blue-team (mitigation annex — prevent/detect/compensate, validated against NERC CIP,
           IEC 62443/61511, NIST CSF/SP 800-82, CISA, MITRE D3FEND, vendor hardening guides)
    ↓ checkpoint — output-verifier
Final package (orchestrator-assembled executive summary + full artifact index)

Key properties:

  • Every producing stage is followed by an independent verification checkpoint. PASS advances, FAIL blocks.
  • Every assessment runs in a single per-job directory (reports/<YYYY-MM-DD>_<target>/) with a fixed file-name convention (01_sentinel_assessment.md through 07_final_package.md) and an orchestrator-maintained 00_manifest.md pinning target-file hash, asset context, scope, and source allow-list.
  • Every agent has an explicit authoritative source allow-list. No memory-recalled technique IDs, clause numbers, or CVEs — everything is validated live against attack.mitre.org, d3fend.mitre.org, NERC/IEC/NIST publications, CISA advisories, and vendor documentation.
  • Safety-affecting controls require MoC (Management of Change) language; safety-function disablement as a "mitigation" is categorically refused.

See CLAUDE.md for the full workflow specification and reports/ for a worked example against modbus-gateway.conf.

In-Flight Work — Memory System Upgrades

Two memory-system initiatives are designed and tracked on GitHub Project #6, with full design + PRD docs in docs/:

  • Karpathy Agentic Wiki memory (epic — 16 child issues). Migrates the current flat MEMORY.md-plus-per-fact-files model to a three-layer architecture (raw sources · LLM-maintained wiki · schema/instructions), with an extended frontmatter type enum for ICS/OT entities (vendor / protocol / technique / asset) and per-agent compilation responsibilities. See docs/designs/wiki-memory-system-design.md + docs/prds/wiki-memory-prd.md.
  • Vector memory + auto-recall (epic — 20 child issues). A parallel high-recall layer that captures all new docs and the full conversation stream (user · assistant · assistant-thinking), auto-vectorizes on a schedule and pre-compaction, and transparently injects the top-K semantic matches into every user prompt before inference. Stack pinned to Voyage voyage-3-lite (1024-dim) + sqlite-vec + Python 3.11 + Typer CLI + hooks on UserPromptSubmit / PreCompact / PostToolUse:Write|Edit / Stop. See docs/designs/vector-memory-system-design.md + docs/prds/vector-memory-prd.md + docs/plans/vector-memory-implementation-plan.md.

Both are worked examples of the workshop's Lab 7D and Lab 7E material taken beyond demonstration into a real, tracked, engineering build.


Quickstart

# 1. Install Claude Code
curl -fsSL https://claude.ai/install.sh | bash    # macOS/Linux
# or (Windows PowerShell):
# irm https://claude.ai/install.ps1 | iex

# 2. Clone this repo
git clone https://github.com/R1ngZer0/LZ2026.git
cd LZ2026

# 3. Launch Claude Code from the repo root
claude

# 4. Try the sample assessment
> Read modbus-gateway.conf and give me a security assessment.
>   Focus on ICS/OT security risks. Be specific about what's wrong
>   and what an attacker could do with each finding.

For the full workshop walkthrough, open docs/workshop/Workshop-Workbook.pdf and follow along from Lab 1.


Safety and Scope

  • Everything in this repo is for education and defensive security work only.
  • The sample configuration is synthetic. Do not copy register maps or network addresses into production.
  • The pipeline deliberately refuses to emit operational attack tooling, exploit code, or safety-function-disablement as a "mitigation."
  • When applying any recommendation to a real asset, follow your organization's MoC and change-control procedures. Safety-critical changes require process-engineer sign-off.

Resources

Agent harnesses

Local models

ICS/OT security references

Memory architecture reference


Attribution

Workshop designed and delivered by Clint Bodungen with Mira (MindStone AI) for Level Zero 2026.

"The future of ICS/OT security isn't smarter AI. It's AI that remembers."

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

No releases published

Packages

 
 
 

Contributors