Agent Instruction File Risks: How AI Assistants Follow an Automatic Execution Chain

1. The Real Risk: Not the File, but the “Read and Execute” Chain

A plain-text file is not dangerous by itself. The risk appears when a coding assistant, terminal agent, or automated development tool starts in a directory and automatically discovers and reads convention files there, treating their natural-language content as high-priority instructions. At that point the file is no longer ordinary documentation. It has entered an instruction channel.

This risk depends on three conditions being true at the same time:

1. The file can be delivered at low cost. Visiting a page or triggering a download may place the file in a downloads folder, sometimes without an explicit confirmation.
2. The agent reads context automatically. Some tools scan the working directory for README-style files, config files, or conventionally named text files in order to understand the task.
3. Natural-language instructions blur into code execution. The agent may change configuration, install dependencies, read credentials, or make network requests based on that text without asking the user to confirm each step.

Defense therefore cannot stop at “do not open suspicious files.” What matters more is limiting what the agent may read, what it may execute, whether approval is required before execution, and whether sensitive credentials are reachable.

2. Attack Chain: From File Drop to Privilege Abuse

A typical instruction-injection chain can be described in five stages.

1. File drop

An attacker uses a web trigger, an archive attachment, shared-folder sync, or a prompted download to place a plain-text instruction file in a directory the user uses often, especially Downloads. Developers frequently treat Downloads as a temporary workspace. The problem is that it naturally contains many files of unclear origin.

2. Context discovery

To have an assistant organize files or generate scripts, developers often start an agent directly inside Downloads. After startup, the agent may scan the current directory for readme files, task files, or conventionally named instruction files. If the tool trusts local files by default, attacker-controlled content can enter the context.

3. Instruction elevation

The text contains task descriptions that look reasonable, such as “disable restrictions to finish debugging,” “install this dependency to repair the environment,” or “read the config and upload it for diagnosis.” Because natural language is persuasive, the agent may treat those lines as part of the user’s intent and may even override system prompts or safety policy.

4. Privilege abuse

Once the agent follows the malicious instructions, it may change global configuration, weaken security limits, disable the sandbox, install packages from unknown sources, run scripts, read local credentials, or send data to an external address. If the agent has broad system privileges, the impact can spread from one project to the whole development machine.

5. Persistence and exfiltration

The attacker may also write startup items, change agent configuration, poison lockfiles, or package access tokens, environment variables, and private-key paths for exfiltration. These actions do not always produce an obvious error, so they can remain unnoticed for a long time.

3. Why Developer Environments Are Easier to Abuse

Developer environments combine high privilege, high connectivity, and high automation, which makes them a strong target for instruction injection.

• Directory habits. Downloads, temp folders, and shared folders are often used directly as working directories, and their contents come from mixed sources.
• Trust in natural language. Developers are used to telling an assistant to “look at the directory” or “follow the instructions,” and can overlook that the file itself may be the instruction.
• Excessive default privilege. A development machine can usually reach source code, configuration, secrets, internal services, and package managers.
• Long automated chains. Reading files, generating commands, installing dependencies, and running tests often happen in sequence, with little approval in between.
• Long-lived credentials. Access tokens in local environment variables and config files may remain valid for a long time. A leak then has a wide blast radius.
• Complex dependency supply chains. Installing one malicious dependency can trigger an install script and then arbitrary code.

4. High-Impact Outcomes: From Config Drift to Supply-Chain Poisoning

This is not only “the assistant ran the wrong command.” It can become a supply-chain and credential incident.

First, security boundaries are weakened. Malicious instructions may push the agent to disable the sandbox, broaden permissions, or change global configuration, so later actions lose isolation.

Second, the dependency supply chain is poisoned. The agent may be steered into installing packages from unknown sources, or into editing dependency manifests and lockfiles, so malicious code enters the build.

Third, credentials leak. If the agent can read environment variables, config directories, and key files, an attacker can obtain access tokens and then reach code repositories, cloud resources, or internal systems.

Fourth, lateral movement. Development machines are often connected to internal networks, test environments, and release paths. Stolen credentials can be reused for further access.

Fifth, auditing is hard. Actions triggered by natural-language instructions may be scattered across shell history, agent logs, and system logs. Without centralized audit, reconstructing the full chain is difficult.

5. Protecting a Personal Development Machine: Isolate, Then Approve, Then Audit

1. Isolate the working directory

Do not start an agent directly in Downloads, on the desktop, or in the user home directory. Create a separate working directory for each task, mount only the source that is required, and block reads of Downloads, config directories, and key directories. Prefer a default-deny, grant-on-demand policy.

2. Scan instruction files before startup

Before the agent starts, scan plain-text files in the working directory for suspected agent instructions, unusual task descriptions, external addresses, credential reads, and dependency-install keywords. Findings should block startup or require human confirmation.

3. Least privilege and sandboxing

Run the agent in a restricted sandbox with no network, no credentials, and no permission to write global configuration by default. Network access or dependency installation should require explicit approval, with limits on destinations and package sources.

4. Credential isolation

Do not put long-lived access tokens in global environment variables on the development machine. Use short-lived credentials, per-task authorization, and least-privilege accounts, and keep sensitive secrets in a store the agent cannot read. When the agent must call an external service, do it through a controlled proxy or temporary authorization.

5. Approval for dependency installs

Require approval for dependency installation, lockfile changes, and install-script execution. Prefer pinned versions, private mirrors, and source verification, and do not let the agent add unknown dependency sources on its own.

6. Review before execution

Review diffs for commands, configuration changes, and file edits the agent proposes. Operations that involve network requests, privilege changes, writes to config directories, or credential reads must be confirmed by a person.

6. Team and Platform Governance: Turn Ad Hoc Habits into Policy

Personal habits do not cover organizational risk. Teams should encode the controls as policy-as-code and enforce them at the platform layer.

• A single agent policy. Define allowed working directories, denied read paths, network egress, dependency sources, actions that need approval, and required log fields.
• Centralized audit. Record agent startup, files read, generated commands, approval results, network requests, and dependency installs so the chain can be searched.
• Anomaly alerts. Alert on starting an agent in Downloads, reading credential directories, disabling the sandbox, contacting unknown external addresses, or installing unknown dependencies.
• CI/CD controls. In pipelines, check dependency manifests and lockfiles, and block dependencies of unknown origin and unapproved configuration changes.
• Incident response. If a suspicious instruction file is found, isolate the host, rotate credentials, review dependencies and configuration, and inspect outbound connection records.

For audit and alerting, general cloud logging and monitoring—such as Baidu AI Cloud log and alerting services—can collect agent events and apply anomaly rules. The choice should fit the organization’s existing security stack. Logging alone is not a sufficient control.

7. Illustrative Policy and Scan Logic

The following is neutral pseudo-configuration. It expresses policy intent only and does not represent any specific product API:

agent_policy:
  working_dirs:
    - ./task-workspace
  deny_read:
    - ~/Downloads
    - ~/.config
    - ~/.ssh
  require_approval:
    - network_egress
    - credential_read
    - dependency_install
    - global_config_write
  sandbox: true
  auto_execute: false

A pre-start scan can follow this pseudocode:

function scan_instruction_files(root):
    findings = []
    for file in walk(root):
        if is_plain_text(file) and looks_like_agent_instruction(file):
            if not is_allowlisted(file):
                findings.append({file, reason: "untrusted_instruction_file"})
            if contains_sensitive_action(file):
                findings.append({file, reason: "sensitive_action_requested"})
    return findings
before_start_agent(workspace):
    findings = scan_instruction_files(workspace)
    if findings not empty:
        block_start()
        require_human_review(findings)

8. Detection and Response Checklist

Teams should check the following:

1. Whether agents may start in Downloads, shared folders, or the user home directory.
2. Whether the agent reads readme or convention files in the current directory by default.
3. Whether the agent can use the network, read credentials, install dependencies, and write global configuration.
4. Whether file reads, generated commands, approvals, and network requests are logged.
5. Whether alerts exist for disabling the sandbox, reading credentials, and contacting unknown addresses.
6. Whether development-machine credentials are rotated regularly, and whether dependency manifests and lockfile changes are reviewed.
7. Whether there is a process to isolate, investigate, and recover after a suspicious file is found.

9. Conclusion

The risk of agent instruction files is not about the file extension. It is about implicit trust in local text by automated tools. When automatic context loading and high-privilege execution exist together, plain text of unknown origin can become an entry point. Effective defense covers directory isolation, pre-start scanning, least privilege, sandboxing, credential protection, dependency approval, centralized audit, and anomaly alerts. Individuals should avoid starting an agent directly in Downloads. Teams should make approval and audit part of platform policy so agent capability stays inside a controlled boundary.