Agent 安全框架设计建议：洋葱模型、零信任原则与 Amazon Bedrock AgentCore 实践
内容提要
Agent安全需以确定性边界约束非确定性行为。文章提出洋葱模型八层防护与零信任原则，强调容器共享内核非最终边界，应默认视Agent代码为不可信。结合Amazon Bedrock AgentCore，通过会话级microVM隔离、JWT身份透传、Cedar细粒度工具授权及Credential Provider代管下游凭证，实现端到端安全。
延伸解读
为什么容器不是运行 Agent 的最终安全边界
文章指出，普通容器与宿主机共享内核，仅靠 namespaces 和 cgroups 隔离，配置不当或存在漏洞时可能被突破。文中列举了 CVE-2024-21626、2025 年底披露的一组 runc 漏洞以及潜伏 18 年的 SCTPhantom 内核漏洞，说明即使运行时零缺陷，共享内核本身仍是逃逸面。因此，补丁、seccomp、AppArmor/SELinux 等加固手段虽能降低风险，但无法从架构上抹掉共享内核这层边界。
零信任在 Agent 场景中的具体落地方式
文章强调零信任是贯穿所有层的原则，而非其中一层。具体到 Agent：不因为请求来自内网、来自 AgentCore Runtime 或来自另一个 Agent 就默认可信；AgentCore Runtime 与 AgentCore Gateway 各自独立验证身份，不共享隐式信任；每次工具调用都基于“谁、做什么、对什么资源、在什么上下文”重新授权；默认拒绝，身份缺失或传播失败时 fail closed，绝不静默降级为权限更大的机器身份；令牌一律短期、最小权限、限定 audience 与 scope。
Cedar 如何为 Agent 提供确定性授权判定
文章澄清了认证与授权的区别：认证回答“你是谁”，由 AgentCore Identity / OAuth / OIDC / JWT 负责；授权回答“你能做什么”，由 AgentCore Policy / Cedar 负责。Cedar 把授权表达为 permit / forbid 规则，每条规则针对 principal、action、resource、context 四元组，对同样输入始终给出同样判定。在调用链中，AgentCore Gateway 是执行点，负责拦截并强制；Cedar 是决策点，只出判定。Agent
下游长期凭证为何不应进入 Agent 运行环境
文章对比了两种凭证管理方式：反模式是把长期凭证存入 Secrets Manager，再让 Agent 在运行时读取，这会使凭证进入 Agent 环境，一旦提示注入或代码执行成功，攻击者就能读走并复用。推荐做法是由 AgentCore Identity 的 Credential Provider 代管下游长期凭证，Agent 只经 AgentCore Gateway 调用工具并接收结果，不接触凭证。以 EKS 为例，推荐将操作封装为窄权限工具，通过 STS 短期凭证和受限 RBAC 角色完成，从而缩小凭证爆炸半径。
Q&A
为什么说普通容器不能作为运行 Agent 代码的最终安全边界？
普通容器与宿主机共享同一个内核，仅靠 namespaces 和 cgroups 做隔离。这种让容器轻量的机制，恰恰是它在配置不当或存在漏洞时可被突破的原因。例如 CVE-2024-21626（Leaky Vessels）中，runc 的文件描述符泄漏使恶意镜像有机会越过容器文件系统边界读写宿主机；2025 年底披露的一组 runc 漏洞可通过挂载竞态与 procfs 写重定向实现完整逃逸，甚至绕过 AppArmor/SELinux；SCTPhantom（CVE-2026-64564）在内核中潜伏 18 年，在保留默认 seccomp、未授予 CAP_NET_ADMIN 和 CAP_SYS_ADMIN 的测试容器中仍可获取宿主机 root 权限。因此容器可以降低风险，但不能被当作运行不可信代码时不可突破的最终边界。
Agent 安全中的洋葱模型具体包含哪些层？
洋葱模型把彼此独立的安全控制放在多层相互嵌套的边界上，按由内到外的防护位置分成八层：1. 模型与编排层——限制自主循环、约束工具选择，高风险操作人工二次确认；2. 会话与运行时层——按用户/会话隔离执行环境，会话结束销毁环境、清理内存；3. 网络与出口层——默认拒绝出站，白名单限制对内网与实例元数据服务的访问；4. 输入与内容层——在 Agent 运行环境之外执行提示注入检测、内容过滤和不可信数据标记；5. 身份层——每次请求都携带可验证的用户或工作负载身份；6. 工具授权层——对每个工具及关键参数做独立、确定性的策略判断；7. 凭证与下游访问层——长期凭证由受控组件管理，Agent 只按需拿短期访问能力；8. 审计与治理层——记录用户、会话、模型决策、工具调用、策略结果与下游响应。
零信任原则在 Agent 安全架构中是如何体现的？
零信任贯穿所有控制层，决定每一层如何作出访问决策。具体到 Agent：不因为请求来自内网、来自 AgentCore Runtime 或来自另一个 Agent 就默认可信；AgentCore Runtime 与 AgentCore Gateway 各自独立验证身份，不共享隐式信任；每一次工具调用都基于“谁、做什么、对什么资源、在什么上下文”重新授权；默认拒绝，身份缺失或传播失败时 fail closed，绝不静默降级为权限更大的机器身份；令牌一律短期、最小权限、限定 audience 与 scope。
AgentCore 如何实现用户身份从登录到工具授权的端到端透传？
整条身份链有两个独立的信任边界：AgentCore Runtime 判断“谁可以调用这个 Agent”，AgentCore Gateway + AgentCore Policy 判断“这个用户能不能调用这个工具、用这组参数”。流程为：1. 在 IdP 签发阶段通过 Pre Token Generation Lambda 注入可信业务 Claims（如 loyalty_tier）；2. AgentCore Runtime 原生 Inbound Auth 在边界验证 JWT（签名、过期、client_id）；3. Agent 从 RequestContext 取出已验证令牌，原样透传给 AgentCore Gateway，Agent 只做信使；4. AgentCore Gateway 再次独立验证 JWT，并将可信 claims 映射为 Cedar 的 principal 属性，由 AgentCore Policy 引擎评估 principal/action/resource/context，只有 PERMIT 才转发调用；5. 下游长期凭证由 AgentCore Identity 的 Credential Provider 代管，不进入 Agent 环境。
Cedar 在 Agent 工具授权中扮演什么角色？它和 AgentCore Gateway 如何分工？
Cedar 是亚马逊云科技开源的授权策略语言与求值引擎，把授权表达成一组 permit/forbid 规则，每条规则针对四元组：principal（谁）、action（做什么动作）、resource（对什么资源）、context（在什么上下文，比如工具参数）。Cedar 对同样的输入始终给出同样的判定，因此适合为非确定性的 Agent 提供确定性的授权判断。Cedar 只作授权判定，不拦截请求；AgentCore Gateway 是执行点，负责拦截并强制执行 Cedar 的判定。Agent 通过 AgentCore Gateway 这个唯一入口调用工具：Gateway 先把已验证的 JWT claims 映射成 Cedar 的 principal 属性，再交给 AgentCore Policy 引擎评估，只有结果为 PERMIT 才把调用真正转发给工具。
为什么推荐用 AgentCore Identity 的 Credential Provider 代管下游凭证，而不是让 Agent 从 Secrets Manager 读取？
常见做法是把长期凭证存入 Secrets Manager，再给 Agent 读取权限，让 Agent 在运行时读取和使用。但 Agent 取出长期凭证时，就把它读入了自己的运行环境——落在内存里，可能还进了日志和堆栈。而 Agent 跑的正是最不可信的那类代码，一次成功的提示注入或代码执行，就能让攻击者把这份长期凭证读走、外传；只要凭证仍然有效且下游接受该凭证，攻击者还可能在 Agent 环境之外复用它。推荐做法是下游凭证不进 Agent，由 AgentCore Identity 的 Credential Provider 代持：读取与使用都发生在受控边界内，Agent 在下游访问环节只拿到工具调用的结果，不接触这些下游凭证。两种做法的本质差别是凭证的爆炸半径。
AgentCore Runtime 的会话级 microVM 隔离解决了什么问题，又没解决什么问题？
AgentCore Runtime 采用 microVM 模式，为每个会话分配独立的 microVM，隔离 CPU、内存和文件系统，并在会话终止时销毁该 microVM、清理内存。它正面回答了“容器不是最终边界，靠什么兜底”的问题：不共享内核，逃逸漏洞即便被触发，影响也只限于这一个会话的 microVM，碰不到宿主机，也碰不到其他用户。但隔离强度只能回答“这段不可信代码能不能碰到邻居”，回答不了“它代表谁”“能调用什么工具”“能用哪些参数”“凭证放在哪里”。这些需要身份、工具授权、凭证管理等其他层的体系化设计。
在 Agent 安全设计中，认证和授权分别对应 AgentCore 的哪些组件？
认证（Authentication，你是谁）对应 AgentCore Identity / OAuth / OIDC / JWT。AgentCore Identity 的 inbound auth（JWT Authorizer）在边界验证调用者的身份。授权（Authorization，你能做什么）对应 AgentCore Policy / Cedar。AgentCore Policy 是面向 Agent 工具调用的细粒度授权服务，可使用 Cedar 策略对调用者、工具、资源及上下文作出确定性判断。AgentCore Gateway 接入 AgentCore Policy 并启用强制执行模式后，会按判定放行或拒绝工具调用。另外，OAuth 本身是一种粗粒度授权，所以准确的分工是：OAuth 负责身份 + 粗粒度授权，Cedar 负责细粒度、带上下文、确定性的授权。
