An attacker submits a pull request containing instructions for an AI coding agent. The agent reads the pull request as context, discovers an MCP tool, and has permission to use a credential that the workflow made available. The code review has quietly become an application-security problem.
The vulnerable unit is not the prompt or the file by itself. It is the complete path:
Untrusted PR → Agent context → MCP tool → Credential → External side effect
That path is the supply chain.
Why the agent belongs in the threat model
Traditional supply-chain reviews focus on packages, build systems, and release credentials. Those remain important. AI coding agents add another moving part: a system that reads content from multiple trust domains and can execute actions on a developer’s behalf.
The agent may read a pull request title, an issue comment, a README, a changelog, or an instruction file. It may also read tool descriptions, configuration, and the output of earlier tools. Some of that content is controlled by the developer. Some of it is controlled by contributors, package authors, or external services.
OpenAI describes prompt injection as a third party misleading an AI system by inserting malicious instructions into its context. In an AI-assisted development loop, an untrusted pull request is one possible injection surface. OpenAI’s prompt-injection overview recommends layered protections, limited access, explicit instructions, and confirmation before consequential actions.
The practical lesson is not to pretend untrusted content can be removed from every workflow. It is to keep untrusted content from silently inheriting the permissions of the person or automation reading it.
Five connected attack surfaces
Pull requests, issues, and repository files
Anything the agent reads can influence the context in which it chooses its next action. A malicious instruction can be hidden in a comment, a README section, a test fixture, or a generated file. The instruction does not need to look like code to affect a model that treats the whole repository as context.
Mark external content as untrusted, separate it from system instructions, and avoid giving the agent broad autonomy over tasks that include attacker-controlled text.
Agent instructions and configuration
Project-local instructions can be useful for conventions and test commands. They can also ask an agent to access files, run commands, or ignore a review boundary. Configuration that enables automatic approval or broad filesystem and network access turns a repository-controlled instruction into a potential capability request.
Review instruction files and runtime policy as security-sensitive configuration. A rule that says “never run deployment commands” is weaker than a runtime that cannot reach deployment credentials or the deployment network.
MCP servers and tool descriptions
MCP standardizes how applications connect language models to external data sources and tools. Its specification describes tools as functions for the model to execute and warns that tools can represent arbitrary code execution. It also calls for user consent, clear authorization flows, and control over data sharing. Read the MCP specification.
That makes tool design part of the supply chain. Pin the servers you use, review their source and tool schemas, allowlist tools per workflow, and prefer narrow typed operations. A generic write primitive is harder to secure than a named operation with a constrained input and a clear audit trail.
Credentials, filesystem, and network access
An injected instruction becomes materially dangerous when the agent can reach something valuable. Limit environment variables, filesystem roots, subprocesses, and outbound network destinations. Use short-lived credentials with the smallest possible scope, and do not make production identities available to a review process that only needs to inspect code.
Sandboxing helps, but it is not the only boundary. A sandbox with a broad network route or a credential that can publish packages still has a large blast radius.
CI workflows and automated side effects
The final link is often in CI. A workflow may trigger on a pull request, check out its contents, start an agent, and give that agent access to a token. The workflow can be syntactically valid while creating a confused-deputy path from an outside contributor to an internal identity.
Require approval for high-impact actions, keep pull-request jobs least-privileged, separate untrusted validation from trusted release steps, and make the boundary visible in logs and review.
Detection is not confirmation
Ordinary scanners are good at finding patterns. They can identify a suspicious tool permission, a dangerous workflow trigger, a secret reference, or an unpinned action. They are less able to answer whether the pattern participates in a real path in this application.
That distinction matters. A presentational component that links to /login is not an authentication handler. A defensive check for the cloud metadata address is not an SSRF request. A headless-browser harness that places document.write inside a string is not necessarily application XSS.
The security question is whether the claimed source reaches the claimed sink under the permissions and controls that actually exist. A finding should carry its evidence: the files and lines read, the pass that made the claim, and the path that was or was not established.
Ship Safe separates the sensor layer from the investigation layer. Deterministic findings remain visible. Evidence-backed verdicts are derived by fixed precedence, and a claim whose citations do not resolve cannot decide the result. The optional Kimi K3 review can provide an advisory second opinion, but it cannot suppress deterministic findings.
Controls that break the path
Current guidance converges on a practical set of controls:
- Treat repository content, pull requests, tool descriptions, and tool results as untrusted input.
- Give agents the minimum data and tools needed for the task.
- Allowlist and pin MCP servers and tool definitions.
- Prefer read-only, named operations over generic shell, SQL, or filesystem primitives.
- Require approval before sending data, changing external systems, deploying, publishing, or modifying permissions.
- Sandbox execution and restrict network egress.
- Use short-lived, narrowly scoped credentials.
- Keep deterministic security findings visible and use AI for explanation and prioritization.
These recommendations are consistent with Google Cloud’s MCP security guidance, Microsoft’s discussion of agents moving from reading to acting, and OWASP’s AI Agent Security Cheat Sheet. OWASP’s Secure Coding with AI Cheat Sheet also treats repository content, MCP servers, agent runtime permissions, CI/CD, and prompt-to-code supply-chain risk as connected surfaces.
A pre-merge review for AI coding agents
Before an agent handles an external pull request, ask:
1. What content can enter the agent’s context without a trusted maintainer editing it?
2. Which instructions are authoritative, and which are merely repository data?
3. What tools can the agent call, and which ones can write or execute?
4. Which credentials, files, and network destinations can those tools reach?
5. What approval gate sits between untrusted input and a consequential action?
6. What evidence will show the reviewer that the path is blocked?
If those answers are not concrete, the agent is part of the supply chain whether the team has documented it or not.
Closing the loop
AI coding agents make software delivery faster. They also make it easier for untrusted text to arrive at a privileged decision point. The answer is not to stop using agents. It is to review the capability path with the same seriousness applied to packages, workflows, and release credentials.
Ship Safe scans code, dependencies, CI workflows, agent configuration, MCP surfaces, and repository content locally. Run an audit to find the sensor findings, then investigate the evidence behind the paths that matter.
For the broader application perspective, read Is Vibe Coding Safe? What AI-Built Apps Need Before They Ship. The central idea is the same: a secure file is not enough if the surrounding path can still reach a dangerous capability.