Guide

How can a coding agent leave behind instructions or access that outlive the session?

Updated November 11, 2026

Short answer

An agent can outlive its session by writing to places that load automatically next time: rules files (AGENTS.md, CLAUDE.md, Cursor rules), project settings and hooks, MCP configs, git hooks, shell startup files, scheduled jobs, CI config, and long-lived tokens or SSH keys. The cheapest control is to make agent config and rules files read-only and watch them for changes. Then check every write to the rest of that list before it runs.

A session ends. The files it wrote don't.

That's the whole problem with persistence. If a coding agent can edit a file that the next session reads, it can pass instructions, or access, to a future version of itself. Sometimes an attacker planted the idea. Sometimes the agent just got creative about "remembering" something.

Where persistence lives#

Think in two groups: files that steer the agent, and things that run without it.

Steering files: AGENTS.md, CLAUDE.md, Cursor rules, agent skills. Every new session reads them as trusted instructions.
Agent config that executes: project settings with hooks, MCP server definitions, plugin entries. These run commands. They don't just suggest them.
Host-level autostart: git hooks, shell startup files (.zshrc, .bashrc), cron, launchd, systemd units.
Pipeline and identity: CI config, long-lived tokens, new SSH or deploy keys.
Trust that ages badly: a tool or MCP server approved once, then changed later.

Harden's threat model for AI coding agents (Nov 2026) gives persistence and privilege manufacturing its own harm class, H5, one of 15 harm classes across 203 threats. It's all about access that outlives the task.

What the public research shows#

Pillar Security's research hid malicious instructions in rules files for Cursor and GitHub Copilot using zero-width joiners, bidirectional text markers and other invisible characters. The researchers noted that the instructions often survive project forking, so the poison travels with the repo.

Check Point Research reported remote code execution and API token exfiltration through Claude Code project files, with hooks defined in .claude/settings.json. Their framing is worth repeating: configuration files that were once passive data now control active execution paths.

BleepingComputer covered a planted AGENTS.md in a Downloads folder. Against Codex, a harmless payload that opened the calculator app succeeded 90% of the time. We wrote up what to check in AGENTS.md in Downloads hijacks Codex.

What the built-in controls do and don't stop#

Managed settings help. In Claude Code, managed settings take precedence over command-line, project and user settings, so a policy you set there beats whatever a repo ships in its own settings file.

They also have limits. The docs say managed settings bind Claude Code only. A developer with admin rights on the machine can also edit the managed source itself, which is why MDM tooling can redeploy it on a schedule.

Control	Stops	Misses
Managed settings (one agent)	Repo settings overriding your policy in that agent	Other agents, shell startup files, cron
Read-only files owned by another account	Edits to rules and config by the agent	Files you forgot to list; anyone with admin rights
Permission rules and prompts	Some writes, as typed	The same write done another way; approval fatigue
Sandbox	Reach outside the workspace	Persistence inside the workspace, like AGENTS.md
Scoped, short-lived credentials	Long-lived tokens and keys	Files that steer the next session

Look at the sandbox row. A rules file lives in the project, so the sandbox lets the agent write it. The steering files need their own protection.

The cheapest control: read-only and watched#

Make the agent's config and rules files read-only and watch them for changes. In Harden's model this is the cheapest high-confidence control, because it removes the re-infection path: nothing the agent writes today gets read as an instruction tomorrow.

Humans still edit these files. They do it on purpose, in a pull request, and never as a side effect of a session. Claude Code runs a ConfigChange hook for each settings-file change it detects, which gives you a signal to log.

A checklist you can run this week#

Inventory every file an agent reads as instructions: AGENTS.md, CLAUDE.md, Cursor rules, skills, agent settings, MCP configs. Include the ones in home directories, not only the ones in repos.
Make them read-only to the agent, owned by an account it can't act as, and alert on diffs. Review them like code, including a check for invisible Unicode.
Set agent policy in managed settings and push it with the MDM you already run.
Alert on writes to .git/hooks, shell startup files, crontab, LaunchAgents and systemd units.
Treat CI config edits as high risk and require a human reviewer.
Replace long-lived tokens with short-lived, scoped ones. Alert on new SSH keys and deploy keys.
Re-check approved tools and MCP servers on a schedule. An approval only covers what the tool was at that moment.
Don't start agents in Downloads or a home directory. Start them in the project root.

Where Harden fits#

Harden Agentic Integrity Foundation (AIF) runs on the developer laptop, outside the agent, at the agent's pre-execution hook. It checks every command, file edit and push against the session's intent before it runs, locally, in milliseconds. One policy covers every agent. It starts watch-only, so you can see what agents are writing before you enforce anything.

For persistence, that means a write to a rules file, a startup file or a hook gets a verdict before it lands. Agent config poisoning is one of the 19 risk categories Harden's local model reviews in context. Permission and security changes are caught by deterministic rules.

It's a layer, not a perimeter. It doesn't replace read-only files, least privilege or scoped credentials, and it can't contain a process that's already malicious on the machine.

FAQ