AI security engineering / 2026
garak scan planner
A Python prototype for NVIDIA garak that explains a supported scan workload before querying an AI target.
- My role
- Project direction and AI-assisted prototype development
- Stage
- Local prototype · Proposal published
- Built with
- Python · garak · pytest · JSON · Local tokenizers
01 / Context
The problem
LLM security scans prepare many inputs and request multiple generations. Operators need to understand that workload before execution. Counting raw prompts misses conversation turns and transformations; preparation code can also call external services independently of the target.
02 / Ownership
My contribution
I directed and developed, with AI assistance, a bounded CLI scan-planning prototype, tracking generator and separate JSON artifact. It supports 30 audited static probes and three local prompt transformations, reporting prepared inputs, unique conversations, requested generations and input size. Optional token counting uses a supplied local tokenizer file.
03 / Reasoning
The decisions behind it
Bound the supported preparation
An audited allowlist and rejection paths distinguish supported static preparation from adaptive or external workloads. Replacing the target alone does not establish an offline boundary.
Keep planning separate from findings
The prototype avoids configured-target and detector execution. Planning artifacts contain workload statistics, without vulnerability findings, raw prompt text or exported prompt digests.
Make counts explainable
Count complete prepared conversations and generation multipliers, respect caps and supported transformations, and use an explicit local tokenizer for optional token counts. These counts are not billed usage or measured cost savings.
05 / Evidence
Verification & boundaries
The recorded relevant suite passed 1,730 cases, including 61 feature tests; three existing generator contract cases passed separately. Four real CLI scenarios exercised static counts, caps and transformations, local token counting and partial coverage. The configured synthetic loopback target received zero requests, and planning created no security report. Formatting, diff and dependency consistency checks passed.
What this does and does not establish
This remains a local prototype with a public scope proposal, not a submitted or accepted upstream feature. Full repository tests remain unverified because of collection-time data downloads and missing optional audio dependencies. Adaptive and external preparation are explicitly unsupported. The four CLI scenarios establish the tested paths, not universal absence of side effects. No merge, release, adoption or cost saving is claimed. AI assistance was used during implementation and validation.
06 / Looking ahead
What comes next
Await maintainer direction on the proposed scope and command design, complete further review and required validation, and prepare a focused upstream contribution if aligned. Status checked on 3 October 2026.