Hacker News 中文摘要

RSS订阅

LLMs与编码代理成安全噩梦 -- LLMs and coding agents are a security nightmare

原文链接 | HN讨论 | 2025-08-18 23:05:44

文章摘要

文章指出，大型语言模型（LLMs）和编码代理的广泛应用显著增加了网络安全的攻击面，导致潜在漏洞增多。作者通过参加Black Hat会议，了解到这些技术带来的安全威胁比预期更为严重。网络安全一直是攻防循环，但新技术的引入使得这一挑战更加复杂和严峻。

文章总结

标题：LLM与编码代理：安全噩梦

在2025年8月17日，Gary Marcus发表了一篇题为《LLM + 编码代理 = 安全噩梦》的文章，探讨了大型语言模型（LLM）和编码代理在网络安全领域带来的巨大风险。

Gary Marcus指出，网络安全一直是一场攻防战，从1988年的Morris蠕虫到后来的反病毒软件，攻击者不断寻找漏洞，而防御者则试图修补这些漏洞。然而，LLM和编码代理的出现极大地扩展了攻击面，带来了前所未有的安全挑战。

LLM的不可靠性已经广为人知，尤其是在生成代码时，LLM可能会出现“幻觉”，生成错误的代码。更严重的是，LLM容易受到“提示注入”攻击，攻击者可以通过精心设计的输入让LLM执行开发者未预期的操作。例如，曾有攻击者通过提示注入让一个汽车经销商聊天机器人以1美元的价格出售一辆2024款雪佛兰Tahoe。

随着“代理”技术的兴起，问题变得更加复杂。这些代理可以代表用户执行各种任务，如交易、预订旅行、编写甚至修复代码等。然而，代理的权限越大，潜在的安全风险也越高。特别是在软件开发领域，编码代理通常被授予广泛的权限，这为攻击者提供了可乘之机。

在Black Hat大会上，Nvidia的研究人员Rebecca Lynch和Rich Harang展示了如何通过提示注入攻击编码代理。他们指出，LLM编码代理可以访问GitHub等公共资源，攻击者可以在这些平台上留下恶意指令，诱使编码代理在开发者的系统上执行恶意操作。例如，攻击者可以在GitHub仓库中隐藏恶意提示，当开发者下载该仓库并让代理执行操作时，恶意指令就会被执行。

此外，攻击者还可以通过“水坑攻击”在开发者常用的工具或文件中植入恶意代码。Nvidia的研究人员展示了如何利用ASCII隐藏技术将恶意代码嵌入到看似无害的文件中，这些代码对用户不可见，但会被LLM解析并执行。

Gary Marcus特别提到，当编码代理在“自动运行模式”下工作时，风险尤为严重。在这种模式下，代理可以在不经过用户确认的情况下执行命令和写入文件，这为攻击者提供了极大的便利。

Nathan Hamiel，Kudelski Security的高级研究总监，也对此表示担忧。他提出了“RRT”策略（Refrain, Restrict, Trap），建议在高风险场景中避免使用LLM，限制系统的执行权限，并监控系统的输入输出以防止攻击。

尽管Nathan和Nils Amiet在Black Hat大会上展示了如何通过攻击开发者工具来获取系统权限，但他们也指出，许多漏洞可以通过修补来修复。然而，由于攻击方式的多样性和开发者对AI工具的依赖，完全消除这些风险几乎是不可能的。

文章最后建议，开发者应谨慎使用编码代理，减少其自主性，并增加额外的安全防护措施。然而，正如Gary Marcus所言，LLM和编码代理的安全问题仍然是一个巨大的挑战，未来可能会带来更多的安全噩梦。

评论总结

  1. AI编写安全代码的可行性

    • 支持者认为，AI可以编写安全代码，类似于经验不足的初级开发者也能做到。
    • 引用："It is more than possible to write secure code with AI, just as it is more than possible to write secure code with inexperienced junior devs."
    • 引用："I think of it more like self driving cars. I expect the error rate to quickly become lower than humans."

  2. AI的安全风险与限制

    • 批评者指出，AI在安全关键场景中的使用应受到限制，建议采用“RRT”（Refrain, Restrict, Trap）策略。
    • 引用："Refrain from using LLMs in high-risk or safety-critical scenarios. Restrict the execution, permissions, and levels of access."
    • 引用："Most of these attacks succeed because app developers either don’t trust role boundaries or don’t understand them."

  3. 开发者行为与安全漏洞

    • 有评论认为，开发者匆忙或不经验证地接受代码更改是安全漏洞的主要原因，而非AI本身。
    • 引用："Is the argument that developers who are less experience/in a hurry, will just accept whatever they’re handed?"
    • 引用："If they cared tho, the attack vectors would collapse."

  4. 本地化与权限控制

    • 本地化LLM的使用被认为是一种更安全的选择，但仍需配合严格的权限控制。
    • 引用："Using a local LLM isn’t a surefire solution unless you also restrict the app’s permissions."
    • 引用："The biggest concern to me is that most public-facing LLM integrations follow product roadmaps that often focus in shipping more capable, more usable versions of the tool."

  5. AI安全性的未来展望

    • 部分评论对AI安全性的未来持乐观态度，认为随着技术进步，AI将变得更可靠。
    • 引用："It’ll get better over time. Or, at least, it should."
    • 引用："Maybe in a couple of years we’ll consider it irresponsible not to write security and safety critical code with frontier LLMs."