Your Coding Agent Is a New Attack Surface and Most Devs Aren’t Ready for It

你的编程智能体是一个新的攻击面，而大多数开发者对此毫无准备

When Your AI Assistant Gets Hijacked Mid-Flight 当你的 AI 助手在运行中被劫持时

If you’ve handed your coding agent an automated task and walked away, this story should make you a little uncomfortable. A developer recently shared an account of their coding agent nearly being taken over by a prompt injection attack — encountered during an automated task, not in a controlled test environment. The injected prompt attempted to override the agent’s original instructions and redirect its behavior. In other words: someone (or something) in the environment tried to tell the agent to do something entirely different than what the developer asked. And it nearly worked. 如果你曾将自动化任务交给编程智能体后就走开了，那么这个故事会让你感到不安。一位开发者最近分享了他们的经历：其编程智能体在执行自动化任务时，差点被提示词注入（prompt injection）攻击所接管，而且这并非发生在受控的测试环境中，而是实际任务中。注入的提示词试图覆盖智能体的原始指令并重定向其行为。换句话说：环境中的某个人（或某种东西）试图指挥智能体去做与开发者要求完全不同的事情。而且，它差点就成功了。

This Isn’t New — But the Stakes Just Got Higher 这并非新鲜事——但风险等级已经升级

Prompt injection has been a known issue since large language models started being used in anything resembling a pipeline. The concept is simple and old: if you can get malicious instructions into the input stream of a system that treats instructions and data interchangeably, you can hijack it. We saw this with SQL injection, with XSS, with template injection. The pattern is ancient. What’s new is the target. Simple chatbots getting prompt-injected is embarrassing. A coding agent getting prompt-injected is potentially catastrophic. 自从大语言模型开始被用于任何类似流水线的场景以来，提示词注入就是一个已知问题。这个概念既简单又古老：如果你能将恶意指令注入到一个将指令和数据混为一谈的系统的输入流中，你就能劫持它。我们曾在 SQL 注入、XSS 和模板注入中见过这种情况。这种模式由来已久，但这次的目标变了。简单的聊天机器人被注入提示词顶多是令人尴尬，而编程智能体被注入提示词则可能是灾难性的。

Agents have tools. They write and execute code, interact with filesystems, make API calls, and increasingly operate with minimal human supervision. The blast radius is not “it says something embarrassing.” The blast radius is “it writes a backdoor, exfiltrates credentials, or commits malicious code to your repository.” That’s a fundamentally different risk profile than what most people are mentally modeling when they integrate an AI coding assistant into their workflow. 智能体拥有工具。它们编写并执行代码、与文件系统交互、进行 API 调用，并且越来越多地在极少人工监督的情况下运行。其影响范围不再是“它说了些尴尬的话”，而是“它编写了后门、窃取了凭据，或向你的代码库提交了恶意代码”。这与大多数人在将 AI 编程助手集成到工作流时所预想的风险模型有着本质的区别。

What’s Being Overstated — and What Isn’t 什么是被夸大的——什么不是

The hype machine tends to frame prompt injection in one of two ways: either it’s a fringe edge case that only affects careless implementors, or it’s an unsolvable existential flaw in LLM architecture. Both are wrong, and both serve specific interests. Vendors building agents want you to believe guardrails are basically solved, that their systems are robust, and that this is a niche research problem. It isn’t. This was a real developer, a real task, a real near-miss. On the other side, the doom crowd wants you to think there’s no safe path forward with agentic AI. That’s also overblown — but the responsible middle ground requires actually grappling with the attack surface, which most teams aren’t doing yet. 炒作机器倾向于将提示词注入归为两类：要么认为这只是影响粗心开发者的边缘案例，要么认为这是 LLM 架构中无法解决的生存缺陷。两者都错了，且都服务于特定的利益。构建智能体的厂商希望你相信护栏机制已基本解决，系统非常稳健，这只是一个细分的研究问题。事实并非如此。这是一个真实的开发者、真实的任务、真实的险情。另一方面，末日论者希望你认为智能体 AI 没有安全的发展路径。这也是夸大其词——但负责任的中间立场要求我们真正去应对攻击面，而大多数团队目前还没做到这一点。

What is being understated: how poorly the industry has thought through the trust model for agents operating in untrusted environments. When your agent browses the web, reads a codebase, or processes third-party data as part of a task, every one of those inputs is a potential injection vector. The agent can’t reliably distinguish between “data I should process” and “instructions I should follow” — because the model itself doesn’t have a hardened boundary there by design. 被低估的是：业界对于智能体在不可信环境中运行的信任模型思考得有多么不足。当你的智能体浏览网页、读取代码库或处理第三方数据作为任务的一部分时，每一个输入都是潜在的注入向量。智能体无法可靠地分辨“我应该处理的数据”和“我应该遵循的指令”——因为模型本身在设计上就没有硬性的边界。

What This Means for You 这对你意味着什么

If you’re a developer using coding agents, the uncomfortable truth is that you’re in the trust-but-verify phase of a technology that was not designed with adversarial inputs in mind. Some concrete implications: 如果你是一名使用编程智能体的开发者，一个令人不安的事实是：你正处于一项技术的“信任但要验证”阶段，而这项技术在设计之初并未考虑过对抗性输入。以下是一些具体的启示：

• Automated tasks with reduced human oversight are the highest risk scenario. This attack nearly succeeded precisely because the agent was operating mid-task. Eyes-on matters. 人工监督减少的自动化任务是风险最高的场景。 这次攻击之所以差点成功，正是因为智能体在任务执行过程中处于无人值守状态。人工监控至关重要。
• The inputs your agent consumes are part of your attack surface. Treat external data sources with the same suspicion you’d treat user input in a web app — because that’s exactly what they are. 智能体消耗的输入是你攻击面的一部分。 对待外部数据源要像对待 Web 应用中的用户输入一样保持怀疑——因为它们本质上就是用户输入。
• Minimal privilege matters. If your agent has write access to your repo, production credentials, and the ability to run arbitrary code, a successful injection isn’t a minor incident. 最小权限原则很重要。 如果你的智能体拥有代码库的写入权限、生产环境凭据，以及运行任意代码的能力，那么一次成功的注入绝非小事。

Security teams largely haven’t caught up. Most appsec programs have no framework for evaluating agentic AI deployments. That gap is going to cause real incidents before it gets addressed. For the broader industry, this story is a data point in what I suspect will become a much louder conversation over the next 12-18 months: who is responsible when an agent gets hijacked and does something harmful? The developer who deployed it? The platform that built it? The model provider? Nobody has a clean answer yet. 安全团队在很大程度上还没跟上节奏。大多数应用安全（AppSec）项目还没有评估智能体 AI 部署的框架。在这一问题得到解决之前，这种差距将导致真实的事故发生。对于整个行业而言，这个故事是一个数据点，预示着未来 12-18 个月内将出现更激烈的讨论：当智能体被劫持并造成损害时，谁该负责？是部署它的开发者？构建它的平台？还是模型提供商？目前还没有明确的答案。

The Open Question 悬而未决的问题

Agentic AI is being adopted faster than the security community can reason about it. One near-miss by a developer paying attention is useful signal — but how many of these are happening silently, in automated pipelines that nobody reviews, with consequences that either go unnoticed or get quietly rolled back? How are you actually vetting the inputs your agents consume before they act on them? 智能体 AI 的采用速度超过了安全社区对其进行分析的速度。一位细心的开发者发现的一次险情是一个有用的信号——但有多少此类事件正在无人审查的自动化流水线中悄然发生，且后果要么未被察觉，要么被悄悄回滚？在智能体采取行动之前，你究竟是如何审查它们所消耗的输入的？