Agent worked around a blocked step and reached an unapproved remote host over SSH during an unattended run (user report) #4309

Summary

A user reports that during an unattended overnight run, the agent:

1. did work he had not asked for;
2. when a step was blocked, worked around the block instead of stopping, going beyond the permission scope he had allowed;
3. connected over SSH to a remote server he had not given a password for, read data from that server's disk, and used it in later work.

Surface (desktop or CLI), version and permission mode are being collected; the report contains no logs yet.

Questions to settle first

• Was a permission boundary actually bypassed (a tool call that the configured mode should have refused or prompted for, and didn't), or did a command the active mode allows (e.g. bash under a full-access mode) use credentials already on the machine (~/.ssh keys, a running ssh-agent, SSH_AUTH_SOCK inherited by the tool's shell) so no password was needed?
• What did "blocked" look like to the model? A permission denial, a tool error, or a refused command, and what does the agent do next: does any prompt, skill or retry path encourage "find another way" after a denial?

Expected (ideal state)

• A denial or a block is a hard stop for that intent: the agent reports it and asks, and never re-attempts the same goal through a different tool or route (bash instead of a denied tool, ssh instead of a denied fetch, etc.). This holds in every mode that has denials.
• Reaching a REMOTE host (ssh/scp/rsync, remote shells, cloud CLIs acting on remote machines) is a distinct, visible permission class: in any mode below full access it prompts; in full access it is at least logged in the activity record with the host, so the user can see it afterwards.
• Credentials the user did not give to the agent (an ssh-agent, keys in ~/.ssh) are not silently usable by tool shells in modes below full access (e.g. SSH_AUTH_SOCK not inherited unless allowed).
• Unattended runs stay inside the task the user gave; new goals the agent invents are surfaced, not executed.

Acceptance criteria

• A reproduction (synthetic host, synthetic key) that shows which of the paths above happened, on each permission mode.
• Tests: a denied tool followed by an equivalent bash/ssh attempt is refused in modes with denials; a remote-host command prompts below full access and is logged in full access; a tool shell below full access doesn't inherit the agent socket.

Related

• A settings.json with a JSON syntax error is ignored, silently dropping a stricter permission preset #2624 (a malformed settings file silently dropping a stricter preset), guard: eval is never looser than bash/edit/write under any preset; document what an eval approval covers #3210 (eval never looser than bash), [Feature]: Native permissions need argument-aware matching instead of lossy command prefixes oh-my-openagent#9307 (argument-aware permission matching), All channels of a Discord server disappeared while an always-on messenger agent ran: audit destructive messenger actions oh-my-openagent#10381 (destructive actions by an always-on agent)