引子：四则警示，开启头脑风暴
在信息化、数智化、具身智能化、无人化深度融合的今天，企业的每一次技术升级都可能带来一次安全“试炼”。为让大家在防范潜在风险的同时，能够在脑中形成鲜活的安全印象，本文先抛出四个典型案例，供大家头脑风暴、展开想象，进而引出后文的深层次讨论。
| 1 |
AI 生成式助手泄露内部数据：某业务部门在内部聊天群中调用未加身份校验的生成式大模型，输入“请列出本年度的客户名单”。模型因缺乏数据访问控制，将敏感表格直接作为文本返回。 |
大模型缺少“身份感知（Identity‑aware）”能力，未对调用者做细粒度授权。 |
敏感客户信息外泄，导致合规审计被处罚，客户信任度下降。 |
AI 服务必须与数据治理层（如 Lake Formation）深度集成，实现“谁问，谁答”。 |
| 2 |
未经审计的跨账号 Lambda 调用：研发团队在 CI/CD 流水线中使用一个共享的 Lambda 函数进行日志归档，因未在函数内部进行身份上下文交换，导致访问了不该触及的 S3 桶。 |
跨账号调用缺少 “Trusted Identity Propagation (TIP)” 机制，导致权限提升。 |
业务数据被写入公共桶，触发数据泄露预警，云资源费用异常激增。 |
每一次跨服务、跨账户的调用，都应在 “单次 Lambda 会话” 中完成身份交换，防止权限漂移。 |
| 3 |
动态凭证泄露导致内部攻击：某项目组使用 IAM Role 通过 AssumeRole 获得临时凭证，凭证在前端页面的 JavaScript 中被意外打印到浏览器控制台，攻击者利用 XSS 窃取后直接调用 Athena 查询。 |
临时凭证未做最小化权限、有效期限制，且日志/调试信息泄露。 |
攻击者以合法身份查询受限数据，导致业务报告被篡改，内部审计受阻。 |
临时凭证必须紧锁业务范围、短生命周期，并做好前端信息脱敏。 |
| 4 |
无人仓库机器人被钓鱼指令操控：公司在无人化仓库部署了 AGV（自动导引车），其调度系统通过 HTTP 接口接受任务。黑客伪造合法的 OIDC Token，利用缺失的 token 校验，向机器人下发“前往指定货架取货并返回”。结果导致高价值商品被误运走。 |
身份验证链缺失，未对 OIDC Token 进行完整校验与绑定。 |
商品损失、业务中断、信任危机。 |
任何面向机器人的指令接口，都必须实现 身份感知、细粒度授权，并记录完整审计日志。 |
这四则案例，分别映射了 AI 数据治理缺失、跨账户身份漂移、临时凭证泄露、机器指令伪造 四大安全痛点。它们既是警示，也是我们在数字化转型中需要重点防范的“安全暗礁”。接下来，让我们从技术实现层面，拆解 AWS 官方提供的 “身份感知 AI 数据代理”（Identity‑aware AI Data Agent）方案，看看如何在实际项目中把这些暗礁化为安全礁石。
一、身份感知 AI 数据代理的核心思路
“技术本身不具备善恶，关键在于使用者的思维与治理。”——《道德经》‑老子
在传统的 AI 代理实现中，代理往往以 单一服务角色（IAM Role）运行，所有业务请求最终被该角色的权限所决定。如此一来，业务层的细粒度授权 只能依赖于在代码里硬编码的访问控制，导致两大问题：
- 授权分离失效：真正的业务主体（人或机器）身份被隐藏，所有操作都归于服务角色，审计链条断裂。
- 治理成本膨胀：每新增或变更业务需求，都需要在代码里同步更新权限逻辑，极易出现遗漏。
身份感知 AI 数据代理 通过以下三步实现 “身份随请求流转，授权在数据层完成”：
- 请求头传递（Header Allowlist）：在 Bedrock AgentCore Runtime 中配置自定义请求头白名单，将用户的
id_token（身份证明）随 HTTP 传递到代理容器。
- 网关元数据转发（Metadata Configuration）：在 Bedrock AgentCore Gateway 的元数据配置中，声明允许转发的自定义请求头，确保该头部能够安全地到达 Lambda 目标，而不被工具（Tool）参数捕获。
- Lambda 端读取与兑换：在 Lambda 函数内部，从
context.client_context.custom['bedrockAgentCorePropagatedHeaders'] 读取 id_token，随后使用 IAM Identity Center 的 Trusted Identity Propagation (TIP) 机制，完成 Token ↔︎ Identity Context ↔︎ STS AssumeRole 的一站式兑换，得到带有真实用户身份的临时凭证，并在该凭证下调用 Athena（或其他数据服务）。
如此一来，Lake Formation 只会看到 真实的业务主体，而不是代理角色；所有查询均受到 Lake Formation 细粒度授权（列级、行级、列过滤等）约束；而 CloudTrail 的 onBehalfOf 字段则完整记录了“谁在背后”。整个链路的安全属性如下：
| 最小暴露 |
id_token 只在 HTTP 头层传递，未进入模型 Prompt/Memory |
防止模型泄露或日志记录中出现敏感身份信息 |
| 单次会话 |
身份上下文在 Lambda 内部完成兑换后即销毁 |
防止凭证被持久化、横向滥用 |
| 授权统一 |
Lake Formation 授权统一管理，AI 层不再参与 |
降低运维复杂性，提升治理一致性 |
| 全链路审计 |
CloudTrail 自动记录 AssumeRole + onBehalfOf |
合规审计“一键可查”，提升信任度 |
这正是 “安全即治理、治理即安全” 的最佳实践，在企业的数智化进程中，提供了一套 “身份先行、数据后授”的安全底层框架。
二、从案例到实践：逐层拆解安全防线
1. 前端 UI – OIDC 令牌的获取与存储
在实际业务中，所有业务用户均通过 OpenID Connect（OIDC） 进行统一身份认证。我们推荐采用 Amazon Cognito 或 企业级 IdP（Okta、Microsoft Entra ID），并在 IAM Identity Center 中配置 Trusted Token Issuer (TTI) 与 OAuth Application（Enable CreateTokenWithIAM），以便后续的 Token‑>IdentityContext 兑换。
技巧：在页面层面，使用 HttpOnly + Secure + SameSite=Strict 的 Cookie 存储 access_token，而 id_token 则在前端 JavaScript 中保留短时间用于调用 AI 代理的自定义 Header。
# .bedrock_agentcore.yamlrequest_header_configuration: requestHeaderAllowlist: - Authorization # 标准 OAuth 访问令牌 - X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken # 身份令牌
此配置是 “第一道关卡”：只有在白名单中的 Header 才会注入到容器的 request_headers 对象中，防止敏感信息被随意泄露。
from bedrock_agentcore.runtime import BedrockAgentCoreAppID_TOKEN_HDR = "X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken"app = BedrockAgentCoreApp()@app.entrypointdef invoke(payload, context): hdrs = getattr(context, "request_headers", {}) id_token = hdrs.get(ID_TOKEN_HDR, "") # 将 id_token 连同业务 payload 一并通过 MCP 发送给网关 # 注意：不要把 id_token 放入工具参数或 Prompt 中 # ...
关键点：id_token 只在 HTTP 传输层 带过去，从不进入模型的 Prompt、Tool Schema、或内部记忆，确保大模型本身不具备读取身份信息的能力。
gateway_target = agentcore.CfnGatewayTarget(
self, "AthenaExecutor", name="athena-executor", gateway_identifier=self.gateway.attr_gateway_identifier, target_configuration=agentcore.CfnGatewayTarget.TargetConfigurationProperty( mcp=agentcore.CfnGatewayTarget.McpTargetConfigurationProperty( lambda_=agentcore.CfnGatewayTarget.McpLambdaTargetConfigurationProperty( lambda_arn=lambda_arn, tool_schema=tool_schema # 不包含 id_token 参数 ) ) ), metadata_configuration=agentcore.CfnGatewayTarget.MetadataConfigurationProperty( allowed_request_headers=["X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken"] ))
第二道关卡：只有在 allowed_request_headers 中声明的 Header 才会被网关安全注入到 Lambda 的 client_context，避免任意 Header 泄漏。
5. Lambda – 服务器端 Token 兑换与业务执行
import boto3, jwt, timeID_TOKEN_HDR = "X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken"def lambda_handler(event, context): # 读取自定义 Header propagated = getattr(context.client_context, "custom", {}) id_token = propagated.get("bedrockAgentCorePropagatedHeaders", {}).get(ID_TOKEN_HDR) if not id_token: return {"statusCode": 400, "body": {"error": "Missing id_token"}} # 1. 校验 id_token（签名、exp、aud、iss 等） # 2. 使用 sso-oidc.create_token_with_iam 兑换 IdentityContext # 3. AssumeRole（ProvidedContexts）获取用户身份的临时凭证 # 4. 用该凭证调用 Athena，确保 Lake Formation 按用户授权返回数据 # 5. 返回业务结果
这一步是 “单次会话” 的核心：身份上下文在 Lambda 内部完全闭环，既不返回前端，也不写入日志，确保凭证仅在执行期间有效。
在 Lake Formation 中，管理员已为 IAM Identity Center 用户或组配置了 SELECT、INSERT、列级过滤、行级过滤 等权限。由于前面的链路已经把真实用户身份注入到查询上下文，Lake Formation 能像传统 BI 工具一样，自动完成 “谁能看哪些列、哪些行” 的精细控制。
小结：从 前端 → Runtime → Gateway → Lambda → Lake Formation，每一步都实现了 “身份随请求传递，授权在数据层完成，审计在云原生日志中落地”，形成了闭环的 安全治理链。
三、数智化、具身智能化、无人化背景下的安全新挑战
在 数字化（Digitalization） 与 智能化（Intelligence） 的交叉点上，企业正在经历以下三大技术浪潮：
- 数智化平台：数据湖、实时分析、生成式 AI 成为业务核心。
- 具身智能（Embodied Intelligence）：机器人、边缘计算节点、IoT 设备具备感知、决策与执行能力。
- 无人化（Unmanned）：全自动化仓储、无人车、无人值守的生产线。
这些技术的共同点是 “每一次数据交互都可能成为安全入口”。如果仍然沿用“服务角色统一授权”的传统思路，必然导致：
- 权限过宽：单一角色拥有所有数据的读取权限，任何被攻破的服务都能直接泄露全库。
- 审计缺失：无法区分是人还是机器发起的请求，导致合规审计难以满足 GDPR、PCI‑DSS 等法规。
- 供应链攻击面扩大：外部第三方模型、插件、工具链若被植入恶意代码，便可以借助过宽的角色横向渗透。
1. 从“角色”到“身份”：TIP 的战略价值
Trusted Identity Propagation (TIP) 把 “用户身份” 从前端一路传递到后端的数据服务，实现 “最小特权、最小暴露” 的安全目标。它的价值体现在：
- 身份唯一性：每一次请求都绑定了唯一的
identityContext，即使在跨账户调用中，也能保持原始用户的足迹。
- 细粒度审计：CloudTrail 自动在
AssumeRole 事件中记录 onBehalfOf，精准定位到具体的 IAM Identity Center 用户。
- 动态授权：Lake Formation 的细粒度策略（列/行过滤）与身份绑定，使得 “谁问、谁答” 在数据层自动实现，而不需要在业务代码中硬编码。
2. 具身智能的身份管控
对于 机器人、AGV、无人机 等具身设备，建议采用 机器凭证 + OIDC 代理 的组合：
- 设备注册到 IAM Identity Center，获取唯一的 client_id / client_secret。
- 每一次任务指令都携带 OAuth 2.0 JWT，在 Gateway → Lambda 环节进行 TIP 兑换后，再调用 Lake Formation 或 S3 等服务。
- 通过 行级过滤，确保即便被攻击者控制了设备，也只能访问该设备所属业务范围内的数据。
3. 无人化运营的审计闭环
在 无人化仓库 中，所有指令均通过 HTTPS + OIDC 进行身份验证，每一次指令的下发、执行、结果回传 均形成 CloudTrail 记录。通过 Lake Formation 的 列/行级别审计，即使出现异常行为，也能快速定位到 “是哪位业务用户、哪台设备、何时何地”。
四、行动号召：加入信息安全意识培训，让每个人成为安全的“第一道防线”
“千里之堤，溃于蚁穴。”——《左传·僖公二十六年》
在技术防线已经逐渐完善的今天，人的行为仍是最关键的防御环节。为了让所有同事在数智化、具身智能、无人化的浪潮中，既能拥抱创新，又能保持警觉，我们即将启动 《信息安全意识提升专项培训》，邀请每位员工积极参与。
培训目标
| 安全认知升级 |
通过案例剖析，让大家了解 AI 代理、跨账户调用、临时凭证等核心概念。 |
| 身份治理实战 |
手把手演示 TIP、Lake Formation 与 Bedrock AgentCore 的完整链路。 |
| 合规审计意识 |
解读 CloudTrail、onBehalfOf 机制，帮助大家理解审计日志的价值。 |
| 日常防护技巧 |
强化密码、令牌管理、最小权限原则，以及对 Phishing、XSS、供应链攻击 的防御方法。 |
培训形式
- 线上微课堂（45 分钟）：由资深安全架构师讲解理论与最佳实践，配合实时演示。
- 实战实验室（90 分钟）：提供 Sandbox 环境，学员自行完成 从 UI 获取 id_token → 通过 TIP 兑换 → Athena 查询 的全链路操作。
- 情景演练（30 分钟）：模拟实际安全事件（如案例 2、案例 4），让学员现场定位、响应、复盘。
- 知识测评：采用轻量化的选择题与填空题，帮助巩固学习成果，合格者将获得 安全先锋徽章。
参与方式
- 报名渠道：公司内部门票系统（点击“培训·安全”），填写姓名、部门、预期学习目标。
- 时间安排：每周四 14:00‑16:30，分批次进行，确保不影响业务高峰。
- 学习资源：培训结束后，统一发布 课程视频、示例代码、最佳实践手册，供大家随时回顾。
温馨提示：本次培训所有实验均采用 AWS 免费层 与 内部隔离账户，请务必在实验结束后 删除临时凭证和资源，确保不留安全隐患。
为何这场培训对你至关重要？
- 提升个人竞争力：掌握 TIP、Lake Formation、Bedrock AgentCore 等前沿技术，成为公司内部的 安全与 AI 融合专家。
- 保障业务连续性：了解并规避因身份泄露、凭证滥用导致的业务中断风险。
- 合规与信任：通过审计日志、细粒度授权，帮助公司满足 GDPR、ISO 27001、PCI‑DSS 等国际合规要求。
- 自我防御：在日常办公、远程登录、第三方工具使用中，能够主动识别并阻断潜在攻击。
五、结语：让安全意识在每一次点击中生根发芽
信息安全不是某个部门的专属责任，而是 每个人的日常习惯。在 AI 大模型、数据湖、无人化设备层出不穷的今天，我们既要拥抱技术红利，也要筑起 身份感知、最小特权、全链路审计 的安全防线。通过本次 身份感知 AI 数据代理 的实践，再结合即将开展的 安全意识培训，我们相信：
- 每一次查询 都会在 Lake Formation 的细粒度策略中得到约束；
- 每一次指令 都会在 IAM Identity Center 的身份校验中得到验证；
- 每一次审计 都会在 CloudTrail 中留下清晰、可追溯的足迹。
让我们在 数智化、具身智能化、无人化 的新时代里，携手把安全理念落到 代码、配置、日志 的每一个细节中。请立即报名参加培训，用实际行动为公司、为行业、为自己的职业生涯，构筑一道坚不可摧的安全城墙。
安全，始于意识；防护，行于实践。
让我们一起，让安全成为企业文化的基石，让每一次创新在安全的护航下，飞得更高、更远。
在日益复杂的网络安全环境中，昆明亭长朗然科技有限公司为您提供全面的信息安全、保密及合规解决方案。我们不仅提供定制化的培训课程，更专注于将安全意识融入企业文化，帮助您打造持续的安全防护体系。我们的产品涵盖数据安全、隐私保护、合规培训等多个方面。如果您正在寻找专业的安全意识宣教服务，请不要犹豫，立即联系我们，我们将为您量身定制最合适的解决方案。
- 电话：0871-67122372
- 微信、手机：18206751343
- 邮件：info＠securemymind.com
- QQ: 1767022898
