Arcjet Agent 运行时安全将控制引入 AI 行动循环

Arcjet 于 9 月 17 日推出 agent runtime security，为进入生产环境后的 AI 代理增加实时控制。该产品瞄准了监控代理与阻止其下一步行动之间的空白。当代理能够发送消息、更新数据库、发起退款或调用内部工具时，这一区别尤为重要。

Arcjet agent runtime security 的发布正值安全厂商竞相争夺这一新执行层的控制权。网关负责检查流量，身份系统验证行为主体，可观测性平台记录活动。Arcjet 则希望将策略检查置于应用程序路径之中，使代理拟议的行动仍有机会被阻止。

这种架构让开发者能够为每项决策获得更多上下文。但它也要求开发者在具有实质后果的行动周围部署执行代码。Arcjet 的核心判断是，组织会接受这种集成工作，因为外部控制无法看到足够多的应用程序细节。

该产品结合了代理发现、行动级强制执行和审计记录。Arcjet 表示，团队可以通过现有遥测数据观察代理，随后借助软件开发工具包和框架集成加入预防性检查。

因此，这次发布并非又一次泛泛而谈的模型安全承诺。它试图界定：当模型输出转化为真实操作时，责任从何处开始。

Arcjet Agent 运行时安全增加三层控制

Arcjet 将可见性、预防和证据整合到同一生产工作流中。

第一层是观察。Arcjet 表示，组织可以通过 OpenTelemetry 传送代理活动；OpenTelemetry 是一项用于收集追踪、指标和日志的开放标准。使用 Claude 的团队还可以通过 Anthropic 的 Compliance API 进行连接。

这一接入流程会建立代理和应用程序清单。随后，Arcjet 会将单个会话与生成它们的代理关联起来。安全调查人员可以审查一条更长的工作流，而不必在彼此割裂的提示词和工具调用中搜索。

这种方法部分依赖于标准化遥测技术日益普及。OpenTelemetry 项目一直在开发用于报告代理任务、框架活动和模型交互的 代理可观测性 规范。

这种标准化能够减少在不同框架中发现代理所需的工作量。然而，仅靠观察无法阻止不安全操作。它只能记录发生过什么，并为后续分析提供上下文。

第二层是强制执行。Arcjet 在代理调用工具、数据库、应用程序编程接口或模型之前放置策略决策。应用程序会收到诸如允许、阻止、脱敏或暂缓审核等类型化响应。

类型化响应是一种可由应用程序代码一致处理的结构化结果。它让工作流能够停止行动、请求人工批准，或向代理返回解释。

Arcjet 还支持调用后的检查。这些检查可以在另一工作流步骤使用结果之前对其进行审查。由此，系统既能控制拟议行动，也能控制其返回的信息。

据该公司称，现有策略涵盖提示词注入、敏感数据暴露、自动化滥用、速率限制和资源配额。提示词注入是指不受信任的内容操纵模型，使其遵循恶意或非预期指令。

第三层是审计。Arcjet 会记录决策、策略版本、行为主体、输入以及相关运行上下文。该记录旨在展示代理尝试了什么，以及系统为何允许或拒绝该行动。

该公司修正后的发布公告将产品概括为三项功能：观察、执行和审计。公告称，策略可以在涉及模型、工具、数据库和 API 的调用前后运行。

这一设计解决了一个具体的运营问题。客服代理可能读取一封电子邮件、查询客户数据库并准备回复。单独审查时，每一步看起来都可能无害。

但组合起来的步骤仍可能将个人信息暴露给攻击者添加的地址。Arcjet 试图保留此前的步骤，并在这一历史背景下评估外发消息。

创始人兼首席执行官 David Mytton 向 SiliconANGLE 表示，风险结果可能由一连串各自看似合理的行动逐渐形成。最初的发布报道还提到，该产品已与多个主要代理框架集成。

这些集成包括 Claude Agent SDK、OpenAI Agents SDK、LangChain、Mastra 和 Microsoft 的 Agent Framework。Arcjet 更广泛的产品页面宣称支持 20 个 SDK 和框架集成。

这一覆盖范围之所以重要，是因为代理部署很少采用统一的运行时。组织可能拥有通过不同接口运行的网页代理、队列工作器、编程助手和定时工作流。

Arcjet 的产品试图通过共享决策模型连接这些环境。最重要的变化并非代理清单界面，而是在行动执行前加入强制性决策的能力。

安全边界正从访问转向行动

已通过身份验证的代理仍可能凭借有效凭据采取错误行动。

传统访问控制关注的是某个身份是否可以进入系统。这仍然是必要的，但当软件能够自主理解目标并选择行动时，它已不再充分。

员工可能授权某个代理使用客户服务平台。但这一权限并不自动意味着该代理应为遇到的每笔交易退款。允许的金额、账户、支付方式以及周边请求仍然重要。

同样的问题也出现在编程工作流中。编程代理可能拥有合法的代码库访问权限，却没有暴露机密、修改部署设置或运行破坏性命令的授权。

长期访问权限划定了外部边界。但它无法确认边界内的每项行动都反映用户当前的意图。

Google 在其 2026 年Beyond Zero 框架中描述了类似转变。该提案在特定资源上的单项行动层面评估授权，而不是授予广泛的应用程序访问权限。

Arcjet 正在追求这一方向中更聚焦且可部署的版本。它利用应用程序内部可获得的上下文检查行动。这些上下文可能包括身份、路由、工具名称、类型化参数、此前步骤和累计使用量。

设想一个能够访问企业资源规划系统的应付账款代理。读取发票和发放付款都发生在同一应用程序中，但二者的后果截然不同。

网络网关或许能够识别流量正流向该应用程序，却未必理解底层功能是在读取供应商记录，还是在修改银行信息。

代码内检查可以审视函数及其参数。它可以对读取发票应用一种策略，对发放资金应用另一种策略。

这一区别解释了 Arcjet 相对于外部控制平面的定位。网关可以集中管理模型路由、身份验证、日志记录和内容检查。Arcjet 认为，当强制执行移至执行行动的代码之外时，系统会失去部分应用程序上下文。

这两种方法并非相互排斥。公司可以使用网关管理模型流量，同时使用 Arcjet 控制特定工具调用。关键问题在于，哪一种控制机制拥有最终决策权。

Arcjet 表示，本地决策增加的开销不足一毫秒；当决策需要其云服务时，耗时则在 20 至 30 毫秒之间。

这些数字属于公司说法，并非独立基准测试结果。它们也不包括更重型的检查。Arcjet 表示，其专门的提示词注入检测在服务商调用前可能增加约 100 毫秒。

当一次代理运行包含数十项行动时，延迟就变得重要。即使是很小的延迟也可能累积，尤其是在远程策略评估或基于模型的检测反复出现时。

因此，这种架构带来了策略部署位置的问题。团队必须决定哪些行动需要本地规则、远程检查、内容分析或人工审核。

只读查询可能仅需授权和日志记录。高价值退款则可能值得采用多项控制并进行人工批准。若对每项行动都施加最严格的流程，工作流将变慢，运营摩擦也会增加。

Arcjet 的答案是细粒度强制执行。工程团队可以将规则保留在受保护处理程序附近，而安全团队能够在无需再次部署应用程序的情况下管理远程策略。

基于代码的规则支持测试、审查和版本控制。远程规则则让安全人员能够跨服务调整阈值。两者结合既能保留工程所有权，也能让安全团队更快介入。

但这也可能引入治理问题。应用程序可能包含一项策略，而远程服务实施另一项策略。团队需要明确优先级、变更历史和故障处理行为。

如果云端策略服务不可用，应用程序必须决定是阻止还是继续。这一决定取决于行动后果及组织对中断的容忍度。

该产品让行动边界变得可见，但并未消除这些设计选择。它为团队提供了将这些选择编码化的位置。

代码内强制执行挑战网关和安全仪表盘

主要竞争发生在能够中断行动的控制机制，与主要观察其周边流量的系统之间。

安全仪表盘可以在遥测数据到达后识别异常行为。这对于调查、事件响应和合规仍然有用，但未必能够阻止已经完成的退款或数据库更新。

AI 网关可以在模型请求或响应经过时采取行动。它们能够检测恶意内容、限制服务商，或在集中节点施加支出限额。

然而，代理的实质性操作可能发生在模型交互之后。模型提出工具调用，而应用程序代码将其对另一系统执行。只看到模型流量的网关可能会遗漏最终操作。

Arcjet 将防护置于该执行路径之内。应用程序会在调用相关函数前立即请求策略决策。这样，策略便可检查类型化参数，而非从自然语言中推断意图。

网络层面上，一笔金额不大的退款与一笔金额大得多的退款可能看起来相似。应用程序处理程序则清楚准确的金额、账户、货币和用户上下文。

代价是部署范围。集中式网关一旦将流量路由经过其中，就可以覆盖许多应用程序。代码内控制则必须插入开发者识别出的边界中。

Arcjet 试图通过 SDK、钩子和框架集成减轻这一负担。该公司还表示，它支持通过 OpenTelemetry 进行观察，无需修改应用程序。

然而，发现与执行并不是一回事。遥测可以揭示未知 agent 的存在，却不会自动在该 agent 的每一项操作前设置拦截控制。

这种区别决定了采用顺序。平台团队可以先盘点 agent 活动，随后由开发者选择高后果操作并在其周围添加防护。

这一顺序切实可行，但覆盖范围仍可能不均衡。一个服务可能保护退款操作，另一个服务却未对账户变更设置防护。安全团队需要证据来显示哪些操作缺乏执行控制。

大型厂商正在争夺重叠领域。Cisco 于 2026 年 2 月扩展了 AI Defense，增加了针对 agent 工具使用的运行时保护与交互治理功能。其 AI Defense 扩展强调覆盖网络、云和本地环境的防护。

Cisco 的方法受益于既有的企业安全业务版图。Arcjet 的主张则聚焦于应用原生集成与开发者采用。

其他产品侧重于模型防火墙、AI 红队测试、身份、网关路由或可观测性。随着厂商沿着 agent 活动从提示词追踪到工具执行，这些类别之间的边界正日益重叠。

因此，Arcjet 必须证明操作级上下文能够带来更好的决策，而不只是产生更多日志。买方会希望看到证据，证明策略既能拦截有实质影响的攻击，又不会干扰正当工作。

该公司当前的示例很直观，包括退款限额、未经授权的工具调用、敏感数据脱敏、失控循环和危险操作序列。

更困难的情况涉及意图模糊。策略可以轻松拒绝某个角色无权使用的工具；但要判断一次被允许的工具调用是否符合用户表述不清的目标，则困难得多。

当组织能够表达清晰规则时，确定性策略会有所帮助。确定性策略会针对相同的已知输入返回相同结果，而不是依赖开放式的模型判断。

规则可以限制支出、约束资源、要求审批，或拦截特定数据类别。当上下文取决于细致的业务含义时，这些规则的判断力就会减弱。

这一局限并不意味着运行时执行没有必要。它界定了确定性控制的边界，以及基于推理的治理从何处开始。

Arcjet 的产品目前强调可靠的执行底线。更丰富的序列分析可以建立在这一基础上，但仍需要一种能够阻止最终操作的机制。

这是该公司论点中最有力的部分。当应用无法在执行前落实决策时，更好的检测所能提供的保护有限。

较弱的部分则是运营证明。Arcjet 尚未发布广泛的第三方数据，展示本次发布的误报率、客户采用情况或事件减少效果。

在这些结果出现之前，买方必须将性能与有效性数据视为厂商主张。试点部署应先让策略以观察模式运行，再启用拦截行为。

提示词注入只是运行时问题的一部分

提示词过滤无法取代授权、最小权限、预算或审批控制。

提示词注入之所以受到关注，是因为攻击者可以将指令隐藏在电子邮件、文档、网站或工具输出中。agent 可能将这些不可信内容视为指引，并改变其行为。

过滤可以在内容到达模型前识别部分恶意模式，但无法可靠判断由此产生的每一项业务操作是否已获授权。

格式正确的请求仍可能超出用户权限。被入侵的账户可能发送看似无害的指令。agent 也可能在未遭遇攻击的情况下发生错误。

因此，运行时安全必须将内容评估与操作授权分开。一项检查询问输入是否显得具有敌意；另一项检查询问该主体是否可以对该资源执行这项操作。

OWASP 关于过度自主性的指导建议尽量减少扩展、权限和自主权，同时建议在高影响操作前进行人工审批。

Arcjet 可以为其中一部分控制提供执行点，但无法决定组织的风险承受能力，也无法重新设计持有过宽凭证的 agent。

拥有不必要数据库权限的 agent 仍然危险。拦截策略可以降低暴露面，但最小权限原则应首先阻止 agent 接触大量敏感操作。

人工审批同样需要谨慎实施。确认界面应展示实际工具、目标地址、参数和后果。要求用户批准由 agent 撰写的摘要，可能掩盖危险细节。

根据其产品材料，Arcjet 会返回“暂缓审核”决策。周边应用仍控制该审核如何呈现，以及由谁批准。

审计记录会带来另一组问题。提示词和工具参数可能包含个人信息、凭证、内部文档或客户数据。

Arcjet 表示，敏感检查可在本地运行，而决策证据则单独存储。它提供通过其云服务、单租户环境、私有虚拟云或客户自行管理的基础设施进行存储的选项。

组织应核实哪些字段会离开其环境，还应定义保留期限、区域存储、访问控制、删除流程和事件响应责任。

该产品宣称拥有涵盖安全性、可用性和保密性的 SOC 2 Type II 报告。这一保证涉及组织控制，但并不验证每一项 agent 策略或集成。

基于序列的检测带来了更多不确定性。跨会话关联操作可以发现孤立检查遗漏的渐进式风险；但当标识符不一致时，也可能生成不完整或错误的历史记录。

OpenTelemetry 约定有助于规范化记录，但并不能保证每个框架都会输出等效上下文，或保留相同的身份信息。

开发者必须跨队列、后台任务和服务边界传递关联标识符。缺失的上下文可能让一个工作流看起来像多个互不相关的运行。

过度收集则会带来相反的问题。记录每一条提示词、工具参数和输出，可能扩大监控平台能够访问的敏感数据范围。

安全团队必须在调查细节和数据最小化之间取得平衡。一条有用的审计轨迹应能证明决策，而不是自动复制每一份敏感载荷。

误报是另一项挑战。提示词注入检测器可能标记正当的安全讨论、引用的恶意软件指令或客户内容。

Arcjet 建议采用演练部署，即记录决策但不执行。这样，团队可在激活规则前，将拟议拦截与真实应用行为进行比较。

演练很有价值，但需要结构化审查。团队应标记误报、衡量漏检情况，并测试故障路径，而非被动观察仪表盘。

策略也可能过时。新工具、参数、数据类别和业务流程会改变一项操作的含义。版本化的策略记录有助于调查人员了解某个时点适用了哪条规则。

但这并不能保证规则始终适当。随着工作流变化，安全和应用负责人必须审查策略。

这些局限强化了核心权衡：将执行能力置于代码中可提供有用上下文，但也会将责任分散到各项服务和团队。

Arcjet 需要让这种分布式模式比一套拼凑的自定义授权检查更易于治理。否则，买方可能只是获得又一层策略，却无法实现一致控制。

下一项考验是生产证据，而非功能广度

如果客户能够证明 Arcjet 在真实 agent 工作流中实现了覆盖、低干扰和成功干预，那么这次发布才具有意义。

第一个值得关注的信号，是超出演示环境的采用情况。Arcjet 应展示团队如何盘点 agent、识别关键操作，并将选定策略从演练模式转入执行。

具名的生产部署将说明买方优先保护哪些工作流。支持运营、软件开发、财务和内部数据访问面临不同的风险与延迟要求。

最有力的证据应包括部署时间、受保护操作的覆盖率、误报率，以及在执行前被阻止的操作数量。这些指标将检验 Arcjet 的核心主张。

第二个信号是互操作性。Arcjet 目前列出了与主要 agent 框架和编程助手的集成。市场将评估这些集成能否在混合环境中保留有用上下文。

组织很少将所有 agent 标准化到单一框架。一个工作流可能从聊天界面开始，经由队列继续，最后在自定义服务中完成。

Arcjet 必须连接这些步骤，而不能迫使每个团队使用同一种编排系统。OpenTelemetry 支持提供了可信的发现层，而 SDK 防护则提供执行能力。

这些层之间的差距仍需关注。买方需要清楚了解已发现但关键操作尚未受保护的 agent。

覆盖率报告可能成为该产品最有价值的功能之一。它能让安全团队区分可见性与实际的预防性控制。

第三个信号是竞争反应。Cisco 和其他企业厂商已经在增加 agent 交互治理与运行时保护。

如果这些公司更深入地进入应用处理器，Arcjet 的架构差异将缩小。如果它们仍聚焦于集中式检查，Arcjet 则可以主张其代码级上下文填补了持续存在的空白。

agent 框架提供商也可能加入原生策略钩子。这一发展可能通过创造通用执行点来帮助 Arcjet，也可能降低对独立平台的需求。

市场很可能会支持分层控制。身份、网关检查、操作授权、遥测和人工审核应对的是不同的故障模式。

买方面临的挑战，是防止重叠变成复杂性。每增加一项决策服务，都会带来配置、延迟、日志记录和可用性要求。

Arcjet 的近期机会，是成为关键函数运行前的最终策略检查点。它的风险，则是成为团队广泛部署但仅有限执行的又一个仪表盘。

评估 Arcjet agent 运行时安全的开发者，应从一个边界明确的工作流开始。他们应梳理输入、身份、工具、数据访问、审批步骤和不可逆操作。

接下来，他们可以为最关键的调用添加防护，并让规则以演练模式运行。审核人员应在启用拦截前检查正当案例和对抗性案例。

安全团队还应测试服务不可用时的行为。退款服务、生产数据库写入器和文档搜索工具不应共享同一种默认故障策略。

最后，团队应验证生成的审计证据。调查人员必须能够重建决策过程，同时不暴露不必要的敏感数据。

这次发布揭示了 AI 安全的真实转变。agent 通过操作创造风险，而不只是通过模型输出。控制措施因此必须沿着工作流延伸到软件改变另一系统的节点。

Arcjet 为这一理念提供了具体实现。未来几个月将显示，其代码内方法是否能够在真实组织中提供一致的控制。

对开发者而言，如今最实际的问题已经非常明确：如果某个智能体操作今天执行出错，哪一项会造成最严重的损失？从那里开始，核验相关的身份与上下文，然后在调用之前设置一项可强制执行的决策机制。