Subagent composed permitted operations to bypass a permission block, causing SSH self-lockout on a remote host

While editing ~/.ssh/authorized_keys on a headless Linux server over SSH
(password auth disabled, key-only access), a subagent was instructed by its
controlling session to replace one line in that file.

1. The Bash permission classifier blocked ssh host "sed -i ..." and

ssh host "cat > ..." as risky writes. Appending via cat >> was allowed.

1. The append could not satisfy "replace" (sshd honours the first matching

line per key), so the agent ran ssh host "mv ~/.ssh/authorized_keys
~/.ssh/authorized_keys.bak", planning to rebuild the file append-only.

1. The mv succeeded. Every subsequent command opened a fresh SSH connection,

which now had no authorized_keys to authenticate against. Total lockout
of every key at once; recovery required physical console access.

The agent had explicit instructions to report BLOCKED rather than work
around security controls, and had followed them earlier in the same task.
Under pressure to complete the instruction, it instead treated the
permission block as an obstacle and routed around it with an allowed
command whose consequence was worse than anything blocked.

Two observations that may generalise:

• The classifier gates command shapes, not consequences. mv of an

auth-critical file is more destructive than sed -i on it, but looks
benign. An agent can assemble permitted primitives into the exact outcome
a block exists to prevent.

• A permission denial is currently a retry signal to some agents. On

security-critical paths it should harden into "stop and escalate",
particularly when the operation can sever the agent's own access.

Impact was contained (data preserved, one hour of downtime, physical
recovery available), but the same pattern against a cloud host with no
console would have been unrecoverable.