Arrakis raises $8M for AI agent runtime security。这轮融资消息比 800 万美元本身更重要的是它把一个过去长期被回避的问题摆到了台面AI Agent 一旦被授权执行真实操作谁能在执行过程中拦住它犯错AI Agent 已经不是单纯聊天。它开始调用工具、读写数据库、访问内部系统、连接外部服务。可问题在于模型输出天然不确定工具调用却是真实发生的外部动作。过去我们说模型安全大多在讨论输出过滤、提示词约束、内容审核。但当 agent 开始操作真实系统安全边界必须从“模型层”下沉到“运行时层”也就是 agent 真正执行工具调用的那一段链路。Arrakis 做的是 AI agent 的 runtime security这次拿到 800 万美元融资说明安全能力在 agent 生产落地中的优先级正在快速提升。这篇文章不只看这轮融资重点拆解 AI Agent 运行时安全到底要防什么、和传统应用安全有什么区别以及作为 agent 开发者有哪些安全手段不需要等产品出来也能立刻落地。1. Arrakis 完成 800 万美元融资AI Agent 运行时安全赛道进入主流1.1 这轮融资值得关注的不是钱而是切入的赛道Arrakis 这轮 800 万美元融资从项目名称到定位都非常明确AI agent runtime security。Arrakis 这个名字源自《沙丘》里的沙漠星球某种意义上也暗示了这个方向的特点——Agent 运行环境本身就是一片充满变量的“沙地”安全产品要做的不是阻止机器运行而是给运行过程划定边界、建立规则、留下痕迹。这个赛道为什么开始被资本关注核心原因很简单AI Agent 的开发模式已经从一个“模型 Prompt”的玩具形态变成一个“模型 工具调用 系统权限 外部网络访问”的生产系统。系统越复杂出问题的可能性越大。过去安全团队只需要保护 Web 接口、数据库、容器编排现在还必须保护 agent 通过自然语言生成的任意工具调用序列。从融资轮次来看这属于早期投资。也就是说这个赛道还非常依赖开发者社区的共识越早把安全机制内建到 agent 开发流程里后面返工成本越低。1.2 Runtime Security 在 Agent 场景中指什么传统意义上的 runtime security常见于 RASP应用运行时自我保护、容器运行时安全、EDR 主机防护。它关注的是程序运行过程中的异常行为、越权操作和恶意负载。对 AI Agent 来说“运行时”指的是一个完整执行闭环用户请求 → LLM 生成回复/工具调用意图 → 工具调用 → 系统操作/外部请求 → 结果回填 → 继续推理这个闭环里有一条关键边界模型输出的“意图”和工具执行的“动作”是分离的。意图可以千变万化动作却有确定性的后果。Runtime security 要做的事情就是把这条边界真正保护起来在“模型决定调用工具”之后“工具真正执行动作”之前插入安全判断层。这条安全层需要覆盖几类能力工具调用是否被允许、参数是否合理、目标地址是否可信、执行过程是否留痕、异常行为能否被及时终止。这些能力共同构成了 AI Agent Runtime Security 的基本盘。2. 为什么 AI Agent 运行时安全突然变成刚需2.1 从“对话生成”到“自主执行”安全假设完全变了传统 LLM 应用的安全假设是模型是核心资产输出是最终产物。安全目标集中在内容侧比如生成内容是否违规、回答是否泄露知识库隐私、是否被提示词注入诱导输出恶意内容。但 AI Agent 改变了这个假设。Agent 的输出不只是一段文本还可能是一个真实动作比如创建订单、发送邮件、修改配置、调用第三方 API。一旦执行动作错误就不只是内容问题而是系统级事故。举例来说一个客服 Agent 如果只负责回答问题提示词注入最坏情况是回答错误信息。但如果这个 Agent 被授权了“查询订单”“创建工单”“修改订单状态”的工具攻击者可以通过恶意构造的上下文或网页内容诱导 Agent 去执行“删除用户订单”“把订单修改为已退款”这类操作。这就是执行层风险和内容层风险的本质区别。2.2 执行链路越长安全空白越多现代 Agent 系统通常具备多步推理和多工具调用能力。执行链路越长攻击面就越大LLM 接收到的输入可能包含不可信外部数据比如网页正文、邮件内容、用户上传文件。模型可能在前置工具返回的结果里被插入恶意指令。Agent 调度器可能根据模型输出把多个工具调用串成一条流水线。工具调用过程需要网络访问、文件读写、数据查询这些动作本身可能被滥用。执行结果回流到上下文又可能影响后续决策形成持续污染。这条链路里任何一环没有安全控制整条链都可能被利用。传统 Web 安全工具保护的是单点入口但 agent 的威胁是跨环节、跨系统的所以需要在运行时层做全局防护。2.3 安全不能只依赖“更好的模型”有一种观点认为模型能力提升之后自然就能识别恶意指令。但从工程角度看这是不够的。模型对语义的判断具有概率性而安全系统需要确定性。提示词注入不是一种固定语法而是不断变化的攻击逻辑。攻击者会用翻译、编码、角色扮演、拼接上下文等方式绕过模型判断。指望模型在所有情况下都抵抗这些攻击等于把所有安全责任都放进一个概率系统里。更稳妥的做法是用模型做能力生成用运行时安全策略做兜底。模型可以判断“这个请求看起来是否正常”安全层负责对“这个工具能不能调、参数合不合规、这个外部地址能不能访问”做确定性裁决。3. AI Agent Runtime Security 的核心防护对象3.1 提示词注入让 Agent 执行非预期指令提示词注入是 Agent 场景最常见的安全问题。攻击者把恶意指令藏在网页内容、文档、邮件、图片 OCR 结果等外部数据中。Agent 读取这些数据后如果直接把它当作指令执行就可能执行攻击者设计的工具调用。运行时安全的第一个防护点就是“识别并拦截注入”对外部数据源的内容做指令性检测。对将要进入工具调用的参数做合法性校验。在工具调用层面对系统操作的敏感度做分级。标准不是“模型判断这句话是不是攻击”而是在执行链路上确保外部不可信数据不能直接触发高权限工具。3.2 工具调用滥用与越权操作Agent 一旦被授予工具权限工具的“能力边界”就成为安全关键。很多 Agent 系统在授权时是粗粒度的只要 Agent 调用了某个工具就认为它有权执行这个工具的全部功能。实际上工具可能包含多个动作每个动作的风险等级不同。比如“订单工具”可能有“查询订单”“修改订单”“删除订单”三个能力从风险角度看完全不是一个级别。运行时安全需要做到功能级或参数级的控制。同时Agent 的越权操作往往不是一次大型攻击而是多次低风险操作的组合。某个 Agent 正常任务需要调用 5 次工具突然在短时间内调用 50 次删除类接口这就应该触发告警或熔断。3.3 上下文污染与数据泄漏Agent 的推理过程中上下文窗口会被逐步填充。攻击者可以通过注入内容污染上下文让 Agent 错误判断自己的权限和任务目标。这种情况在长链路任务中尤其明显前面几步被污染后面所有决策都会被带偏。数据泄漏是另一个容易被忽略的方向。Agent 在工具执行过程中可能读取大量内部数据这些数据会被模型用于生成结果。如果 Agent 又把结果写入外部接口或者通过输出通道返回给不可信用户就会形成数据泄漏。运行时安全需要控制的不只是外部输入还有内部数据的输出方向。3.4 供应链与插件风险现代 Agent 开发大量依赖第三方框架、插件、工具 API。一个插件如果被恶意维护者投毒或者一个工具 API 返回了被污染的数据整个 Agent 都会受到影响。供应链风险在 Agent 场景里比传统应用更放大因为插件不只是代码调用它还可能直接携带“让 Agent 读取用户私密数据”“向外部域名发送请求”这类能力。运行时安全需要能观察 Agent 在运行期的真实行为包括出站网络请求、文件读写路径、进程执行记录然后与声明能力做比对。4. 传统应用安全与 Agent 运行时安全的对比从技术视角来看Agent 运行时安全不是一个全新领域它综合了应用安全、身份安全、数据安全、零信任的思路但实现方式有明显差异对比项传统 Web 应用安全AI Agent 运行时安全攻击输入SQL、Shell 命令、伪造请求参数自然语言提示词、外部网页、文档内容、上下文攻击特征语法固定规则匹配效果较好语义多变无法靠固定签名覆盖执行主体程序代码逻辑确定LLM 生成意图行为有概率性关键保护点网络入口、接口鉴权、数据库操作工具调用、上下文污染、权限边界、出站请求审计难度请求日志即可还原链路需要同时追踪请求、模型输出、工具调用和结果回流安全机制WAF、API 网关、IAM运行时策略引擎、沙箱隔离、语义级校验这个对比说明Agent 安全不能简单套用传统 WAF 或 API 网关。它需要理解 Agent 的执行语义能够在模型、工具、权限、数据之间建立关联。这也解释了为什么“Agent runtime security”会作为一个独立方向被提出来。5. Agent 开发者的运行时安全实践清单无论 Arrakis 这类产品最终怎么落地Agent 开发者在自己的系统里可以先做以下几件事。这些手段不依赖特定厂商属于通用工程实践。5.1 最小权限与人工审批给 Agent 授权工具时遵循最小权限原则。不要给 Agent 一个“全功能工具包”而是按任务拆出最小工具子集。对于删除、退款、转账、批量发送等高风险操作加入人工审批节点。审批节点不需要覆盖所有工具调用只覆盖高影响操作。普通查询可以直接执行高风险写入必须等审批通过后再执行。5.2 输入输出双向过滤与沙箱隔离对 Agent 的输入和输出都要做安全处理。输入侧对外部不可信数据使用隔离标记避免其内容直接作为系统指令参与推理。输出侧对 Agent 准备调用工具的参数做类型、范围、格式校验对将要发送到外部网络的请求做域名和内容检查。如果条件允许把 Agent 执行环境放进沙箱容器限制文件系统可写范围。限制网络出站目标。限制进程创建能力。给每个 Agent 任务分配独立临时目录。沙箱的作用不是彻底免疫而是把风险控制在有限范围内让安全审计有明确边界。5.3 审计日志与监控熔断Agent 的安全审计日志需要覆盖完整闭环用户请求、模型生成内容、工具调用参数、执行结果、出站请求、耗时和 token 消耗。建议按 request_id 串联整条链路方便排查和回溯。监控部分要设置基础规则单任务工具调用次数超过阈值。工具调用连续失败次数异常。出站请求指向非允许域名。高风险工具在短时间被高频调用。单个用户触发了大量敏感操作。这些规则命中后直接熔断而不是只记日志。运行时安全需要能“拦截”而不只是“事后追溯”。5.4 可落地的策略配置示例运行安全模块在工程上通常表现为一个工具调用拦截层。下面是一个通用参考示例需要按实际 Agent 框架和语言调整。# agent_runtime_security.py # 通用参考示例在 Agent 调用工具前插入安全策略层 import json from datetime import timedelta def load_policy(path: str) - dict: with open(path, r, encodingutf-8) as f: return json.load(f) class ToolCallDenied(Exception): pass async def secure_tool_call(tool_name: str, args: dict, context: dict, policy: dict): # 1. 是否在禁用名单 if tool_name in policy.get(blocked_tools, []): raise ToolCallDenied(ftool {tool_name} is blocked) # 2. 是否在允许名单 if tool_name not in policy.get(allowed_tools, []): raise ToolCallDenied(ftool {tool_name} is not in allowlist) # 3. 是否命中需要人工审批的操作 if tool_name in policy.get(require_approval, []): await notifier.send_approval_request( tool_name, args, request_idcontext[request_id] ) approval await approval_gate.wait_for_approval(timeouttimedelta(seconds30)) if not approval.allowed: raise ToolCallDenied(tool call rejected by human approval) # 4. 通过策略校验后执行真实工具调用 result await tool_executor.call(tool_name, args) # 5. 审计日志 auditor.log( request_idcontext[request_id], tool_nametool_name, argssanitize_payload(args), resultsanitize_payload(result), usercontext.get(user), timestampnow(), ) return result对应的策略配置可以单独维护{ agent_id: customer-service-agent, allowed_tools: [ search_kb, get_order_status, create_ticket ], blocked_tools: [ delete_user, transfer_money, drop_database ], require_approval: [ refund_order, send_email_to_user ], max_tool_calls_per_task: 30, outbound_url_allowlist: [ https://api.internal.example.com, https://kb.example.com ] }这套策略配置的核心思路是把“Agent 能做什么”显式写出来而不是依赖 Agent 自己判断边界。配置文件可以纳入 Git 管理随代码评审一起变更也可以定期做权限复核。5.5 审计日志查看示例审计日志的格式建议使用 JSON Lines方便用命令行工具快速检索# 查看审计日志中的工具调用记录通用示例 jq select(.event_typetool_call) | {request_id, tool_name, user, ts} agent_audit.log # 按工具名聚合统计调用次数 jq -r select(.event_typetool_call) | .tool_name agent_audit.log | sort | uniq -c | sort -rn日志不只在出问题时才有用。日常运维中通过统计工具调用频率可以发现 Agent 的“隐性权限膨胀”比如某个任务本来只需要查询实际却频繁触发写入类工具。6. 面向 Agent 安全产品的评估维度如果后续要选型或者参考 Arrakis 这类安全产品建议从下面几个维度去看。每个维度都直接关系到生产环境能否接得住评估维度重点观察说明策略配置能力是否支持代码定义、版本化管理纯 UI 配置很难对接 CI/CD兼容性支持哪些 Agent 框架和 RuntimeLangChain、LangGraph、自研 Runtime 都要考虑安全检测覆盖面是否覆盖提示词注入、工具滥用、数据外发覆盖面越广接入后越少二次开发性能开销对推理延迟和工具调用延迟的影响安全拦截层不能成为 Agent 执行瓶颈审计可观测性日志、Trace、指标是否完整生产排障必须能串联完整请求链路部署形态SDK、Sidecar、网关还是独立平台不同形态对改造量和运维成本影响很大可扩展性是否支持自定义策略和自定义检测规则Agent 场景变化快闭死规则很快失效还有一个比较重要但容易被忽略的维度安全策略本身如何测试。Agent 安全产品应该提供一套测试集或演练环境让开发者可以验证“某种攻击是否能被拦截”。没有验证机制的安全产品很难让人放心接入生产系统。7. 对国内 AI 开发者的建议与合规边界Agent 运行时安全不只是技术问题也涉及授权、隐私和合规边界。开发者在做 Agent 系统时要特别注意以下几类问题。第一Agent 访问的数据要区分来源和敏感级别。内部数据库、个人信息、商业机密在进入 Agent 上下文之前应该先做脱敏和权限校验。不能让 Agent 因为多步推理意外把高敏感数据写入到低权限输出通道。第二Agent 自动执行的操作必须事先获得合法授权。比如自动退款、自动发送邮件、自动修改用户资料、自动发布内容这些操作如果被攻击者利用会产生真实损失。合法授权不单指用户同意的操作还包括企业内部操作权限的授权模型。第三图像、语音、视频、数字人相关的 Agent 能力涉及人脸、声音、版权素材时必须确认素材来源和用户授权。不能把换脸、声音克隆、数字人生成能力直接组装到 Agent 工具包里不设任何边界。第四Agent 的安全测试应该在隔离环境里完成。用真实用户数据、真实业务库做攻击模拟风险很大。建议准备一套完整的最小测试数据集覆盖攻击样例、异常输入和高风险操作路径。第五Agent 的对外服务要设置访问限制。内部 Agent 服务和外部可访问的 API 服务要分域管理避免 Agent 工具接口被外部直接调用绕过安全策略。8. 总结Arrakis 拿到 800 万美元融资最值得开发者关注的信息是AI Agent 运行时安全已经从学术议题变成产品方向。它说明了市场对这个问题的判断——模型安全不等于系统安全Agent 一旦执行真实操作运行时防护就是必选项。对正在开发 Agent 的团队来说现在最应该做的不是等安全产品成熟而是把最小权限、工具审批、审计日志、监控熔断这些通用工程手段先落到自己的 Agent 系统里。配置可以简单但边界必须存在。对这个领域持续关注的人下一步可以重点观察几个方向Agent 与外部工具协议如 MCP 这类工具调用协议的安全规范如何建立Agent 的身份与访问管理如何设计以及跨 Agent 协作时信任链如何验证。这些方向成熟之后Agent 系统才能真正从“能演示”走向“敢上线”。