Make an AI agent's working directory a trust boundary: scope, disclose, consent

When your coding agent starts, it inherits the folder it opens. That folder is the first trust boundary the user can see, and the one attackers can reach without asking.

A malicious website can drop a file into a user's Downloads folder without a click or permission. Omdia's survey of cybersecurity decision-makers found that 40% of respondents had limited confidence in their organizations' AI-agent security. A local instruction file should not be able to install packages, change configuration, or leak authentication tokens without a visible consent step. The product response is a boundary the user can see: scope the directory, disclose what the agent reads, and make configuration changes require consent.

The working directory is the trust boundary

When an agent loads instruction files from a project, it is taking orders from files. Those files may be part of the repo, part of the user's machine, or part of a web drop. The UI should make that difference obvious before the model starts working.

The model may be careful, but the file system is not. A path is a permission. A loaded instruction file is a standing order. The threat is prompt injection through files, not just through chat: the instruction can arrive before the user types anything.

In one case, a malicious AGENTS.md in a customer's Downloads folder told Codex to install the malicious npm package function-color, and the company stopped the installation before execution.

In reproduction tests, Codex obeyed the malicious instructions in over 90% of runs, and the behavior included changing machine-wide MCP server settings and opening a session with approval and sandbox controls bypassed.

A rogue CLAUDE.md file could point Claude Code's API traffic at a researcher-controlled server, leak authentication tokens, and let that server issue commands, with the configuration change working in about half of the tests.

Ship the boundary as product behavior

The order matters. Start with the file system, then the instruction surface, then the consent surface. Each layer should be visible to the user, not just to the backend. These are agent guardrails that belong in the product, not in a security white paper.

• Scope the working directory to the project root. Done means the agent can read and write only inside the opened project, and any path outside that root is blocked or flagged. The boundary should follow the project the user opened, not a broader machine location.
• Classify folders as trusted, user-writable, or web-writable. The finished state is a visible trust class on the active directory, with the reason for its level. A folder the user controls is one class; a folder that a web drop can reach is another.
• Surface loaded AGENTS.md or CLAUDE.md files in the UI. These files can carry instructions that agents follow, so the user should see where a loaded file came from before the agent acts.
• Require consent for configuration changes, including MCP server settings. The consent step should show what changes, what it affects, and whether it applies machine-wide. No silent config edits.
• Treat web-writable folders as untrusted input. Done means files from Downloads are treated as data, not commands. The agent may summarize them, but it should not execute instructions from them without an explicit user action. The common mistake is assuming a file is harmless because it looks like documentation.
• Add evals for malicious instruction files. The finished state is a test suite with malicious AGENTS.md and CLAUDE.md files that try to install packages, redirect API traffic, or bypass sandbox controls. The evals should report which instructions were ignored, which were blocked, and which required consent.

The failure mode is a writable folder

The dangerous path is a file that arrives in a place the agent already trusts. The launch should not happen until the UI can show the boundary.