使用 Amazon Bedrock AgentCore 对亚马逊 S3 和 Snowflake 进行人工智能信用分析

原文：AI Credit Analytics Across Amazon S3 and Snowflake with Amazon Bedrock AgentCore

银行的信贷分析师收到 50,000 美元的贷款申请。该决定需要查看该机构的信贷政策手册（以 PDF 格式存储在 Amazon S3 中），提取申请人的账户历史记录和交易模式（存储在 Snowflake 中），并将两者合成建议，所有这些都在同一次对话中完成。如今，此工作流程通常涉及在三到四个系统之间切换、复制粘贴数据，仅手动查找每个应用程序就可能需要 20-40 分钟。

在这篇文章中，我们介绍了一种可部署的参考架构，它可以同时解决这两个难题。我们将展示 Amazon Bedrock AgentCore 如何编排单一的人工智能代理，该代理涵盖亚马逊 S3 中的非结构化文档和 Snowflake 中的结构化数据。该架构包括每位用户的身份、完整的审计跟踪以及从第一天起的 PII 保护。该模式使用模型上下文协议（MCP）作为其可扩展工具接口，这意味着您无需重新设计即可连接任何与 MCP 兼容的数据源，例如今天的 Snowflake、未来的亚马逊 Redshift 或亚马逊关系数据库服务（Amazon RDS）。参考部署在大约 70 秒内完成全面的信用资格评估（未优化的基线，我们稍后将详细介绍），在几秒钟内即可完成分析师跨系统手动交叉引用通常需要 20-40 分钟的过程。

金融服务中的信贷决策挑战

信贷决策本质上是多源的。保单文件（承保指南、监管门槛、产品条款表）存放在文件库中。客户数据（账户余额、交易历史、信用评分、就业记录）存在于数据平台中。这两个世界很少共享一个通用的查询接口。

如果您正在为信贷决策、贷款发放或了解您的客户（KYC）构建基于人工智能的分析，您将面临三个复合限制：

可审计性：监管机构希望每一次数据访问都可追溯到特定的人工操作员。当人工智能代理查询客户数据时，查询必须以真实分析师的身份出现在 Snowflake 的 QUERY_HISTORY（或等效账户）中，而不是通用服务账户。否则，审计跟踪的可追溯性就会丢失。

访问控制：不同的分析师拥有不同的数据权限。零售信贷分析师不应查看商业贷款组合。这些基于角色的访问控制 (RBAC) 边界必须在数据平台层强制执行，而不是在可以绕过的应用程序代码中强制执行。

数据敏感性：客户的个人身份信息 (PII)，包括社会安全号码、账号和出生日期，绝不能出现在人工智能生成的响应中，即使基础数据源返回了这些信息。编辑必须是自动的和政策驱动的。

现有方法通常包括构建自定义 API 层、手动管理 OAuth 代币交换以及编写每个连接器的集成代码。每个新的数据源都意味着一个新的集成项目。结果脆弱、维护成本高昂且难以审计。

解决方案概述：Amazon Bedrock AgentCore 和 MCP

我们的参考架构使用 Bedrock AgentCore 作为包含三个工具的单个 AI 代理的编排层。每个工具都由不同的数据源支持，全部统一在 MCP 标准下：

-knowledge_base_search：对存储在亚马逊 S3 中的信贷政策 PDF 进行检索增强生成 (RAG)，由亚马逊基岩知识库提供支持，以亚马逊 OpenSearch Serverless Serverless 作为矢量存储。

-cortex_search：在 Snowflake Managed MCP 服务器上使用 Snowflake Cortex Search 对客户信用档案进行语义搜索。

-cortex_analyst：通过同一个 MCP 服务器使用 Snowflake Cortex Analyst 对 Snowflake 中的结构化银行数据（账户、交易、余额）执行自然语言到 SQL。

知识库路径使用代理的 IAM 执行角色而不是每用户证书，因为信用政策文件是机构知识，而不是需要每位用户访问控制的客户特定数据。客户数据敏感且受 RBAC 的约束，使用每位用户的 Okta 代币正确流经 AgentCore 网关。这是一个经过深思熟虑的架构边界：治理（Cedar，每个用户的身份）适用于最重要的路径：客户数据访问。

AgentCore Gateway 充当代理与 Snowflake 托管 MCP 服务器之间的 MCP 协议感知桥梁。它处理出站身份验证，使用 Cedar（一种专门构建的授权策略语言）强制执行每种工具的访问策略，并管理三足的 OAuth（3LO）同意流程，所有这些都对代理代码透明。

图 1：信用风险评估代理：从分析师通过 AgentCore 到数据源的逻辑流程，通过 Okta 3LO 提供每位用户的身份。

代理人如何回答贷款资格问题

为了说明端到端流程，请考虑一个常见的信贷工作流程：“客户 C-1042 有资格获得 50,000 美元的个人贷款吗？”代理只需一个回合即可协调以下内容：

第 1 步：调用 knowledge_base_search，从亚马逊 S3 的政策 PDF 中检索银行的债务与收入（DTI）比率限制、最低信用评分门槛和个人贷款的产品条款。

第 2 步：调用 cortex_search，通过语义搜索从 Snowflake 中提取客户的信用档案（风险指标、就业状况、信用记录）。

第 3 步：致电 cortex_analyst，从 Snowflake 的结构化表格中查询客户的经常账户余额、月收入和现有债务。

步骤 4：综合所有三个结果：根据实际数据计算债务收入比率，将其与保单门槛进行比较，根据最低额度检查信用评分，并生成带有支持证据的结构化资格建议。

在我们的参考部署中，整个多工具编排（从问题到综合建议）在大约 70 秒内完成。如果没有代理，同样的分析需要 20-40 分钟的跨系统手动交叉引用。对于一家每天处理 200 份贷款申请的银行来说，这意味着每周都会恢复大量的分析师能力。您的信贷团队这次可以将重定向到复杂的边缘案例、关系管理和投资组合层面的风险分析。

企业身份：监管环境的每位用户可审计性

这种模式下的关键架构决策是身份如何从人工分析师通过人工智能代理流向数据平台。在许多 AI 代理实现中，代理使用共享服务帐户向下游系统进行身份验证。这种方法无法满足金融服务监管部门的预期，原因很简单：如果每个查询在审计日志中都显示为 “service-agent-prod”，则监管机构无法确定哪位分析师访问了哪些客户的数据。

图 2：企业身份和治理层：每层均可独立审计。

搭载 Okta 的三足式 OAuth

该架构使用三足式 OAuth (3LO) 实现每用户身份，Okta 作为企业身份提供商，与大多数金融机构已经用于企业单点登录的 Okta 相同。以下是身份的流动方式：

-分析师使用 Okta 单点登录（SSO）进行身份验证（由您的公司政策强制执行多因素身份验证（MFA））。

-亚马逊 AgentCore Identity 将分析师 Okta 发行的 OAuth 代币存储在其托管代币库中：每位用户设置一个代币，从未共享。访问令牌到期时，使用存储的刷新令牌自动刷新。

-当代理调用雪花工具时，AgentCore Gateway 会检索该特定分析师的代币并将其转发给 Snowflake。

-Snowflake 根据 Okta 的 JSON Web 密钥集 (JWKS) 端点验证 Okta JSON Web 代币 (JWT)，将代币声明映射到分析师的 Snowflake LOGIN_NAME，并在分析师的角色（例如 ANALYST_ROLE）下执行查询。

结果：Snowflake 的 QUERY_HISTORY 中的每一个查询都归因于真正的人类分析师：他们的姓名、角色和权利。如果分析师 A 可以看到零售账户但看不到商业投资组合，那么即使人工智能代理发布 SQL，Snowflake 的本地 RBAC 也会强制执行该边界。不需要应用程序级访问控制代码。

对于您的合规团队而言，这意味着审计记录与直接查询 Snowflake 的人没有区别，因为在数据平台层，它是人类。人工智能代理是分析师手中的工具，而不是拥有自己证书的独立参与者。

关于令牌生命周期和失效模式的注意事项：当 Okta 访问令牌在会话期间到期时，AgentCore Identity 会自动使用存储的刷新令牌来获取新的令牌。无需用户交互。如果刷新令牌本身已过期，则代理会收到授权请求（新的同意 URL），而不是硬错误。在更具破坏性的情况下，Okta 以管理方式撤销了令牌，AgentCore 无法检测到该服务器端，并且下游的 MCP 工具调用将收到身份验证错误。应用程序必须通过调用 forceAuthentication: true 来处理此问题，才能启动干净的重新身份验证流程。在任何这些场景中，对话上下文都不会丢失。

每种工具授权的 Cedar 政策

AgentCore Gateway 使用 Cedar 来控制每个用户可以调用哪些工具。Gateway 强制执行默认拒绝模式：除非明确的许可政策授予访问权限，否则每个工具调用都将被阻止。Cedar 架构是根据您的 Gateway 的工具定义自动生成的，您可以针对该架构以声明方式编写授权规则。

例如，一项允许分析师访问 cortex_analyst 工具的策略：

许可（委托人是 AgentCore:: oauthUser，操作 == AgentCore:: Action:: “Snowflakemcp___Cortex_Analyst”，资源 == AgentCore:: Gateway:: “arn: aws: bedrock-agentcore:: gateway/”）当 {Principal.Hastag（“角色”）&& Principal.getTag（“角色”）== “” ANALYST 时;

注意：确切的操作名称和主要标签是根据您的网关配置自动生成的。有关确切的语法，请参阅您部署的 Gateway 的 Cedar 架构。

用户的身份（来自他们的 OAuth 令牌声明）决定了他们可以访问的内容。工具标识在操作中编码，资源是网关本身。

这意味着您的授权决策是可审计的、确定性的，并且与应用程序代码分开。添加新工具或向新角色授予访问权限是策略更改，而不是代码部署。

使用亚马逊基岩护栏保护 PII

即使代理检索合法的客户数据，敏感字段也不得出现在人工智能生成的响应中。我们为 Amazon Bedrock Guardrails 配置了 PII 实体检测，为输入和输出上的美国社会安全号码和信用卡/借记卡号设置了匿名化操作。如果分析师不小心在提示中加入了敏感标识符，或者如果代理的响应中包含卡号，则在响应到达用户之前，护栏会对其进行拦截和编辑。这是已配置的策略，不是自动推断。它使您的安全团队可以明确控制哪些实体类型受到保护以及对每种实体类型适用哪些操作（封锁或匿名）。

可扩展性：MCP 作为通用数据连接器

代理架构的一个常见问题是锁定：如果您围绕一个数据平台进行构建，则添加第二个数据平台需要进行大量的重新设计。MCP 通过提供与数据源无关的标准工具调用协议来消除此问题。

在这个参考架构中，Snowflake 是 AgentCore Gateway 背后的 MCP 目标之一。将 Amazon Redshift 添加为第二个数据源只需要四个步骤：

-部署 Redshift MCP 服务器（一种将 Redshift 查询作为 MCP 工具公开 Redshift 查询的轻量级封装器）。

-在同一 AgentCore 网关实例上将其注册为新目标。

-添加 Cedar 政策，授予相应用户访问新工具的权限。

-将新工具定义添加到代理的工具列表中。

代理的推理逻辑没有变化，没有新的 OAuth 流程，没有基础设施的重新架构。同样的模式适用于亚马逊 RDS、亚马逊 DynamoDB 或任何公开 MCP 接口的第三方系统。在我们的测试中，添加新的 MCP 目标从开始到调用工具仅用了不到 30 分钟。

对于一家今天向 Snowflake 查询信用分析但明天又想增加 Amazon Redshift 以获取市场风险数据和为欺诈信号添加内部 REST API 的银行来说，扩张是配置，而不是一个新项目。这是 MCP 在实践中实现的可扩展性承诺：您的架构随业务而扩展，而不是与业务背道而驰。

性能和运营结果

我们在五个代表性的信用分析情景中衡量了参考实施情况。下表显示了连续三次测试运行的平均延迟：

表 1：参考部署的实测性能（三次运行的平均值）。

部署条件和调整机会

上述测量是在以下参考部署条件下进行的：

-Snowflake 小型仓库，可自动暂停 300 秒（空闲期结束后会出现冷启动延迟）

-公共互联网终端节点贯穿始终（亚马逊 CloudFront、应用程序负载均衡器、亚马逊 ECS Fargate、AgentCore Gateway、Snowflake MCP 服务器）

-默认亚马逊虚拟私有云（亚马逊 VPC）中的单个 ECS Fargate 任务（1 个 vCPU，3 GB 内存），us-east-1

-LLM 的顺序多工具编排（代理一次调用一个工具，而不是并行调用工具）

生产部署可以通过多种优化来减少这些延迟：

-更大的 Snowflake 仓库：中型或大型仓库可消除冷启动延迟并缩短查询执行时间。

-VPC 终端节点和 AWS PrivateLink：使用连接到 AgentCore 的 VPC 终端节点以及与 Snowflake 的 PrivateLink 连接取代公共互联网跳跃可以减少网络往返时间。

-并行工具调用：调整代理的系统提示以并行（而不是按顺序）调用独立工具，可以将完整资格评估延迟（最复杂的场景，调用所有三个工具）缩短 2-3 倍，因为知识库查询和 Snowflake 查询彼此之间没有依赖关系。

-暖仓排程：配置更长的自动暂停间隔或使用 Snowflake 的仓库调度可以消除工作时间内的冷启动开销。

FSI 决策者的关键指标不是原始延迟，而是操作改进率：即使在最复杂的情况下约为 71 秒，该架构也比手动跨系统分析提高了 17-34 倍。单源查询实现了 16-43 倍的改进。对于一个每天处理 200 份申请的信贷团队来说，这意味着分析师可以腾出大量精力去做判断密集型工作。

评估代理质量以做好生产准备

企业 FSI 部署需要在生产版本发布之前提供代理质量的书面证据。AgentCore 评估在整个代理互动流程中提供托管评估。它衡量了四个关键维度：支持按需评估（用于 CI/CD 质量门户）和在线评估（实时流量连续采样）。对于错误的决策会带来监管后果的信用风险代理人，我们建议从这四个指标开始作为生产前的验证套件。

-刀具选择精度：代理是否选择了正确的工具？

-工具参数精度：是否通过了正确的客户 ID 和财务参数？

-正确性和忠诚度：信用决定是否以检索到的数据为事实？

-目标成功率：代理人是否提供了完整的资格建议？

吸取的经验教训

根据金融服务要求构建和测试该架构浮出水面，这两个见解广泛适用于部署 AI 代理的 FSI 机构：

企业 SSO 到数据平台的身份映射需要预先验证

在任何查询成功之前，必须验证身份提供商的令牌声明和数据平台的用户标识符之间的映射。即使是很小的不匹配，例如区分大小写的差异，也会导致静默身份验证失败。我们建议您运行部署前验证脚本来确认目标群体中每个用户的映射。

添加新数据源是配置，不是工程

一旦建立了 AgentCore Gateway + MCP 模式，添加新的数据源将遵循一份可重复的清单：部署 MCP 服务器、注册目标、编写雪松政策、添加工具。在我们的测试中，从开始到调用工作工具只用了不到 30 分钟。

先决条件和预计成本

要部署参考实现，您需要：启用基岩模型访问权限（Claude Sonnet）的 AWS 账户、启用 Cortex Search 和 Cortex Analyst 的 Snowflake 账户、配置了自定义授权服务器和 OpenID Connect (OIDC) Web 应用程序的 Okta 租户，以及 AWS CDK CLI。全面部署大约需要 15-20 分钟。参考部署的预计运行成本约为每天 15-25 美元，这主要是由 OpenSearch Serverless（至少 2 个 OpenSearch 计算单元（OCU））、ECS Fargate（1 项任务）和亚马逊 Bedrock 模型调用推动的。根据您的 Snowflake 合同，雪花成本（仓库计算）单独计费。我们建议在沙箱账户中部署以进行评估。

结论和后续步骤

在这篇文章中，我们演示了 AgentCore 如何通过 Okta 3LO 与 MCP 和企业身份相结合，为金融服务中基于人工智能的信用分析提供可部署的模式。该架构解决了采用金融服务业人工智能的核心紧张局势：对智能自动化的需求以及对每位用户可审计性和访问控制的监管要求。

完整的参考实现可在 GitHub 上找到。它包括使用 AWS CDK、综合银行数据、策略文档和代理代码进行的一键部署。

我们鼓励您在沙盒环境中部署此参考架构，使用自己的政策文档和数据架构对其进行测试，并评估该模式如何映射到您的信用决策、KYC、欺诈检测或投资组合分析工作流程。要开始，请克隆存储库并运行。/deploy.sh。整个环境将在大约 15-20 分钟内完成部署。