🔄 Topic

Not every automation lane deserves to run unattended. I documented which ones do, wired the Headroom proxy in properly as a managed service, and explicitly banned a lane that looked fine but was not.

🎯 Goal

Turn “can this run without me watching?” from a gut call into a written routing policy, with the supporting infrastructure installed the reliable way.

🛠 What I Did

I treated unattended-ness as a privilege a lane must earn.

Main areas covered:

  • documented the Qwen+Headroom workflow as an approved unattended delegation lane, with its constraints written down
  • added an opt-in wrapper for the Headroom proxy rather than making it a silent default
  • installed the proxy as a LaunchAgent so the managed service survives restarts predictably instead of living in a forgotten terminal tab
  • explicitly documented a warning against the aider-qwen lane for unattended delegation — fine supervised, not trustworthy alone
  • cross-linked the routing docs so anyone (including future me) hits the warning before wiring that lane into anything autonomous
  • kept the unattended criteria consistent with the rest of the stack: verified outputs, bounded writes, recoverable changes

🔗 Key Cybersecurity Connections

“Unattended” is a privilege level. A lane running while nobody watches has no human compensating control, so it must carry its own: verification, bounded scope, recoverability. Writing down which lanes qualify — and which do not — is the same exercise as deciding which jobs may run as a service account versus which require an operator present.

The negative documentation matters most. A written “do not use X unattended” is a guardrail; an unwritten one is a future incident with good intentions.

🔍 Investigation Questions

  • What exactly qualifies a lane for unattended operation?
  • Which lanes are explicitly banned, and is the ban discoverable?
  • Does the managed service restart cleanly after reboot or crash?
  • What does an unattended lane do when its verifier fails at 3am?
  • Is the opt-in explicit, or could the proxy engage by surprise?

🚨 Detection Opportunities

Checks for unattended lanes:

  • banned lane appearing in an unattended schedule
  • managed service down while its lane still accepts tasks
  • unattended run completing without its verification record
  • opt-in wrapper bypassed by direct invocation
  • overnight failure queue growing without a morning alert

Example:

project=unattended-delegation
signal=banned_lane_scheduled_unattended
risk_area=unsupervised_untrusted_automation
triage=halt_schedule_check_routing_docs_and_who_wired_it

🧭 MITRE ATT&CK Techniques

Possible mapping for the infrastructure choice:

  • T1543 — Create or Modify System Process (LaunchAgents are persistence; installing my own deliberately is the defensive mirror of watching for hostile ones)

🗺 Visual Investigation Diagram

Lane candidate
    ↓
Verified outputs? Bounded writes? Recoverable?
    ↓ yes                    ↓ no
Approved unattended      Documented ban
    ↓
Opt-in wrapper + managed service
    ↓
Overnight work with morning evidence

⚠ Challenges

The hard part was banning a lane that mostly works. “Mostly works” is exactly the profile that causes 3am damage — good enough to trust, not good enough to deserve it. Writing the warning felt like admitting a tool failed; it is actually the routing policy doing its job.

📚 What I Learned

I learned that autonomy policy is written in both directions: approvals with conditions, and bans with reasons. The reasons matter — a ban without its why gets deleted by the next optimistic session.

➡ Next Steps

  • Review the unattended roster monthly against fresh benchmarks
  • Add a morning summary for overnight lane activity
  • Test the LaunchAgent’s crash-recovery behavior deliberately
  • Keep new lanes supervised until they earn the unattended tier

🧠 Reflection

The stack now has something like shift work: trusted lanes on the night shift with their own controls, everything else waiting for the human to come back. That structure came from evidence, not vibes — which has become the rule for everything here.

🧩 Lessons Learned

What worked

Unattended status as an earned tier with written criteria.

What broke

A plausible lane failed the criteria despite looking capable.

Why it broke

Supervised success hides the failure modes that matter when nobody is watching.

Fix / takeaway

Approve with conditions, ban with reasons, and make both discoverable where the wiring happens.

📈 Skill Progression Context

This supports my cybersecurity progression because tiered trust, service hardening, and documented negative controls are the daily mechanics of running production automation safely.

😄 TL;DR

Wrote the night-shift roster for my agents — and one capable-looking lane didn’t make the cut.