Abnormal AI AgentCore 邮件安全通过限制代理权限实现规模化

Abnormal AI 已在一个每日处理数十亿封邮件的检测系统中部署了 Amazon Bedrock AgentCore Code Interpreter。Abnormal AI AgentCore 邮件安全设计为自主代理提供临时算力，但不允许该环境不受限制地访问互联网。这项限制是核心理念，而非无关紧要的配置选择。

代理仅处理该流水线每天数以万计最棘手的案例。轻量级分类器先处理数十亿封邮件，而更大的机器学习模型会检查数百万个不确定的结果。Abnormal 仅将代理驱动的分析用于前序阶段无法自信分类的案例。

这一架构挑战了“邮件安全能力提升依赖于将每封邮件发送给可用的最大模型”这一更简单的想法。它也不同于以分析师为中心的系统，例如 Microsoft Security Copilot；后者可解释钓鱼邮件分类结果以供人工审查。Abnormal 将代理直接置于内联检测流水线中，延迟、隔离以及可预测的故障边界都立即变得重要。

此次部署之所以重要，是因为其代理在分析行为威胁数据时能够编写并执行脚本。这一能力比固定分类器更灵活，但也带来了新的攻击面。一封邮件既是证据，也可能是恶意输入，因此审查邮件的任何代理都必须被视为可能做出不安全决策。

Abnormal 的应对方案是一个围绕选择性升级和受限执行构建的分层系统。模型可在临时沙箱中进行计算、聚合和验证。外围架构则决定哪些内容可以进入、哪些内容可以离开，以及哪些操作始终不可用。

Abnormal AI AgentCore 邮件安全瞄准最棘手的案例

关键变化不在于 Abnormal 增加了一个 AI 代理，而在于它将能够编写代码的代理置于实时检测流水线中，却没有把全部工作负载交给它们。

根据部署案例研究，Abnormal 使用三个处理层级。第一层对每天数十亿封邮件应用小型模型、启发式规则和逻辑回归分类器。这些方法处理无需昂贵分析的案例。

仍不确定的邮件会进入第二层。深度学习及其他机器学习模型每天借助更广泛的行为信号检查数百万封邮件。只有最难解决的案例才会进入第三层。

最后一层每天借助内联代理和 Code Interpreter 处理数以万计的邮件。代理会获取威胁情报数据，动态编写脚本，并分析每个案例如何契合 Abnormal 的行为模型。随后，它们会在邮件进入收件箱前参与检测决策。

这一漏斗对经济性和可靠性都很重要。若在每封邮件上运行通用代理，就会将最多算力花在通常只能带来最少额外价值的地方。它也会使生产流水线中更大一部分暴露于非确定性行为。

选择性升级使代理成为异常处理器。前序阶段承担可预测的处理量，代理则调查那些传统上会交由人工分析师处理的案例。该设计依据不确定性而非产品定位来使用模型复杂度。

该架构也限制了代理故障带来的运营后果。第三层出错仍然很重要，但代理并不控制每一封普通邮件的分类。独立系统会处理误分类，并利用它们改进更广泛的检测系统。

Abnormal 表示，监控系统也会验证实时流水线。AWS 案例研究并未公布独立的准确率、误报率或延迟测量数据。因此，它记录的是一套运行架构，而非证明代理优于所有传统检测方法的对比证据。

该公司还在内联路径之外运行一个分析师代理。该批处理系统会摄取误分类和调优信号，然后在更大的邮件集合中寻找模式。它会为第一层起草候选启发式规则，并为第二层带来改进。

AWS 表示，该分析师代理每周运行约 100 个批处理作业。单个作业可以持续运行超过 30 分钟。由于模型训练在 Code Interpreter 会话之外进行，某些工作流会持续一整天。

这一反馈循环赋予了代理第二种角色。它不仅评判困难邮件，还会从困难结果中挖掘规则，供成本更低的分类器日后应用。

其结果是一种务实的分工。固定规则提供吞吐量，训练模型提供更广泛的模式识别，代理则提供灵活的调查能力。最昂贵的推理仅留给这种灵活性具有明确用途的案例。

临时工作区提供的是计算能力，而非更多模型上下文

Code Interpreter 之所以重要，是因为它让代理能够计算并验证主张，而不是将语言生成当作计算。

大型语言模型可以描述一项计算，却仍然得出错误结果。它也可以提出有用的脚本，但并不知道该脚本是否能够正确执行。Abnormal 的代理需要一个工作区，使生成的代码能够针对获准数据运行。

Amazon Bedrock AgentCore Code Interpreter 通过 API 提供这一工作区。该服务为代理提供隔离环境，用于执行命令、上传文件和返回结果。它不强制规定特定的推理循环或代理框架。

AWS 将这一能力描述为完全托管的无服务器执行运行时。会话在临时 MicroVM 中运行；MicroVM 是具备隔离计算、内存和文件系统的轻量级虚拟机。会话默认持续 15 分钟，最长可配置为八小时。

该环境包括 Python 和 Node.js 运行时，以及常见的数据处理、统计和可视化库。最大 100 MB 的文件可通过 API 直接传递。较大的数据集可使用 Amazon S3 或客户自行管理的文件系统配置。

上下文与计算之间的区别十分重要。向模型提示词中添加威胁情报，会让模型获得更多可供解释的材料。向它提供 Code Interpreter，则让代理能够以编程方式转换、计数、比较并测试这些材料。

Abnormal AI 高管 Shrivu Shankar 将该环境描述为几乎所有代理都需要的计算临时工作区。这种表述将代码执行的用途扩展到软件开发助手之外。安全代理可以使用脚本进行聚合、行为比较、数据验证或可重复的评分。

代理还可以运行程序化验证器。测试、代码检查工具和集成检查可在输出进入另一生产组件前提供机器可读的反馈。它们不能保证正确性，但能为代理提供超越其自身生成解释的证据。

这一方法与代理设计中更广泛的模式相似。开发者正日益将提出工作方案的模型与实际执行工作的运行时分离。模型仍具有概率性，而执行环境则为具体操作提供确定性结果。

AWS 最初将 Code Interpreter 作为安全运行代理生成代码的基础设施推出。它在 Abnormal 流水线中的价值正来自这种分离。Abnormal 可以保留现有代理框架，同时将隔离计算视为外部服务。

轻量级框架也赋予代理灵活性。Abnormal 表示，僵化的分步工作流可能不如配合通用工具的高层原则表现良好。代理可以选择方法，但必须在外围系统设定的边界内运行。

这种平衡并不容易。自由度过低会让代理沦为昂贵的固定工作流。自由度过高则会让不可信输入影响代码、网络请求、文件和凭证。

临时工作区模型找到了中间位置。它赋予代理在本地创建脚本和临时产物的自由。它不会自动授予代理对该工作区周边生产环境的权限。

对于构建者而言，在增加另一个模型或更大的上下文窗口前，这一设计提出了一个明确问题：代理需要更多知识，还是需要一个可控的计算场所？这两类问题需要不同的基础设施。

构建内部代理的团队还需要模型提示词之外的持久记录。一个可搜索的知识库可以保存规范和运营发现。执行沙箱应保持临时性，而经批准的知识则应通过受治理的系统持久保存。

无出口沙箱将代理风险转化为有边界的问题

Abnormal 最有力的设计选择，是即使代理出现意外行为，也不允许分析沙箱不受限制地访问网络。

邮件安全代理处理由外部人员创建的内容。攻击者可以在这些内容中加入指令、链接、编码材料或对抗性文本。模型可能将这些元素视为证据，但也可能将它们当作指令。

这个问题被称为提示注入，即不可信内容试图将代理从预定任务中引开。模型层面的防御可以识别部分攻击，但无法针对每一种操纵提供确定性保证。

因此，Abnormal 为 Code Interpreter 选择了相应的沙箱网络配置。在其实现中，执行环境没有公共互联网出口。威胁情报可以进入以供分析，但生成的代码不能自由地将这些信息传输至外部端点。

这一限制服务于两个目标。第一，它提升了可复现性，因为外部网站或服务无法在执行期间改变会话行为。第二，若模型遵循恶意指令或生成不安全代码，它能够限制数据外泄。

这正是本文的核心张力：代理灵活性与有边界的执行。系统给予模型选择计算方式和编写脚本的自由；基础设施则限制这些脚本能够触及的范围。

AWS 为 Code Interpreter 支持多种网络模式。沙箱模式提供受限的外部访问，包括受支持的 Amazon S3 操作。公共模式允许访问互联网资源，而 VPC 模式将环境连接至获批准的私有资源。

这些选项不应被视为可相互替代的便利设置。公共访问扩展了代理的能力，但也扩大了可能的数据外泄和依赖风险。VPC 访问可以触达有价值的内部系统，因此执行角色和网络策略至关重要。

Abnormal 在其现有的网络隔离执行环境中加入了托管沙箱。这种纵深防御方法避免将单一隔离边界视为充分保障。该公司还控制哪些数据可以进入 Code Interpreter，以及代理能够执行哪些写入操作。

这一架构与其他代理开发领域逐渐形成的安全指导原则一致。Anthropic 认为，代理隔离需要同时具备文件系统和网络边界。若缺少出站限制，遭入侵的进程就可能将可访问的机密信息发送到外部。

Anthropic 后续的隔离分析更直接地阐明了核心观点：概率性监督无法取代对可访问资源设置的硬性边界。即使模型作出错误决策，隔离仍可限制其后果。

AWS 文档补充了另一项重要限定。每个 AgentCore 会话都会获得相互隔离的 CPU、内存和文件系统资源，其 MicroVM 随后会被终止。不过，客户仍需自行负责权限配置、会话映射、输入验证、凭证以及连接的工具。

这份安全指南还警告称，MicroVM 内的代码可以访问分配给该环境的凭证。与其他会话隔离，并不意味着当前会话中过度授予的权限就是安全的。

因此，安全沙箱需要的不只是临时计算资源。构建者必须限定执行角色的权限范围、限制网络路径、过滤工具输入，并排除不必要的凭证。他们还必须决定执行结束后哪些产物可以离开环境。

无出站访问模式尤其适合输入自包含的任务。代理可以接收一组范围明确的证据包，在本地完成计算，并返回有限的结果。需要访问任意网站或外部 API 的工作流，则会带来更棘手的策略问题。

一种答案是采用经由中介的工具层。代理不被授予通用网络访问权限，而是通过受控代理调用具名工具。每个工具都可以执行身份验证、输入验证、允许列表、日志记录以及受限的输出模式。

这种设计既保留了有用的外部操作能力，又不会让沙箱变成一台普通的联网机器。它还为安全团队留下记录：代理请求了什么，以及工具返回了什么。

Abnormal 的部署并未消除提示注入。它降低的是一次成功注入在单个环境中所能造成的影响。相较于声称模型总能识别恶意内容，这是一项更经得起推敲的生产环境主张。

三级管道同时对安全厂商和代理构建者提出压力

Abnormal 的架构将标准从产出具有说服力的代理回答，提高到在真实运营约束下作出边界明确的决策。

电子邮件安全厂商早已使用规则、信誉系统、机器学习和行为分析。新的压力来自于将灵活的代理更深入地置入检测工作流。竞争者必须决定，代理应当辅助分析师，还是直接进入分类路径。

Microsoft 的做法提供了一个有价值的对照，但并不能简单地决出高下。其 Security Copilot Phishing Triage Agent 会评估邮件内容、发件人信誉和行为信号，并生成可由分析师审阅或推翻的分类结果与自然语言说明。

该钓鱼邮件分诊模型强调受治理的代理身份、明确的触发条件、访问权限和操作权利。它将透明度与人工审查置于工作流的核心位置。

相比之下，据报道，Abnormal 的部署会针对经过严格筛选的一小部分邮件使用内联代理。输出会在邮件投递前参与决策，尽管其周围还有监控与独立学习系统。两者的差异更多在于工作流中的位置，而非基础模型能力。

两种方法都不会让人工分析师变得多余。Abnormal 最棘手的案例，正是传统上需要分析师关注的案例。其代理承担了一部分调查工作，而人类仍负责设计控制措施、解释失败情况以及治理模型变更。

这一架构同样对通用代理平台厂商提出了要求。生产运行时需要支持的不只是代码执行，还包括会话隔离、生命周期控制、可观测性、可预测的文件处理，以及管理员能够理解和管理的网络策略。

托管服务降低了运行一次性计算环境所需的工作量，但并未消除应用层设计决策。构建者仍需决定哪些输入能够进入沙箱、会话如何映射到任务，以及哪些结果能够改变生产系统。

三级漏斗还提供了另一项经验：代理扩展在一定程度上是路由问题。团队应衡量不确定性并进行选择性升级，而不是假设每个请求都值得获得同样的模型、上下文、工具和计算预算。

这一原则适用于安全以外的领域。客户支持系统可以将常规请求路由至确定性工作流，并将代理留给模糊情形。数据系统可以先使用固定转换，在模式或证据发生冲突时再调用代理。

批量分析师提供了第二种可复用模式。生产故障可以反馈给离线代理，由其查找重复出现的原因并提出成本更低的规则。人类或自动化验证器可以在这些建议上线前对其进行评估。

不过，这一反馈循环也引入了治理问题。由过去误分类推导出的候选启发式规则，可能编码某种暂时模式，或放大有偏样本。构建者在更新管道早期阶段前，需要准备评估集、发布控制和回滚路径。

AWS 案例研究并未提供这些运营细节。它表示独立系统会从错误中学习，监控会验证线上系统，但没有披露审批阈值、评估方法，或进入生产环境的代理建议比例。

它也没有披露端到端延迟。内联邮件检测受到投递时限约束，而缓慢的第三层可能影响用户体验。选择性路由降低了这一风险，但构建者仍需要了解百分位延迟和超时行为。

成本同样不明朗。该漏斗几乎肯定避免了对数十亿封常规邮件运行代理计算。公开材料没有提供单封邮件成本、会话利用率，或与自管理沙箱的基础设施比较。

这些缺失并不会否定该架构。它们界定了有价值的客户案例研究与经独立验证的性能证据之间的边界。企业买家应评估这一模式，同时要求提供与自身工作负载相关的测量数据。

对安全负责人而言，最有价值的问题不是某一家厂商是否拥有“代理式”检测，而是代理在决策路径的何处介入、它接收什么证据，以及失败时会发生什么。

对于平台团队而言，问题同样具体：代理能否在一个权限严格受限的环境中完成有价值的工作，还是所提议的工作流依赖广泛凭证和开放网络？

如果有价值的工作需要无限制访问，该设计就尚未解决核心权衡，只是将风险转移到了运行时中。

Abnormal AI 案例研究未能证明什么

该部署展现了一种可信的隔离模式，但并未证明其在准确率、速度或总运营成本方面具有独立验证的提升。

核心来源是一篇在 Abnormal 参与下撰写的 AWS 文章。AWS 提供基础设施，而 Abnormal 是被重点介绍的客户。读者应将规模数据和工作流描述视为附带归属的公司说法。

所报告的业务量仍然具有参考意义。数十亿封邮件进入第一层，数百万封进入第二层，每天有数万封进入代理处理环节。然而，这些数量并未说明代理最终能多频繁地改善判定结果。

若干缺失的测量指标将改变评估结论。误报率可以显示复杂但合法的邮件是否面临额外风险。漏报率则可以说明代理是否捕获了早期模型遗漏的攻击。

分析师审阅数据也会有所帮助。如果人工经常推翻代理决策，那么第三层可能更像是一个优先级排序工具，而非自主检测机制。即使推翻情况很少，买家仍需要证据证明监控能够捕捉静默错误。

延迟分布同样重要，因为平均值可能掩盖运营故障。一小部分长时间运行的会话，即使典型分类能够快速完成，也可能延迟邮件投递。超时和回退机制应与模型质量一样接受严谨测试。

同样的谨慎也适用于确定性相关的说法。移除公共互联网访问可降低外部可变性，但模型输出仍可能具有随机性。软件库、输入排序、运行时版本和编排逻辑也都会影响结果。

“无出站访问”也应被准确理解。它限制的是沙箱向公共网络发起通信，并不会自动验证传入数据、防止有害的本地计算，或保证返回的产物不包含敏感信息。

因此，输出控制仍然必不可少。生成的报告本身可能包含机密数据。脚本即使不接触互联网，也可能创建过大的产物、耗尽会话资源，或产生误导性结果。

持久化存储还会带来额外考量。Abnormal 在工作持续时间超过一个会话时，将文件作为检查点。采用该模式的构建者必须定义保留期限、访问边界、加密、并发写入和产物所有权。

文件系统是恢复点，而不是安全策略。离开临时会话的数据会在其他位置变为持久数据。其保护措施随后取决于存储服务和使用它的应用程序。

长时间运行的工作也会使身份管理更复杂。持续一天的流程可能跨越多个会话和外部训练任务。每次交接都需要经过身份验证的任务身份、明确的输入和可验证的输出。

可观测性有助于重建这些转换过程。AgentCore 可以将日志发送到 Amazon CloudWatch，并通过 AWS CloudTrail 审计活动。团队仍须决定记录哪些内容，避免将敏感邮件内容复制到另一个系统中。

监控代理需要同时关注运营和安全信号。执行错误、超时和资源消耗可揭示可靠性问题。异常命令、被阻止的网络尝试以及不寻常的输出大小，则可能暴露敌意行为或混乱行为。

构建者还应刻意测试故障路径。当沙箱无法启动、脚本超出限制，或模型生成无效代码时会发生什么？系统需要一个安全回退机制，不能悄然将不确定性归类为安全。

对于 Abnormal，早期检测层提供了这类外围结构的一部分。公开案例并未说明每一种第三层故障的最终回退机制。在技术评估过程中，这一缺口值得仔细审查。

因此，该案例研究支持的结论比其规模本身可能暗示的更为有限。当路由机制严格限制代理工作负载时，托管临时计算可以融入高吞吐量安全管道。强隔离也可以降低模型失败带来的后果。

它并未证明每一项安全决策都能从代理中受益。它展示的是 Abnormal 认为灵活计算值得投入的位置：那些更简单的系统无法自信解决、数量很少却十分棘手的长尾案例。

三个信号将表明这一模式能否在大规模环境中成立

下一个检验点是，Abnormal 和 AWS 是否会发布运营证据，将隔离架构与可量化的检测结果联系起来。

第一个信号是工作负载质量数据。应关注误报率、漏报率、分析师人工改判情况，以及相较于此前第三层流程的可量化改进。这些结果将更有力地证明，智能体带来的是检测价值，而非架构复杂度。

缺少这类衡量数据并不代表失败。它只会使最强的主张仍停留在供应商报告的实施经验范畴内。采购方仍需结合自身流量和威胁特征开展受控评估。

第二个信号是托管代码执行服务中更深入的策略控制。值得关注的发展包括更严格的出口允许列表、按工具授权、工件扫描、凭证代理，以及详尽的会话来源追踪。这些控制可在不扩大整个沙箱权限范围的前提下授予必要能力，从而强化这一权衡。

若转向不受限制的网络访问，这一模式则会被削弱。它或许能让集成更容易，但也会让概率性的模型防御承受更大压力。最安全的架构，是尽可能将权限置于模型之外。

第三个信号是其他安全厂商开始采用选择性智能体路由。Microsoft 已将智能体应用于网络钓鱼分流和分析师工作流。下一步的关键，是证明厂商能够将智能体置于内联流程中，同时保留透明的回退机制和审查路径。

更广泛的采用将表明，Abnormal 的三层漏斗正在成为行业模式。若市场退回到仅供分析师使用的副驾驶工具，则意味着延迟、可靠性或治理问题仍在阻碍内联自主性。

构建者无需等待市场给出结论。他们现在就可以通过受限工作负载和明确的评估标准来测试这一架构。应从输入包自包含、且结果可由确定性验证器判断的案例开始。

将持久凭证置于执行环境之外。只授予单项任务所需的数据和工具。把每一份文档、消息、网站及工具响应都视为潜在的恶意输入。

应将会话终止纳入设计，而不是当作清理细节。仅持久化已获批准的工件，并将其关联到可审计的任务身份。为每一种超时、格式错误结果和不可用依赖项定义安全行为。

最重要的是，衡量这个漏斗。记录每一层解决了多少案例、为何发生升级，以及下一层是否改善了结果。智能体计算应通过可量化的价值赢得其位置。

Abnormal AI AgentCore 的电子邮件安全故事，归根结底讲的是有纪律的限制。智能体获得足够的自由去调查固定系统无法判定的案例；它们不会仅因推理看似有用，就获得无限的触达范围。

这也是每个生产级智能体团队都应面对的实际问题：你的智能体能够在一个可销毁、可观测且边界严格受控的环境中完成哪些有价值的工作？先构建这条边界，再决定其中应赋予多少自主性。