Your Agent Runs Code You Never Wrote - Why agent isolation is a different problem
好的,用户让我帮忙总结一篇文章的内容,控制在100字以内,而且不需要特定的开头。我先看看文章内容。 文章主要讨论了Cursor、Claude Code、Devin、OpenAI和E2B这几个工具如何隔离代理工作负载。从完全不隔离(比如Cursor直接在shell运行命令)到使用硬件隔离的Firecracker微虚拟机(E2B)。接着提到容器运行时每年都有安全漏洞,而Firecracker七年没有发生过逃逸事件,AWS也认为容器不是安全边界。文章还举了几个真实的安全事件,比如Devin被一个中毒的GitHub问题接管,Slack AI的数据外泄,以及Clinejection供应链攻击。最后提到将探讨六个隔离维度。 现在需要把这些信息浓缩到100字以内。首先确定主要点:不同工具的隔离方法、容器的安全性问题、Firecracker的优势、真实案例和六个维度的探讨。 可能的结构:介绍工具和隔离方式,提到容器的安全问题和Firecracker的表现,然后简要提及案例和后续探讨。 试着组织语言: 分析了Cursor等工具的工作负载隔离方法,从无沙盒到硬件隔离的微虚拟机。指出容器存在安全漏洞,而Firecracker表现优异。举例说明安全事件,并将深入探讨六个隔离维度。 检查字数:大约70字左右,符合要求。 </think> 文章分析了Cursor等工具的工作负载隔离方法,从无沙盒到硬件隔离的微虚拟机,并指出容器存在安全漏洞而Firecracker表现优异。举例说明安全事件,并将深入探讨六个隔离维度。 2026-3-31 05:11:54 Author: www.reddit.com(查看原文) 阅读量:4 收藏

I looked at how Cursor, Claude Code, Devin, OpenAI, and E2B actually isolate agent workloads today. The range goes from literally no sandbox (Cursor runs commands in your shell) to hardware-isolated Firecracker microVMs (E2B).

Container runtimes have had escape CVEs every year since 2019. Firecracker: zero guest-to-host escapes in seven years. AWS themselves said "we do not consider containers a security boundary."

The post covers five assumptions traditional isolation makes that agents break, real incidents (Devin taken over via one poisoned GitHub issue, Slack AI exfiltration, Clinejection supply chain attack), and the six dimensions of isolation I'll be exploring in this series.


文章来源: https://www.reddit.com/r/netsec/comments/1s8ebcc/your_agent_runs_code_you_never_wrote_why_agent/
如有侵权请联系:admin#unsafe.sh