Stop Untrusted Repo Files From Steering Coding Agents
A coding agent can inherit instructions from a file that your team did not write, review, or even notice. If it also has permission to edit configuration, install packages, or reach the internet, a routine coding task can become an access-control problem.
This is no longer just a prompt-quality issue. Forever Security reports that a malicious AGENTS.md placed in a Downloads folder prompted Codex to add an MCP server and install a malicious npm package in more than 90% of its test runs. The report also describes a CLAUDE.md variant that redirected Claude Code's API traffic. The Hacker News reported on the Downloads-folder test, while Forever Security's write-up details the test setup and behavior.
The operational lesson is not to ban instruction files. They can make an agent more useful. The lesson is to stop treating every instruction file the agent can read as trusted policy. Trust should come from the workspace, the user, and the controls around the agent-not from a file's confident wording.
When this needs an AI agent build
Move from research to an implementation conversation when coding agents will work across cloned repositories, shared developer machines, or business-critical code-and can run tools beyond read-only analysis. The same applies if your team expects agents to install dependencies, change settings, access internal services, or handle credentials.
A solo developer experimenting in a disposable environment may be able to manage this manually. A team rolling out agents needs repeatable rules: which folders are trusted, which actions require approval, what the agent can reach, and how an incident is contained. If you cannot answer those questions for the agent's actual workflow, expanding access is premature.
Why an instruction file becomes a control surface
Files such as AGENTS.md and CLAUDE.md are ordinary text, but coding tools may use them to shape their actions. An instruction can ask an agent to change a configuration file, add a server, run a package manager, or send data somewhere. The risk increases when the agent can act on that request without a separate control checking its source and impact.
A cloned repository is not automatically trustworthy because it is hosted in a familiar service. It can contain legitimate project guidance, stale instructions, or files an attacker added. The same distinction applies to Downloads: a file there may be useful reference material, but its location should not grant it authority over an agent.
The attack surface is broader than the text itself. It includes the agent's file access, shell and package tools, configuration paths, available credentials, approval behavior, and outbound network access. A prompt telling the agent to "be careful" does not restrict those capabilities.
An Instruction File Is Not a Trust Boundary
That distinction also matters for teams using approval prompts. A review button can catch mistakes, but it is not a complete security boundary if the agent can frame a harmful action as necessary or if the reviewer cannot see the effects. An arXiv study examines privilege-escalation attacks against coding agents that use harness-level protections, underscoring why approval should be paired with limits on what the agent can do. Read the study's abstract and scope.
Workspace trust and configuration controls
Start by deciding which locations count as trusted workspaces. A user or administrator should explicitly designate a repository or folder before the agent treats local instructions there as actionable. Files outside that boundary-including Downloads, temporary folders, and unrelated repositories-should be treated as untrusted input.
Trust should be narrow and visible. Do not make an entire home directory trusted just to avoid repeated prompts. For shared machines, define who can approve a workspace and how that decision is recorded. When a repository changes ownership or is replaced with a fresh clone, require a new trust decision rather than silently inheriting the old one.
Next, separate project guidance from agent configuration. A repository may reasonably tell an agent how to run tests or format code. It should not be able to change the agent's global settings, add an MCP server, alter the model endpoint, or weaken security rules. Keep sensitive configuration in a location the agent cannot rewrite during ordinary tasks. Restrict changes to that configuration to an administrator-controlled process, with a reviewable diff and a separate approval path.
These are different controls: workspace trust decides whether instructions can guide work; configuration protection prevents project content from changing the tool's authority. Both are needed. A trusted project can still contain a dangerous command, and an untrusted file should not gain influence merely because configuration is locked down.
Build Path: Put boundaries around the workflow
A useful implementation starts with the work the agent needs to do, then grants only the access required for that work. Consider a developer asking an agent to fix a failing test in a newly cloned repository.
- Inputs: The agent receives the developer's request, repository files, test output, and project instructions. The workspace is explicitly approved; files elsewhere on the machine remain outside its instruction scope.
- Review and plan: The agent can inspect the repository and propose edits. It can explain which project instructions it followed and flag requests to change agent configuration, add tools, install packages, or contact external services.
- Constrained action: The agent edits files within the approved repository. Package installation and network access are blocked by default or routed through a policy-controlled mechanism. A request to add a package is shown with the package name, source, reason, and expected change before a person approves it.
- Approval or fallback: A reviewer can approve the specific dependency or deny it and ask for an alternative. If the action cannot be evaluated safely, the agent stops and returns the proposed command rather than trying a workaround.
- Outcome: The developer gets a testable patch and a clear record of any elevated action. The team reduces routine review effort without letting project text silently expand the agent's permissions.
Make approval specific to an action, not a blanket "trust this repository forever" decision. Approval for a package install should not authorize an unrelated configuration edit or a new network destination. Show the reviewer the meaningful consequences in plain language, not only a command that requires specialist interpretation.
For package installation, define what is allowed: approved registries, dependency sources, and package-manager commands. Where possible, use a controlled build environment with a lockfile and reproducible dependency process. If a package is not necessary to complete the task, the agent should be able to finish without installing it.
For outbound traffic, use an egress control point such as a proxy or restricted network policy. Permit only the destinations the workflow needs. This limits an agent's ability to send local files or credentials to arbitrary endpoints, even if an instruction asks it to do so. OpenAI describes its approach to sandboxing Codex on Windows as a way to constrain agent access to the surrounding system; the useful design principle for buyers is to enforce boundaries outside the agent's own instructions. OpenAI's sandbox overview provides product-specific context.
Protect credentials as if instructions will fail
Do not rely on an agent to recognize every secret. Keep long-lived login tokens out of repository files, environment dumps, and directories the agent can read without a business need. Use a secrets manager or a narrowly scoped credential broker where the workflow requires authentication.
Give credentials the smallest permissions and shortest useful lifetime. Avoid passing a user's general-purpose login token to an agent that only needs to read a ticket or create a test branch. If a token may have been exposed, revoke or rotate it, review its activity, and check whether dependent integrations need new credentials. Rotation is containment, not prevention; it does not replace limiting what the agent could access in the first place.
Also decide what the agent can put into logs, patches, and support tickets. A successful workflow should not copy secrets into its explanation or commit them into code. Add checks to the review and delivery path so accidental disclosure is caught before a patch is merged.
What to measure before expanding access
Track more than task completion. A rollout dashboard should show how often agents request elevated actions, which requests are denied, how often human reviewers override a warning, and whether the agent attempted access outside the approved workspace. Review unusual outbound requests and configuration changes as operational signals, not just security events.
Test with realistic but controlled cases: an untrusted instruction file asks to install a package, change the agent endpoint, or reveal a credential. The expected result is not merely that the model says no. The system should prevent the action, explain the boundary, and leave enough information for a reviewer to understand what happened.
Keep the test set tied to actual workflows. If an internal assistant only reads code and drafts explanations, it may not need shell access or credentials at all. If an agent runs tests and updates a pull request, define those specific capabilities and their review points. Capabilities that are not necessary create maintenance work without improving the business outcome.
Risks and trade-offs: When to wait
Tighter controls can add friction. A developer may need to approve a legitimate dependency, and a restrictive network policy can break a workflow that expects to fetch resources dynamically. Those costs are manageable when the team knows what the agent needs and has a fast route for requesting justified access.
Wait before enabling autonomous package installation, broad filesystem access, or unrestricted network access if you cannot identify an owner for approvals, an incident contact, and a way to revoke credentials. Also wait if developers have to bypass controls to get ordinary work done. That usually means the boundary is poorly matched to the workflow, not that the answer is to remove it.
Not every coding task needs an agent. For infrequent work, a developer using a conventional editor may be simpler than maintaining a sandbox, approval process, and monitoring. Automation becomes more attractive when tasks repeat, inputs and expected outcomes are clear, and a human can review consequential changes without recreating the whole task.
One non-obvious decision rule: do not ask only, "Can we trust this repository?" Ask, "What is the maximum authority this repository's content can influence?" If the answer includes global settings, credentials, or unrestricted outbound access, trust labels alone are not an adequate control.
What Quellix would build
Quellix's AI agent development work for this problem would start with a review of the coding workflow, tool permissions, configuration paths, and credential flows-not with a new prompt. We would map which instructions the agent reads, which actions it can take, and where a human needs to approve a change.
From there, the implementation could include an explicit workspace-trust flow, protected agent configuration, restricted tool permissions, controlled package and network access, and credential handling matched to the task. We would test representative untrusted-file scenarios, define safe failure behavior, and give operators a compact view of approvals and blocked actions.
The right first step is a technical review of one representative repository and one agent workflow. Bring the tasks developers want to automate, the tools and integrations involved, and any existing approval or sandbox rules. That is enough to decide whether a controlled pilot is worthwhile-or whether read-only assistance is the better starting point.
The part most rollouts need to decide first
The security boundary should match the business task. If you need an agent to suggest code changes, begin with read and edit access inside an approved workspace. Add package installation, external services, or credential use only when a specific workflow requires them and a reviewer can assess the request.
For teams planning a broader agent rollout, AI agent development services can help translate that boundary into a tested workflow. The useful outcome is not an agent that never asks for permission; it is an agent whose permissions are understandable, limited, and operationally manageable.
