baselineFree
Creates the trusted reference state that the rest of the workflow depends on. Baseline Scan is the foundation of the free CLI model.
Docs · Use Cases
AuditWalk in Practice
AuditWalk is built around a Baseline-first workflow, and the free CLI already provides meaningful tools for establishing trusted state, running targeted checks, and detecting drift over time.
While the broader AuditWalk platform extends into interpretation and repair planning, the currently available command-line tools are already useful for disciplined, evidence-based review.
The examples below focus on how the free CLI can be used in practice. They show how Baseline Scan creation, PreFlight checks, and Compare runs help users verify change, investigate drift, and build a clear understanding of what happened before deciding what to do next.
preflightFree
Runs a narrower, targeted check using the active baseline as reference. Useful when you want faster focused review without immediately running full Compare.
compareFree
Performs full drift detection against the confirmed baseline. This is the core free CLI command for measuring what changed.
doctorPaid / Coming
Interprets Compare output and helps explain what findings likely mean. Extends the workflow, but free Baseline/PreFlight/Compare already provide practical value.
repairPaid / Coming
Builds scoped repair plans from confirmed findings. Like Doctor, this extends the workflow beyond observation and comparison.
Supporting Commands
inspect, report, trust, status, full
Free CLI: baseline, preflight, compare, inspect, report, trust, status, full
Paid / Coming: doctor, repair (platform extension)
Use Case 01 — Crypto & Blockchain
Before you move funds, verify your environment.
You're about to make a significant transaction — transferring crypto, signing a contract on-chain, or moving funds between wallets. Your system has been running for a few days. Browser extensions have updated. You've run a few scripts. You want to know that nothing in your environment has changed in a way that could intercept or redirect what you're about to do.
01
Establish your baseline on a known-clean system
The first time you use AuditWalk — ideally right after a fresh install or a point you trust — you run a full scan and confirm it as your baseline. This becomes the reference everything is measured against.
auditwalk scan run --profile full
auditwalk baseline set --scan-id <scan_id>
✓ Scan complete — scan_00041
✓ Baseline Scan completed — 48,219 paths recorded
Baseline is now active. Run preflight or compare at any time.
02
Run a preflight before the transaction
Before you open your wallet or connect to any exchange, run a targeted preflight scoped to the areas most likely to be compromised — browser profile, system startup entries, and crypto-related paths.
auditwalk preflight run --scope browser,system,crypto
✓ Preflight complete — browser, system, crypto
Compared against baselined 3 days ago
Findings: 0
✓ CLEAR — no drift detected in scoped areas
03
Proceed, then compare after the transaction
After the transaction completes, run a full compare. This documents the post-transaction state and gives you a record of anything that changed during the session.
auditwalk compare run
auditwalk report render --format md --out ./post-transaction-report.md
04
If drift is detected, run doctor before acting
If compare surfaces findings, doctor interprets them and tells you what they mean in context — whether they're expected browser cache changes or something worth investigating before you transact again.
auditwalk doctor
What good looks like
Preflight returns zero findings in browser, system, and crypto scopes. The output reads CLEAR. You proceed with confidence knowing your environment matches the state you confirmed as trusted.
✓ CLEAR — 0 findings
browser: 0 system: 0 crypto: 0
Compared against baseline artifact scan_00041
What to investigate
A new browser extension appears, or a startup entry you don't recognise has been added. Don't proceed with the transaction until doctor has assessed the finding and you've resolved it or confirmed it as expected.
! ATTENTION — 2 findings
~ browser extension modified
~/.config/chromium/Default/Extensions/
+ new startup entry detected
/etc/systemd/system/update-helper.service
Use Case 02 — Autonomous Agents
Verify what your agent actually did.
You're running an automated workflow — a local agent that browses, writes files, executes scripts, or manages your environment on your behalf. The agent has legitimate access to your system. The question isn't whether it's supposed to be there — it's whether everything it changed was intentional and expected.
01
Snapshot before the agent run
Before triggering the agent, capture the current system state. If you already have a confirmed baseline, run a fresh scan so you have a timestamped pre-run artifact to compare against.
auditwalk scan run --profile full
✓ Scan complete — scan_00089
48,312 paths recorded at 14:22:07
02
Run your agent workflow
Execute the agent task as normal. AuditWalk is passive — it doesn't interfere with or monitor the agent in real time. The comparison happens after the fact against the snapshot you just captured.
03
Compare against the pre-run snapshot
After the agent completes, run a compare to surface every filesystem change the session produced. This gives you a factual record of what the agent did — useful both for verification and for building a log of agent activity over time.
auditwalk compare run
auditwalk attention show
✓ Compare complete
Drift detected: 14 changes
+ 11 files added (expected — agent output)
~ 2 files modified (expected — config updates)
+ 1 file added (unexpected — review required)
/etc/cron.d/agent-persist
04
Doctor reviews the findings
Doctor reads the compare output and assesses each finding — distinguishing expected agent activity from anything that warrants investigation. In this case, a new cron entry that wasn't part of the task definition gets flagged for review.
auditwalk doctor
Reviewing 14 findings from compare run...
✓ 13 findings assessed as expected agent activity
! 1 finding requires attention
/etc/cron.d/agent-persist
Severity: HIGH
A persistence entry was added outside the agent's declared
task scope. This path was not present before the run and
does not match known agent output patterns.
Recommendation: inspect before next agent execution.
05
Inspect the flagged finding, then decide
Use inspect to drill into the specific finding. If it's legitimate — something your agent is supposed to add — you can acknowledge it and update your baseline. If it's not, repair will generate a plan to remove it.
auditwalk inspect /etc/cron.d/agent-persist
What good looks like
Every change the agent made is accounted for and matches what the task was supposed to do. Doctor confirms all findings as expected. You update your baseline to reflect the new trusted state.
✓ All 14 findings assessed
✓ No unexpected activity detected
Recommend: confirm new baseline to record agent output
What to investigate
Startup entries, cron jobs, or new executables that weren't part of the agent's declared task. New entries in system paths the agent had no reason to touch. Any modification to browser profiles or authentication files.
! Unexpected persistence entry
! New executable in /usr/local/bin/
~ Browser profile modified outside agent scope
Use Case 03 — IT Service Providers
Baseline on intake. Compare on every callback.
A customer brings in a machine. You clean it up, remove malware, update software, and return it. Three weeks later they call back: it's running slow, something's not right. Without a baseline from when the machine left your shop, you're diagnosing blind. With one, you have a structured diff of exactly what changed between then and now.
01
Baseline the machine before it leaves your shop
After you've completed your work and the machine is in a known-good state, run a full scan and run Baseline Scan. Label it clearly so you can identify it when the customer calls back.
auditwalk scan run --profile full
auditwalk baseline set --scan-id <scan_id>
✓ Scan complete — scan_00012
✓ Baseline Scan completed
Label: customer-smithj-post-repair-2026-03-15
42,108 paths recorded
02
On callback — run a compare immediately
When the customer brings the machine back or calls reporting issues, the first thing you do is run a compare against the baseline you set at last service. This gives you a structured list of everything that changed since the machine left your shop.
auditwalk compare run
✓ Compare complete
Compared against baseline: customer-smithj-post-repair-2026-03-15
Drift detected: 47 changes
~ 31 system/package updates (expected)
+ 9 new browser extensions
+ 4 new startup entries
+ 3 new executables in user paths
03
Run doctor to prioritise the findings
Doctor reads the compare output and ranks the findings by severity, separating routine changes from items requiring investigation. This saves you the time of manually reviewing every changed file.
auditwalk doctor
Reviewing 47 findings...
✓ 31 findings: routine system updates — no action needed
! 9 findings: browser extensions — review recommended
! 7 findings: HIGH severity — action required
new startup entry: /etc/systemd/system/ms-update.service
new startup entry: /etc/init.d/browser-helper
new executable: /usr/local/bin/sys-monitor
(+ 4 more — run attention show for full list)
04
Generate a repair plan and review it with the customer
Repair produces a step-by-step plan for resolving the high-severity findings. Crucially, nothing executes until you approve each action — you can review the plan with the customer before making any changes.
auditwalk repair plan
auditwalk report render --format md --out ./smithj-callback-report.md
What good looks like
Compare shows only expected changes — OS updates, application patches, user-installed software. Doctor confirms no high-severity findings. You export the report, update the baseline, and return the machine with a clean bill of health and documentation to prove it.
✓ 47 findings — all assessed LOW or INFO
✓ No unexpected persistence or executables
Ready to export report and update baseline
What to investigate
Startup entries with names imitating legitimate services. New executables in system or user paths the customer didn't install. Browser extensions added after the repair date. Any modification to authentication or credential files.
! Startup entry mimics system service name
! Executable added to PATH after repair date
~ SSH config modified — verify with customer
Use Case 04 — Developers & SRE
Catch configuration drift before it becomes an incident.
You maintain a Linux environment that's been running for months. Packages update, cron jobs accumulate, config files drift from their intended state. Something is behaving differently — slightly slower, an intermittent error, a service that restarts more than it should. You want a structured diff between the system as it is now and the system as it was when everything last worked correctly.
01
Establish a baseline at a known-good state
After a clean deploy, a successful rollout, or any point you consider a reliable reference, run a full scan and run Baseline Scan. This is the state you'll compare future runs against.
auditwalk scan run --profile full
auditwalk baseline set --scan-id <scan_id>
02
Run preflight regularly as a lightweight check
Rather than a full compare every time, use preflight scoped to the areas most likely to drift — system configs, executables, startup entries. It's fast enough to run before a deployment or at the start of an on-call shift.
auditwalk preflight run --scope system,files
✓ Preflight complete — system, files
Compared against baseline from 2026-03-01
~ 3 config files modified
Run compare for full details
03
Full compare when preflight flags drift
When preflight finds something, run a full compare to get the complete picture. The compare artifact contains structured JSON output you can feed directly into your alerting or logging pipeline.
auditwalk compare run
auditwalk compare export --format json --out ./drift-report.json
✓ Compare complete — 3 findings
~ /etc/nginx/nginx.conf modified
~ /etc/systemd/system/app.service modified
~ /usr/local/bin/deploy-hook modified
04
Doctor identifies the root cause
Doctor reads the compare findings and tells you which changes are likely to be causing the behaviour you're seeing, with enough context to act on it without manually diffing every file.
auditwalk doctor
Reviewing 3 findings...
! nginx.conf — worker_processes value changed
Before: worker_processes auto;
After: worker_processes 1;
Assessment: likely cause of degraded throughput under load.
~ app.service — restart policy tightened (expected)
~ deploy-hook — timestamp only, no functional change
What good looks like
Preflight returns clean on system and files scope. Compare after a deploy shows only the files you changed intentionally. JSON output lands cleanly in your pipeline. Baseline updated to reflect the new deployed state.
✓ CLEAR — 0 unexpected findings
3 expected changes from deploy confirmed
Baseline updated: scan_00203
What to investigate
Config files modified outside a deployment window. New cron entries or startup hooks you didn't add. Executables that changed outside a package update cycle. Any modification to files that should be immutable between deploys.
! cron entry added outside deploy window
~ /etc/hosts modified — verify intent
! binary changed outside package manager
Use Case 05 — After Remote Access
Someone had access to your system. Here's how to find out what they changed.
You allowed someone access to your machine — a support technician, a friend helping remotely, or someone who convinced you to share your screen or install a remote desktop tool. The session is over. You want to know what they did while they had access. Maybe you're confident it was fine. Maybe you're not. Either way, you want evidence rather than assumption.
01
If you have a pre-session baseline, run compare now
If you had the foresight to run a scan and confirm a baseline before the session, you can immediately compare against it to see everything that changed while the other person had access.
auditwalk compare run
✓ Compare complete
Compared against baselined before remote session
Drift detected: 8 changes
02
If you don't have a baseline, start one now
If this is your first time using AuditWalk and you don't have a pre-session baseline, run a scan now and confirm it. It won't tell you what changed during the session you just had — but it gives you a clean reference point for everything going forward. From this point you're protected.
auditwalk scan run --profile full
auditwalk baseline set --scan-id <scan_id>
03
Run doctor to interpret the findings
Doctor reads the compare output and distinguishes expected changes — software that was legitimately updated, files the technician was supposed to touch — from anything that looks out of place. The assessment is specific and path-level, not generic.
auditwalk doctor
Reviewing 8 findings...
✓ 5 findings: expected — driver updates and log files
! 3 findings: HIGH severity
new executable: /usr/local/bin/sys-helper
new cron entry: /etc/cron.d/update-check
modified file: ~/.ssh/authorized_keys
Assessment: these changes are not consistent with a
routine support session. Recommend repair before
next sensitive activity.
04
Review the repair plan before acting
Repair generates a step-by-step plan for removing or reversing the concerning changes. You review every action before anything executes. Nothing happens without your explicit approval.
auditwalk repair plan
Repair plan — 3 actions
1. Remove /usr/local/bin/sys-helper
Hash: a3f9c... — not present in baseline
Action: delete — requires sudo
2. Remove /etc/cron.d/update-check
Added during session window
Action: delete — requires sudo
3. Restore ~/.ssh/authorized_keys
Modified during session — baseline version available
Action: restore from baseline artifact
Review complete. Run: auditwalk repair execute to apply.
What good looks like
Compare shows only the changes you expected — the driver update, the file the technician said they'd modify. Doctor confirms all findings as consistent with the stated purpose of the session. You have a documented record of the session's effect on your system.
✓ 4 findings — all consistent with support session
✓ No unexpected persistence, executables, or auth changes
Session documented. Baseline updated.
What to investigate
New executables with generic names. Cron entries added during the session window. Any modification to SSH authorized keys, browser profiles, or credential files. Startup entries that weren't there before the session.
! authorized_keys modified during session
! new executable — not in baseline
! cron entry added — investigate before proceeding
Use Case 06 — Suspicious Activity
You clicked something. Here's how to find out if it did anything.
You clicked a link that didn't look right. A download started that you didn't expect. An installer ran and you're not entirely sure what it installed. You want to know — specifically and factually — whether anything on your system changed as a result. Not a virus scan that tells you it's clean. Actual evidence of what changed and what didn't.
01
Run a targeted preflight immediately
If you have a confirmed baseline, run preflight immediately — scoped to the areas most likely to be affected by a malicious download. The faster you run it, the cleaner the signal. Don't reboot first if you can help it.
auditwalk preflight run --scope browser,system,files
✓ Preflight complete — browser, system, files
Compared against baselined 6 days ago
! ATTENTION — 2 findings require review
02
Run a full compare to see everything
After preflight gives you an initial picture, run a full compare to catch anything outside the scoped areas. Suspicious downloads sometimes target paths you wouldn't think to check first.
auditwalk compare run
✓ Compare complete
Drift detected: 3 changes
+ new file: ~/Downloads/installer.sh
+ new file: /usr/local/bin/update-helper
~ modified: ~/.bashrc
03
Doctor tells you what the findings mean
Doctor reads the compare output and tells you which findings are concerning and why. It doesn't just list what changed — it gives you context: what the file appears to do, why it's in a concerning location, and what the recommended response is.
auditwalk doctor
Reviewing 3 findings...
~ ~/Downloads/installer.sh — download artifact, low risk if not executed
! /usr/local/bin/update-helper — HIGH
Executable placed in PATH. Name follows a common
masquerade pattern for persistence tools.
Not present in baseline. Not associated with a
known package manager transaction.
Recommendation: do not execute. Review and remove.
! ~/.bashrc — MEDIUM
A PATH addition was appended to your shell config.
This causes /usr/local/bin/ to be searched before
system paths on login.
Recommendation: review the appended line and restore
if not intentional.
04
Generate a repair plan and review before acting
Repair produces a specific, reviewable plan for each finding. For the executable in PATH, it proposes deletion. For the bashrc modification, it shows you exactly what was added and offers to restore the baseline version. You approve each action individually.
auditwalk repair plan
What good looks like
Compare returns zero findings or only the download file itself in your Downloads folder. Doctor confirms nothing was executed or installed. You have factual evidence the click didn't result in any system change — which is often exactly the reassurance you need.
✓ CLEAR — 1 finding
~/Downloads/suspicious-file.pdf
✓ Download artifact only — no execution detected
✓ No system paths, startup entries, or configs modified
What to investigate
New executables in PATH locations. Modifications to shell config files like .bashrc, .profile, or .zshrc. New startup entries or cron jobs. Browser extension changes that happened at the same time as the download.
! Executable added to PATH location
! Shell config modified — PATH manipulation
! Browser extension added in same time window