Agent File-Edit Persistence — SSH Authorized Keys / Shell Startup PATH Hijack

How the attack works

An attacker with control over what an AI agent is instructed to do directs it to use its file-write or file-edit tool. In one variant, the agent appends an SSH public key (ssh-rsa, ssh-ed25519, etc.) to ~/.ssh/authorized_keys, giving the attacker a standing login credential. In the other variant, the agent edits a shell startup file (.bashrc, .zshrc, .profile, or a profile.d script) so that a writable-by-anyone directory like /tmp, /var/tmp, /dev/shm or ~/.cache is placed at the front of the PATH. Any command the user later runs whose name matches a file planted in that folder executes the attacker's code instead of the real program. The detection ties the write action to the specific agent process and session it came from, so the alert reflects one concrete instance of this behavior rather than a general pattern across the environment.

Netzilo detection

Why it matters

An attacker gains either a durable login credential (SSH key) or the ability to silently substitute commands for a user's future shell sessions, both of which allow lasting access or code execution without repeating the initial compromise.

What you can do

• →Review any AI agent activity that writes to ~/.ssh/authorized_keys or shell startup files, and confirm it was explicitly requested by an authorized operator.
• →Restrict agent file-write tools from touching SSH configuration and shell profile files unless that is a defined, approved task.
• →Audit PATH entries in startup files for world-writable directories (/tmp, /var/tmp, /dev/shm, /private/tmp, ~/.cache) and remove any that aren't tied to a known toolchain.
• →Periodically diff authorized_keys files and shell startup files against known-good baselines to catch unauthorized additions early.

Known benign look-alikes

• Legitimate provisioning work where the operator explicitly asks the agent to add their own SSH public key to authorized_keys on a new dev box, CI runner or jump host.
• Dotfile-management workflows (chezmoi, ansible, stow, home-manager) where the agent edits .bashrc/.zshrc and a toolchain genuinely prepends a cache-backed bin directory (for example a pyenv/uv/bun shim under $HOME/.cache) ahead of $PATH.
• Container or devcontainer bootstrap scripts that intentionally prepend /tmp or /dev/shm build directories to PATH in a throwaway image.
• Integration tests or documentation fixtures whose write target is itself a shell rc file (for example a test asserting rc parsing) — the target-path gate keeps README or tutorial writes that only *mention* authorized_keys from matching, but a fixture literally named .bashrc will match.
• Security-research and detection-engineering repositories where the agent authors an example authorized_keys or PATH-hijack rc file as test data.

References

• https://attack.mitre.org/techniques/T1098/004/
• https://attack.mitre.org/techniques/T1546/004/
• https://attack.mitre.org/techniques/T1574/007/

Related threats