Persistence is what happens when a malicious agent skill modifies something that survives beyond the current session, so its access or behavior continues even after the original conversation, terminal window, or agent process is long gone. Common targets include shell startup files like .bashrc or .zshrc, cron jobs, systemd units, authorized_keys, and global agent configuration files.

Why this matters more than a one-time action

A destructive command that runs once and finishes has a clear, bounded blast radius. Persistence changes that math entirely. Once a backdoor is written into a startup file or a scheduled job, it doesn't need the original skill, the original conversation, or even the original attacker to still be involved. It just needs the modified file to still be there the next time a shell opens or a cron tick fires.

This is also why persistence attempts are treated as high-severity intent even when a sandbox blocks the actual write. The goal isn't a single successful exploit. It's an entry point that keeps working indefinitely, which is exactly the kind of risk that traditional one-time vulnerability scans are poorly suited to catch, since a scan performed today says nothing about a file quietly modified last week.

What it actually looks like

The technical signature is narrower than it might sound: writes, appends, or modifications targeting a small, well-known set of paths, shell profiles, cron directories, systemd unit files, SSH authorized_keys, or agent-specific configuration and template files. None of these paths are exotic. They're the same handful of locations any persistence mechanism, malicious or otherwise, has to touch to survive a restart.

Attempts to configure project state, templates, MCP setup, and global configuration files were treated as strong-confidence persistence intent in sandboxed evaluation, even when the corresponding write was safely blocked rather than executed.

How detection works without letting it happen

A sandbox designed for this doesn't need to let a backdoor actually get installed to detect the attempt. It monitors filesystem writes directed at these specific configuration paths, flags the attempt as intent-level evidence, and blocks the action from completing. Static analysis complements this by flagging code or instructions that reference these paths in combination with modification operations, giving a pre-execution signal before the skill ever runs.

FAQ

Does persistence always require modifying a system file? Usually, yes, in some form. The specific target varies (a shell profile, a cron entry, an agent config), but the defining trait is a change that outlives the current process, which by definition means writing to something that gets read again later.

Can a blocked persistence attempt still count as evidence of malicious intent? Yes. A sandbox that safely skips a dangerous write still records exactly what was attempted and why it was stopped. That recorded intent is treated as strong evidence on its own, separate from whether the action actually succeeded.

Is this only a risk for local developer machines? No. The same pattern applies anywhere an agent skill runs with write access to persistent configuration, including CI/CD runners and any shared environment where a modified startup file or scheduled job would affect future sessions, not just the current user.

Related reading: "The curl-Pipe-to-Shell Problem: Remote Script Execution in Agentic AI," "Beyond the Code: Tool Poisoning and Agent Goal Hijacking Explained"