We Built a Security Scanner That Automates Itself - and Never Touches the Cloud

How AI Security Studio's ASS Script engine lets you record, replay, and narrate a full offline security scan - deterministic analysis first, local LLM reasoning second.

Most "AI-powered" security tools have the same dependency: your code has to leave your machine to get an answer.

That's a non-starter for a lot of security research - client engagements under NDA, regulated codebases, or just not wanting proprietary source sitting in someone else's inference logs.

AI Security Studio is built the other way: everything runs locally. Local LLM (Ollama / llama.cpp / LM Studio), no external API calls, no telemetry.

This post walks through one specific piece of it - the automation engine we call ASS Script - and the small offline pipeline I built on top of it to generate narrated, subtitled walkthrough videos without touching a cloud TTS API either.

Deterministic first, LLM second

Before any AI touches a finding, it goes through:

Parser → Rule Engine → Knowledge Retrieval → Summarization → LLM → Reasoning → Finding → Report

Static parsing (Roslyn / Tree-sitter) and a deterministic rule engine - secret detection, header analysis, JWT validation, SQLi/XSS pattern matching - do the actual discovery.

The LLM never sees raw source. It only reasons over structured summaries the rule engine already produced: explaining why something is a bug, correlating findings, drafting the writeup.

If the evidence isn't solid, the system is designed to say "needs manual verification" rather than invent a conclusion.

Record once, replay forever

ASS Script (AI Security Studio Automation Script) is an iMacro-style record/play/edit engine built on the same node-graph designer used elsewhere in the app.

Scripts are plain YAML - readable and diffable, not an opaque macro blob:

nodes:
  - id: "n5"
    kind: "GuiInteract"
    title: "Click Find bugs on this URL"
    notes: "Imports the URL as a one-host scope. Scope import only - sends no network traffic by itself."
    parameters:
      control: "ScanUrlButton"
      action: "click"
  - id: "n9"
    kind: "GuiInteract"
    title: "Click Scan All"
    notes: "Kicks off the panel's real passive sweep - genuinely live crawl traffic, same as a human operator would trigger."
    parameters:
      control: "ScanAllButton"
      action: "click"
  - id: "n14"
    kind: "RunScan"
    title: "Live source scan"
    notes: "Runs the real ScanService against the target's own source directory - footage shows a real scan, not a mockup."
    parameters:
      path: "/path/to/target/source"

Each node is a real GUI action or a real scan/analyzer call - no simulated steps.

You record a workflow once, then replay it identically from the GUI or the CLI (workflow run some-script.adrflow.yaml).

The fun side quest: offline narration for the demo videos

We wanted walkthrough videos with voiceover and subtitles, but the "generate subtitles" step usually means uploading video/audio to a cloud transcription or TTS API - which would be a little embarrassing for a project whose whole pitch is "nothing leaves your machine."

So the pipeline is: write the shot list as a markdown table (beat / timecode / on-screen action / caption / VO line), then run it through a small Python script that:

• Parses the table into timed cues
• Synthesizes each VO line with macOS's built-in say (fully offline TTS)
• Measures each clip's real duration with ffprobe
• Concatenates them into one narration track with ffmpeg
• Emits a .srt timed to the actual synthesized audio, not a guess
• Flags any beat where the narration runs longer than the video's planned window, so you know exactly where to hold a shot longer

The output is a narration.wav + captions.srt pair generated entirely from tools already on the machine - no API keys, no cloud dependency, same philosophy as the scanner itself.

Why this matters beyond the demo video

The pattern generalizes: treat the LLM/AI step as optional and swappable, put the deterministic and local-first parts first.

It's true for the security pipeline (rule engine before LLM) and it turned out to be just as true for the tooling around the project (offline TTS before cloud TTS).

If your architecture assumes "AI" every time it actually means "network call," that's worth questioning.