What happens when a coding agent follows a malicious README and the repository has token access?

The agent can run setup commands, read environment files, contact external services, and push changes while staying within its granted permissions. If the environment also exposes a usable token, the README can turn ordinary task execution into unauthorized access or repository modification. The incident is not the text itself, but the sequence of allowed steps that the text triggers.

Why a Malicious README Becomes Dangerous Once an Agent Has Tokens

A coding agent is risky here because it does not just “read” a repository page, it may act on instructions embedded in that page and then execute setup, test, or maintenance steps with real permissions. Once token access is present, those permissions can extend beyond local file access to repository writes, package pulls, issue tracking, or external calls. The security problem is therefore a trust boundary failure between unreviewed content and privileged automation.

OWASP Top 10 for Agentic Applications 2026 captures this class well because agent instruction-following and tool use are the exact behaviours that turn ordinary task execution into a control-risk problem. If the README can influence what the agent runs, then the repository becomes an input channel, not just a codebase. In practice, many teams discover this only after an agent has already consumed repository instructions and exercised an over-scoped token.

How the Abuse Chain Works in Practice

The chain usually starts with a harmless-looking onboarding step: clone the repository, install dependencies, run a setup script, or follow contributor notes. A malicious README can insert commands, URLs, or seemingly normal shell snippets that cause the agent to execute actions the human reviewer did not intend. Because coding agents are designed to make progress, they may treat the instructions as part of the task rather than as untrusted content.

Token access changes the impact materially. If the environment exposes a Git token, cloud token, package token, or similar credential, the agent may be able to authenticate to systems that the README never mentions explicitly. That allows the malicious content to become a pivot into repository modification, secret discovery, dependency tampering, or data exfiltration. The key failure is not that the README is “malicious text” in the abstract. It is that the agent is allowed to combine repository input, shell execution, and authenticated access without a sufficiently strong approval boundary.

Repository instructions can steer the agent toward setup commands that are laterally useful to an attacker.
Environment files and local config may be readable if the agent has file access during routine task execution.
Usable tokens can convert read-only automation into write-capable or externally connected automation.
Any tool that permits network access, package installation, or pushes to the repository expands the blast radius.

CSA MAESTRO agentic AI threat modeling framework is useful here because it frames the problem as a tool-and-authority design issue, not just a prompt issue. This guidance breaks down when the agent can execute arbitrary setup instructions and the token grants real downstream authority.

Where the Edge Cases and Failure Modes Actually Show Up

Tighter agent permissions often increase workflow friction, requiring organisations to balance task automation against the risk of untrusted repository content. The hard part is that the dangerous path may still look like standard developer automation, especially when the repository itself includes legitimate setup commands alongside the malicious ones.

The main edge case is scope mismatch. A repository token that only needs to read issues may still be enough to leak metadata, enumerate private content, or support follow-on abuse if the agent is tricked into using it from an untrusted context. Another edge case is indirect execution: even if the README does not directly contain a payload, it can point the agent toward scripts, package hooks, or external resources that do the real work. Guidance is still emerging on how much autonomy is acceptable in these workflows, so teams should treat repository instructions as untrusted until they are separately verified. OWASP Non-Human Identity Top 10 is relevant when the token itself is the real asset, because the loss of control often starts with weak ownership, overbroad scope, or poor lifecycle controls around machine credentials.

Where this answer becomes incomplete is when the agent can chain repository trust with signed commits, CI secrets, or production deployment credentials, because the consequence then moves from repository abuse into supply-chain compromise.

Risk and Threat Considerations

This scenario creates a combined execution and credential-risk problem. The malicious README is an untrusted instruction source, while the token is a high-value access path. Together they can let an attacker turn routine automation into unauthorized repository changes, secret exposure, dependency tampering, or external service abuse.

Failure mechanism: The agent follows repository content as if it were task guidance, then uses granted tools and tokens to carry out actions that were never separately approved. The abuse works because the environment collapses content trust, execution trust, and credential trust into one workflow.

Impact: The practical outcome can be code modification, exfiltration of environment data, misuse of third-party services, or persistence through altered repository state. In a broader build or deployment chain, the same pattern can also create supply-chain exposure.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	A1 — Prompt Injection and Instruction Hijacking	Malicious README content steers the agent's actions through untrusted instructions.
Recommendation — Treat repository instructions as untrusted input and block agent actions driven by them.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	The issue turns on exposed tokens that grant machine access.
Recommendation — Scope, rotate, and revoke tokens used by automation and agent runtimes.
CIS Controls v8	6 — Access Control Management	Overbroad token permissions let the agent exceed intended repository boundaries.
Recommendation — Enforce least privilege for automation identities and remove unused access.
MITRE ATT&CK	T1059 — Command and Scripting Interpreter	The attack path relies on repository-driven command execution.
	T1552 — Unsecured Credentials	The repository workflow may expose tokens or other credentials to the agent.
Recommendation — Hunt for unreviewed script execution triggered from repository instructions. Detect credential discovery and limit where automation can read secrets.

Practitioner Guidance

What to verify: Teams should verify whether the agent can distinguish repository instructions from trusted operator instructions, and whether any token exposed to the runtime can write, publish, or trigger downstream actions. If the answer is unclear, the environment should be treated as write-capable even when the task is meant to be read-only.

What to prioritise: The first control question is not whether the README is “safe enough”, but whether the agent actually needs authenticated access while processing untrusted repository content. If token use is unnecessary for the task, remove it from the runtime instead of hoping the agent will avoid misuse.

Common mistake: Treating setup automation as low risk because it is “normal developer work” is the error that most often creates exposure. Normality does not matter if the agent can be induced to run the normal steps in a malicious order or against malicious targets.

Practitioner takeaway: Once an agent can read untrusted repository instructions and act with a usable token, the safe assumption is that content can become execution and execution can become access.