3  Recipe: first profile and first run

Tool: kailash (profiles, CLI) · Section: Getting started · Level: easy · Time: ~15 min after boot · Layer/Category: CLASSIC (profile system) · Tags: getting-started, install, profile, cli

3.1 Problem

Kailash OS is a NixOS-based distribution for AI security work, built declaratively from a manifest of 337 tools across four layers. A profile selects which tool categories a Kailash system carries — you want to pick the one that matches your role (red-team, blue-team, ops, agent infrastructure), know exactly how you choose it, and verify the system you booted actually is what you asked for.

3.2 Solution

The profile is encoded in the image you download — choosing a profile IS choosing your image. Match your role:

Profile Carries
minimal the CORE substrate — kernel, base userland, hardening, safety defaults, desktop, CLI & menu engines; no tool categories enabled
redteam-ai the AI red-team lab scope — ATTACK core plus its OPS/DEFENCE pairings
full the complete live catalogue (“kali-everything” lab scope)
headless-agent base + CLI only, no desktop; the qcow2 grows at first boot

On the booted system, confirm the landed CLI surfaces:

# 1. The profiles the release declares
kailash profile list

# 2. What the manifest carries for your interest area
#    (manifest inventory — every command reads the manifest)
kailash list --layer ATTACK
kailash search prompt-injection

# 3. One tool's full record: ATLAS tactics, OWASP mapping, docs pointer
kailash info garak

# 4. The manifest invariants, locally (the CI gate, runnable by hand)
kailash manifest validate

What success looks like:

  • kailash profile list names the release’s declared profiles
  • kailash info garak returns the full manifest record — layer ATTACK, category a-02, safety requires-target, ATLAS tactics (AML.T0051, AML.T0054), OWASP LLM01 both epochs, docs pointer
  • kailash manifest validate passes — the loader self-inventory is green on your installation

3.3 Discussion

  • Declarative, not imperative: categories are enabled in the system configuration and a rebuild is the install step; there is no imperative package action that can drift the system away from its declaration. Rebuilding against the same lock reproduces the same tool set exactly — see Enable your first category.
  • kailash list shows the manifest, not your boot state: every CLI command reads the manifest (the CLI derivation bakes the manifest to a store path, so the CLI can never disagree with the declared build). Listing what a profile carries is a build-time fact: per-category VM tests boot a VM and --help-smoke the tool list from the manifest — that is the verified instrument, not a hand-run command surface. A kailash doctor-style per-tool installed/version/smoke check is specified but lands per the roadmap — track it on the OS repo’s CLI lane, not here.
  • Pick redteam-ai for the cookbook’s attack lanes: the scanning and pair recipes assume ATTACK tooling present; pick headless-agent for automation hosts without a desktop.
  • Safety posture comes with the profile: even on full, exp-class tools stay behind the lab-mode gate and requires-target tools refuse to self-fire — the profile states the tool set, the safety classes govern the run behaviour.

3.4 See also

Recipe provenance. Profile table and declarative-enablement statements are from the guide’s profiles chapter (verified 2026-10-14 at main); CLI verbs are the landed slice per kailash-packages#52 (list, search, info, profile list, manifest validate/check) verified against the CLI chapter of the OS spec — roadmap verbs are labelled as such, not quoted.