Greenlight Financial 基于 Amazon Bedrock AgentCore 构建自主 SOC 解决方案

Greenlight Financial 每月处理多达 4,000 起安全与风险案件，其中 90% 以上无需人工干预即可解决。Greenlight 的 Luna 使用了 Amazon Bedrock AgentCore，这是用于大规模构建、连接和优化智能体的基础设施。具体而言，Greenlight 使用 AgentCore runtime（Amazon Bedrock AgentCore 的一项功能）来托管 Luna 的智能体代码，并使用 AgentCore memory（Amazon Bedrock AgentCore 的一项功能）来支持其分层多智能体系统。这避免了在内部自行构建和运营这些功能的需要。Luna 可在数秒内对暗网泄露卡告警、身份异常和金融风险事件进行分类分诊。

本文介绍了 Greenlight Financial 如何在 Amazon Bedrock AgentCore 上构建自主安全运营中心（SOC）解决方案。我们将介绍其多层级监督者架构、30 多个专用智能体、用于持续学习的情景记忆，以及从 SOC 用例扩展到金融风险分诊的过程。我们还将分享生产环境指标、基础设施决策，以及在受监管行业中构建自主安全运营的模式。

Greenlight 需要解决的问题

Greenlight Financial 为家庭提供金融产品：借记卡、储蓄工具，以及 Family Hub 和宠物追踪器等联网设备。该公司在与大型银行相同的监管要求下大规模处理敏感金融数据。

Greenlight 的 SOC 每月收到 3,000–4,000 条来自四个主要渠道的安全与风险告警：

• 暗网泄露卡 – 卡组织网络和内部威胁情报发现 Greenlight 客户的卡出现在暗网上。
• 身份与访问异常 – 在身份提供商（IdP）和内部系统中出现的异常登录模式、权限提升和策略违规。
• 基础设施告警 – 来自 EDR（端点检测与响应）、SIEM（安全信息与事件管理）、资产清单及其他可观测性工具的信号。
• 金融风险事件 – 来自卡处理系统的可疑交易模式、合规触发器和欺诈指标。

每条告警都需要交叉比对多个数据源，分析师才能做出判定。一条暗网泄露卡通知需要检查该卡是否处于激活状态、与历史通知去重、审查客户会话数据，并检查未结的支持工单。这一流程对人类分析师而言每起案件需要 15-30 分钟。按每月 4,000 起案件计算，这笔账根本算不过来。

Greenlight 需要一个能够实现以下功能的系统：

1. 以机器速度自主分诊并解决常规案件。
2. 将复杂案件连同完整上下文上报给人类分析师。
3. 从解决模式中学习，以逐步提升准确性。
4. 在金融服务合规护栏内运行。

架构：基于 Amazon Bedrock AgentCore 的分层多智能体系统

Greenlight 将 Luna 构建为 Amazon Bedrock AgentCore 上的分层多智能体系统。该架构采用分层监督者模式，与人类 SOC 团队的运作方式一致：L1 处理海量事件，L2 处理复杂案件。

图 1：Luna 在 Amazon Bedrock AgentCore 上的分层监督者架构

第 1 层监督者：高并发分诊

第一层主管（Tier 1 supervisor）使用通过 Amazon Bedrock 提供的高级语言模型，运行在 Amazon Virtual Private Cloud（Amazon VPC）内的 Amazon Bedrock AgentCore 运行时上。该运行时使用私有子网，并通过 ZIP 文件和 Amazon Simple Storage Service（Amazon S3）进行直接代码部署。它通过编排 30 多个专用智能体来处理传入案例的初步分诊：

第一层主管通过两条路径接收案例：暴露 Luna Queue API 和 Model Context Protocol（MCP）端点的 Amazon API Gateway，以及用于自动警报接入的 Tines SOAR。它会根据警报类型决定调用哪些专用智能体，综合它们的发现并给出结论。常规案例的中位分诊时间为个位数秒。

第二层主管：深度调查

超出第一层置信度阈值的案例会升级到第二层主管，后者使用 Amazon Bedrock 上具备扩展推理能力的高级基础模型。该智能体处理需要多步推理的 10% 案例：

• 对升级案例进行更深入的跨数据源关联再调查。
• 通过 boto3 以扩展的上下文窗口调用专用智能体。
• 跨 3–5 个数据源串联推理以建立因果关系。
• 生成包含证据链的详细调查报告，供人工审查。

第二层主管按计划运行，使用 Amazon EventBridge 速率触发器和 Amazon Simple Notification Service（Amazon SNS）队列完成通知来批量处理升级案例，并可按需处理紧急的第一层升级案例。

面向不同角色的入口

不同团队以不同方式使用 Luna，因此应用提供了三个入口。范围涵盖完全自动化的警报接入到交互式的按需调查。每个入口对应一个角色及其工作的到达方式：

1. Tines SOAR – 主要的流量来源。自动化警报接入直接将案例送入第一层。
2. 安全、风险与 ProdOps 工程师 – 直接 API 访问，用于临时调查请求。
3. Claude Desktop 扩展 – 面向值班工程师的聊天界面。工程师打开扩展，描述想要调查的内容，Luna 便以完整的工具访问权限执行深度调查。

记忆与学习：Luna 如何随时间变得更聪明

记忆层构建在 AgentCore memory 之上。正是这一层将 Luna 与无状态的分诊工具区分开来。它支持模式识别、去重以及持续提升准确性。

情景记忆（30 天滚动窗口）

存储近期事件与处置结果。当新告警到达时，Luna 会检查：“过去 30 天里我见过这种模式吗？当时的结论是什么？这是否是一种我应该加入允许列表的已知行为？”

具体示例：Greenlight 的某个基础设施角色每周二凌晨 3 点会为计划的维护生成特定的访问模式。没有记忆时，Luna 每周都会标记它。有了情景记忆后，Luna 在第一次处置后就了解到这种模式是预期的，并将其自动加入允许列表。

长期记忆

将语义偏好与处置模板保留在 30 天窗口之外：

• “这种访问模式是预期的，因为这就是该角色的用途。”
• Greenlight 的历史案例数据显示“来自这个特定暗网来源的卡片有 73% 的误报率——优先进行去重处理。”
• 针对重复出现案例类型的处置模板，承载了机构知识。

案例学习流水线

一条专用流水线将处置结果反馈回系统：

1. 摄取——一个 AWS Lambda 函数从 Tines 事件中捕获每一次案例处置结果。
2. 学习 + 去重——DynamoDB 存储处置模式并对相似案例去重。当 Luna 以相同方式解决同一案例三次后，它会将其记录为已确认的模式。
3. 摘要——一个 Lambda 函数将新的学习成果处理为可操作上下文，供监督者（supervisor）在推理时使用。
4. 反馈回路——处置学习成果反馈到第一层（Tier 1），逐步提升首次处理的准确率。

这条流水线将 Luna 的自主处置率从 83%（仅 Tier 1）提升到 90% 以上（Tier 1、Tier 2 以及学习成果）。

从 SOC 扩展到金融风险分诊

在 SOC 部署后的两个月内，Greenlight 将 Luna 扩展到金融风险评估领域。架构上的改动极小：在现有基础设施上叠加了新的专用智能体和一个风险领域监督者。

暗网泄露卡片工作流

当一张 Greenlight 客户卡片出现在暗网上时，Luna 会自主执行以下工作流：

1. 摄取——威胁情报提供商（Mastercard、内部信息源）报告被泄露的卡号。
2. 验证——Luna 查询 Galileo：这张卡是否属于 Greenlight？当前是否处于激活状态？近期的交易记录如何？
3. 去重——DynamoDB 检查：这是重复通知吗？这张卡是否已被处置过？多个提供商常常报告同一次泄露。
4. 交叉引用——查询 Mixpanel 检查客户会话异常，查询 Zendesk 查找相关工单，并参考内部欺诈评分。
5. 评估并行动——确定风险等级。低风险：记录并监控。中风险：标记待审查。高风险：附带完整证据链升级给人工分析师。

Greenlight 每天会收到数百条泄露卡片通知。Luna 在几秒钟内处理每一条。而人工分析师做同样的工作——登录 Galileo、检查 DynamoDB、打开 Mixpanel、搜索 Zendesk——每张卡需要 15-30 分钟。

成果

下表从对 SOC 最重要的指标角度跟踪了 Greenlight 的安全运营情况。它对比了三个阶段：Luna 之前的人工分诊、Tier 1 自动化，以及完整的 Tier 1 和 Tier 2 系统。

预计节省的分析师时间：

根据 Greenlight 的案例量和人工处理耗时测量，每月处理 4,000 个案例、每个案例 15–30 分钟，大约需要 1,000–2,000 个分析师工时。Greenlight 报告称，Luna 自主解决了其中 90% 以上的案例，每月避免了估计 900–1,800 小时的常规人工工作。分析师可以转而专注于需要人类判断的案例。

风险降低来自两个因素：速度（以秒计 compared 分钟，缩短了暴露窗口）和一致性（Luna 在周六凌晨 3 点应用的分类逻辑与周二上午 10 点完全相同，没有疲劳，也没有走捷径）。

构建 Luna 的五点经验

构建 Luna 并将其从安全运营扩展到金融风险领域，为在受监管环境中构建多智能体系统的团队带来了五点经验：

1. 从有边界的领域开始，再横向扩展

Greenlight 从安全分类处置入手，因为成功标准非常明确：正确解决案例或升级处理。在该模式被证明可靠、解决率达 83% 之后，扩展到金融风险领域只需添加新的专业智能体和一个风险领域监督智能体，而无需重构架构。

2. 镜像你的人类团队结构

Tier 1/Tier 2 模式直接对应 SOC 团队现有的运作方式。L1 分析师按照操作手册处理大量案例，L2 分析师运用调查技能处理复杂案例。这使得与安全团队建立信任的过程更快。他们直观地理解这一模型，因为它与他们自己的升级逻辑相吻合。

3. 记忆的价值会不断累积

情景记忆和长期记忆层正是让 Luna 从 83% 提升到 90% 以上的关键。每个被解决的案例都会教会 Luna 一些东西：一个新的允许列表模式、一个已确认的误报来源、一个解决方案模板。运营 6 个月后，Luna 已经积累了新的人类分析师需要数月才能建立起来的机构知识。

4. 先分类，后行动

在受监管的环境中，Greenlight 将 Luna 设计为只做分类和建议，不会在没有明确策略批准的情况下采取自主修复行动。风险领域的扩展遵循同样的原则。Luna 提供支持其建议的证据。在这种人在回路模式中，由人类分析师或经批准的自动化策略来授权并执行修复。这种分离满足了 Greenlight 的合规要求，并与风险团队建立了信任。

当 Greenlight 扩展到金融风险领域时，他们复用了现有的专业智能体（Datadog、Zendesk、Mixpanel），并添加了领域专用的智能体（Galileo、欺诈评分）。同一个检查 Zendesk 工单的智能体，既用于安全案例，也用于风险案例。这降低了维护开销，并有助于保持跨领域的一致性。

基础设施技术栈

Luna 完全运行在 AWS 托管服务之上。Amazon Bedrock AgentCore 是编排运行时，技术栈的其余部分负责调度、消息传递、状态、密钥管理和集成。下表列出了每项服务及其在基础设施中的角色：

Greenlight 接下来的计划

在安全与风险这一基础之上，Greenlight 正在将 Luna 的多智能体模式扩展到新的运营领域和工具中：

• 全面的风险领域覆盖——针对金融和业务风险案例的自主分诊（进行中，约一个月前已上线）。
• 产品运营——探索使用 AWS DevOps Agent 进行事件调查、根因分析和缓解指导。Greenlight 还在评估 Luna 现有的智能体如何在能力重叠的情况下支持运营调查。
• 自定义运营工作流——探索 AWS DevOps Agent 的自定义智能体、技能和 Model Context Protocol 集成，以实现可重复的运营工作流并访问 Greenlight 的内部工具。
• AWS DevOps Agent 与技能——结合 AWS DevOps Agent 的 UI 和技能框架，用于脚本执行工作流（执行时限 90 秒）。
• Well-Architected 评审——探索使用 Model Context Protocol 服务器，依据 AWS 最佳实践进行自动化的基础设施评估。

结论

根据 Greenlight 的生产环境测量数据，Luna 可自主解决公司 90% 以上的安全与风险案例，每月处理多达 4,000 个案例。需要进一步判断的案例会升级给人类分析师。这种人在回路中的方法使 Greenlight 能够自动完成常规分诊，同时保持对修复决策的控制。

其他受监管行业的团队也可以采用同样的方法：从一个有明确边界的用例入手，定义清晰的升级标准，并随着系统成熟逐步添加专门的智能体和记忆。在初始模式被证明可靠之后，团队可以将其扩展到相关的运营领域。

要了解更多信息，请访问 Amazon Bedrock AgentCore 产品页面和 Amazon Bedrock AgentCore 文档。

关于作者