The Escape Hatch

"Every good system needs a door for the thing it didn't predict. The trick is a door you can't walk through by accident."

You always need the unanticipated command

No matter how many typed kinds you build, reality will eventually hand you something you didn't foresee — a one-off fix, a debug session, a command that exists for exactly one situation. Pretend that never happens and you force people to smuggle their real work around the system, which is far worse than giving them an honest door.

So build the hatch — and keep it honest

The interactive terminal is that door. But it's built to be impossible to confuse: the host's color and label sit in the tab and terminal chrome, the stable id and current hostname are shown, along with the connection path and the session start time. You can always tell, at a glance, exactly which machine your keystrokes are going to. An escape hatch you can fall through blind isn't safety — it's a trapdoor.

The hatch is never disguised as automation

Nothing typed in the terminal silently becomes a durable fleet operation. That's the whole reason Interactive is its own risk class: so raw shell can't put on the costume of a safe, previewed kind and slip into the automated path. A command runs on the one machine you're looking at, driven by your hand — it doesn't fan out, and it doesn't promote itself.

Even the terminal has boundaries

Registering something as infrastructure — a NAS, say — grants a terminal to it without making it a fleet Mac. It gets a shell; it does not get power policy, probes, or campaign targeting. The terminal is a targeted human surface, not a backdoor that quietly extends fleet membership to anything you can SSH into.

Give the unpredictable a door, and make the door loud. The safest escape hatch is the one nobody can mistake for the front entrance.

Code

The terminal makes its target impossible to miss·json

{
  "terminal_session": "term_9c2",
  "host_id": "server",              // stable identity, always shown
  "hostname": "server.local",       // current observation
  "host_color": "#5BA3D8",          // same color as its fleet card
  "connection_path": "ssh -tt (system client)",
  "started_at": "2026-07-19T10:04:00Z",
  "risk_class": "interactive"       // its OWN class -- never 'automation'
}
// You can always answer 'which machine am I typing at?' from the chrome.
// Nothing typed here becomes a durable fleet operation on its own.

Exercise

Think about the last time a tool wouldn't let you do something legitimate and you worked around it (edited a file it managed, ran a manual command it 'owned'). What visibility did your workaround destroy? Then design an honest escape hatch for that tool: what would it show you about the target so the escape stays inside the audited system?

Hint

The workaround's real cost is invisibility — the tool no longer knows what you did. A good hatch keeps you inside the logged, targeted surface, so the unusual action is still on the record instead of happening in the dark beside it.

You always need the unanticipated command

So build the hatch — and keep it honest

The hatch is never disguised as automation

Even the terminal has boundaries

Code

External links

Exercise

Progress

Comments 0