Template

Air-Gapped Operations

Runs entirely on your hardware with a local LLM. Zero network egress. Filesystem-only channels. For environments where cloud LLMs are forbidden.

Air-gapSandboxToolsMemory

For: DoD-adjacent, finance compliance, healthcare data residency, classified environments — anyone whose security team says no SaaS bots.

Air-Gapped Operations

Your security team says no cloud LLMs. Your compliance team says no data egress. Your CISO says no SaaS bots. Lockdown is the agent that lives entirely on your hardware.

Why this template exists

This is the template that justifies Scout's existence to operators that ChatGPT and Claude Projects can't serve. If you're in a regulated industry — DoD-adjacent, classified, finance compliance, healthcare data residency, critical infrastructure — your environment has hard rules:

  • No data leaves your network
  • No third-party services touch your data
  • No external API calls, period
  • All software must be auditable and run on hardware you control

These rules aren't a preference; they're contractual or legal. Most AI products can't operate inside them. Lockdown is designed inside them.

What it does

Lockdown runs as a local agent on your hardware. It uses a local LLM (llama.cpp or Ollama) — no API calls to OpenAI/Anthropic/Google. It communicates via filesystem channels: drop a task description in /agent-in/, the agent picks it up, processes it, writes results to /agent-out/.

There are no network channels. No webhooks. No Telegram. No SaaS integrations. The agent's entire surface area is two directories on your filesystem.

This is intentional. The filesystem is the security boundary. You control what enters /agent-in/ (your scripts, your ETL job outputs, your watched directories). You control what reads from /agent-out/ (your downstream processes, your operators, your audit log).

The agent itself runs sandboxed: scout_runtime's sandbox layer explicitly denies outbound network traffic when the air-gap mode is enabled. This is not a soft policy; it's enforced at the syscall level by the sandbox.

What you'll configure

After picking this template, the architect will walk you through:

  1. Pick a local model. Llama 3.1 70B via llama.cpp is the recommended starting point if you have GPU. Llama 3.1 8B works on CPU-only setups. Ollama is the easier path; llama.cpp is the more performant one. The architect explains the tradeoffs.
  2. Verify the model file. Lockdown checks the GGUF file exists at the path you specify before starting. Catches the "I forgot to download the model" error early.
  3. Configure the I/O directories. Default is /agent-in/ and /agent-out/; you can move them anywhere. The agent will refuse to start if these paths don't exist or aren't writable.
  4. Optional: enable sandboxed exec. If your agent needs to run diagnostic commands (e.g., parse log files, run grep across a filesystem mount), enable the sandboxed_exec action. It runs with no network access and only the filesystem paths you whitelist.
  5. Verify the air-gap. Before deploying, the architect can produce a verification checklist: a tcpdump command to confirm zero outbound traffic during a test run, the firewall rules you need on the host, the audit log paths to watch.

What it looks like running

# Operator drops a task
$ echo "Summarize the last 24h of /var/log/auth/access.log,
flag any failed-login spikes" > /agent-in/2024-03-12-1402.task

# Lockdown picks it up within the poll interval (default 60s)
# Lockdown processes via local model + sandboxed_exec on the log file
# Lockdown writes result to /agent-out/

$ cat /agent-out/2024-03-12-1402.result
Summary: last 24h of /var/log/auth/access.log

Total auth attempts: 18,412 (baseline ~17,000 ± 2,000)
Failed login spike at 03:42-03:51 EST: 847 failures from IP 10.42.1.18.
Affected accounts: 4 (svc-deploy, ci-bot, monitoring, scrape-prod).
Pattern: rotating user-agent strings, password-spray characteristics.

No successful login from 10.42.1.18 in the window.
Recommendation: confirm 10.42.1.18 is expected internal IP; if not,
escalate to network-sec via standard channel.

Source data: /var/log/auth/access.log, lines 487,221-505,633.
Sandbox: filesystem read-only on /var/log; no network egress observed.

The whole interaction never touched the internet.

Verify your air-gap

After deploying, run a verification pass:

# Watch for any outbound traffic from the agent process
sudo tcpdump -i any -nn 'host not 127.0.0.1 and \
  port not 53'  # exclude DNS

# In another terminal, give the agent a task
echo "test task" > /agent-in/test.task

# After agent processes the task, kill tcpdump
# If tcpdump captured ZERO packets, your air-gap is verified

The architect ships a verify-airgap.sh script that automates this check. Run it after every deploy and after every model swap.

Why this is CIQ's differentiator

CIQ ships Rocky Linux to enterprises that can't use Red Hat for compliance reasons. The same customers can't use ChatGPT, can't use Claude, can't use Bard. They need agents that match their environment: on-prem, auditable, local-everything.

Lockdown is the Rocky Linux distribution-shaped agent template. It's the one CIQ can sell into the DoD, into FedRAMP-bound vendors, into HIPAA-regulated healthcare, into FINRA-regulated trading desks.

It's also the template that proves Scout is the right platform for regulated AI. The agents Scout designs inherit air-gap support because the runtime supports it. This is the platform thesis made concrete in one template.

When this template isn't right

  • You're not in a regulated environment — local LLMs are slower, worse, and more annoying than Anthropic/OpenAI. If you don't need the air-gap, use Personal CIO or Research Synthesizer with their cloud-model defaults. They'll be faster and smarter.
  • You don't have GPU hardware — CPU-only inference on Llama 3.1 8B works but is slow (5-30s per response). If you can wait, fine. If you can't, the template isn't useful without GPU.
  • You need internet research — the agent can't fetch URLs. If your task needs the web, this template can't do it. Consider a hybrid: Lockdown for processing + a separately-deployed Hermes for research, with a manual gate between them.

What you can ask the architect to change

  • "Use Ollama instead of llama.cpp" — swaps the local-model runtime
  • "Add a local vector index — let me search documents in /docs/" — adds local RAG without breaking the air-gap (the index is local)
  • "Two-way audit logging — every task + result also goes to /audit/" — adds an audit channel for compliance trails
  • "Run as a non-root user with strict cgroup limits" — extra-paranoid hardening for the most-regulated environments

See it in action

Sample interactions illustrating how Lockdown actually behaves.

Operator drops a log-summary task

You

(file dropped) Summarize last 24h of /var/log/auth/access.log, flag failed-login spikes

Agent

[file written to /agent-out/2024-03-12-1402.result]

Summary: last 24h of /var/log/auth/access.log

Total auth attempts: 18,412 (baseline ~17,000 ± 2,000).
Failed login spike at 03:42-03:51 EST: 847 failures from IP 10.42.1.18.
Affected accounts: 4 (svc-deploy, ci-bot, monitoring, scrape-prod).
Pattern: rotating user-agent strings, password-spray characteristics.

No successful login from 10.42.1.18 in the window.
Recommendation: confirm 10.42.1.18 is expected internal IP; if not, escalate via standard channel.

Source data: /var/log/auth/access.log, lines 487,221-505,633.
Sandbox: filesystem read-only on /var/log; no network egress observed.

Heartbeat-triggered scan finds an anomaly during scheduled check

You

(no input — heartbeat at 03:00 EST)

Agent

[file written to /agent-out/2024-03-12-0300.heartbeat]

Heartbeat scan — 03:00 EST.

No anomalies in last hour:
- /var/log/audit: no new HIGH-severity events
- /var/log/auth: failed-login rate 8/min (normal)
- /var/log/syslog: no kernel warnings or OOM kills
- Disk: /var at 67%, /tmp at 12%, /home at 84% (watch)

No action required. Next scan at 03:30 EST.

Operator verifies air-gap before deploying to production

You

(running verify-airgap.sh)

Agent

[file written to /agent-out/airgap-verification-2024-03-12.report]

Air-gap verification report — 2024-03-12 14:30 EST.

Test duration: 10 minutes
Agent tasks processed: 4 (test-1, test-2, test-3, test-4)

Network capture (tcpdump excluding loopback + DNS):
- Total packets captured: 0
- Outbound connections attempted: 0
- Inbound connections accepted: 0

Firewall state at test start: DROP all outbound except loopback ✓
Model file integrity: SHA256 verified ✓
Sandbox state: ENFORCED ✓

Verdict: AIR-GAP VERIFIED. Safe to deploy.

Ready to deploy this agent?

Picking this template loads the configuration above into the Forge Architect. You can refine anything via plain English before deploying.

Use this template