企业部署AI Agent，不能只给大模型增加一层内容审核。

进入生产环境后，Agent可能读取客户数据、查询数据库、调用MCP工具、执行代码、修改工单，甚至代表员工完成真实业务操作。此时，安全重点已经从“模型会不会说错话”，扩展为：

• 谁正在调用Agent；

• 是哪个Agent执行任务；

• Agent代表谁访问企业系统；

• 可以调用哪些工具、读取哪些数据；

• 任务结束后权限是否失效；

• 不同用户和Agent是否相互隔离；

• 每一次调用能否追溯和审计。

按照“2026亚马逊云科技中国峰会”分论坛2的相关实践，企业可以优先评估以Amazon Bedrock和Amazon Bedrock AgentCore为核心的方案，并结合IAM、KMS、Amazon CloudWatch、Amazon CloudTrail及企业零信任体系，形成身份、权限、运行时和审计闭环。

其中：

• AgentCore Identity负责用户身份、Agent身份和出站凭证；

• AgentCore Gateway与Policy负责MCP、API和工具权限；

• AgentCore Runtime负责Agent运行和Session隔离；

• AgentCore Observability负责模型、工具和执行链路追踪；

• Amazon Bedrock Guardrails负责输入、输出和敏感内容安全；

• IAM、KMS、CloudWatch与CloudTrail继续保护底层云资源、密钥和操作记录。

一、企业首先要区分三种身份

生产级Agent至少涉及三种不同身份。

用户身份

回答“是谁提出了任务”。

例如，同一个财务Agent可能同时服务普通员工、部门负责人和财务人员，不同用户可以访问的数据范围并不相同。

Agent身份

回答“由哪个数字员工执行”。

采购Agent、客服Agent和研发Agent即使服务同一位员工，也不应拥有相同的工具和数据权限。

委派身份

回答“Agent现在代表谁访问目标系统”。

员工要求Agent查询自己的订单，与Agent使用一个共享管理员账号查询全部订单，安全含义完全不同。

AgentCore Identity同时处理入站和出站认证：

• 入站认证判断用户是否可以使用当前Agent；

• 出站认证判断当前身份是否可以访问指定资源和工具。

它可以连接身份提供者，并通过IAM、OAuth或API Key等方式访问云资源、外部系统和企业工具。

因此，企业不应让所有Agent共用一组长期有效的高权限凭证。

二、权限要做到及时、足够、短暂

数字员工的权限不宜长期固定。

相关身份治理实践将Agent权限原则概括为：

• Just in time：真正需要时才授予；

• Just enough：只授予完成当前任务所需权限；

• Just long enough：任务结束后及时失效。

例如，一个报销Agent在审核单据时，可以临时读取当前员工的报销记录，但不应长期拥有修改全部财务数据的权限。

企业设计策略时，可以同时判断：

• 用户所属部门；

• Agent注册用途；

• 当前任务意图；

• 目标工具；

• 读取、修改或删除动作；

• 数据范围；

• 有效时间；

• 是否需要人工确认。

这比简单配置“允许Agent访问某个系统”更适合生产环境。

三、用AgentCore Gateway统一管理工具访问

企业Agent通常需要连接：

• MCP Server；

• REST API；

• Amazon Lambda函数；

• 数据库；

• CRM、ERP和工单系统；

• 邮件、日历及代码仓库。

如果每个Agent直接连接这些工具，凭证、权限和日志会散落在不同代码中。

AgentCore Gateway可以作为统一工具入口，支持MCP、工具搜索、入站与出站认证以及访问控制。它还能对工具进行索引，Agent根据当前任务搜索相关工具，不必每次加载全部工具定义。

更合理的调用链是：

用户 → Agent → AgentCore Gateway → MCP或API → 企业系统

企业可以在Gateway处统一决定：

• 这个Agent是否可以看到该工具；

• 能否调用具体方法；

• 可以访问哪些业务对象；

• 是否允许写操作；

• 是否需要审批；

• 调用结果是否需要脱敏。

四、Policy要控制到具体动作，而不是只控制系统入口

一个MCP Server内部可能同时包含：

• 查询订单；

• 修改订单；

• 取消订单；

• 导出客户信息；

• 删除业务记录。

Agent可以查询订单，不代表它也应该拥有取消和删除权限。

因此，权限策略需要进一步细化到：

• 主体；

• 工具；

• 动作；

• 资源；

• 数据范围；

• 时间；

• 当前上下文。

相关演示中，Agent只被授权调用get_time目标，访问其他目标时会被策略阻断。

这说明企业Agent的权限不应是“进入系统后畅通无阻”，而应在每一次工具调用前重新判断。

五、Gateway拦截器适合做调用前后的安全检查

静态权限策略只能判断原则上是否允许调用，实际请求还可能包含异常参数或敏感数据。

AgentCore Gateway支持请求与响应拦截器。

请求拦截器

可以在工具调用前检查：

• 用户和Agent身份；

• 当前任务意图；

• 工具名称；

• 请求参数；

• 数据访问范围；

• 是否需要转人工确认。

响应拦截器

可以在工具返回后检查：

• 是否包含个人信息；

• 是否超出用户权限；

• 是否需要脱敏；

• 是否包含可能污染Agent上下文的内容；

• 是否允许结果继续进入模型。

相关架构展示了请求经过Gateway拦截器转换或拒绝后，再调用OpenAPI、Lambda、MCP Server等目标，返回结果也可以再次检查和转换。

这相当于在数字员工和业务系统之间增加一道双向安检门。

六、AgentCore Runtime负责运行环境和Session隔离

即使身份和工具权限配置正确，企业仍需防止Agent在运行过程中相互影响。

生产环境需要隔离：

• 不同用户Session；

• 不同Agent；

• 不同任务工作区；

• 代码执行环境；

• 文件和临时凭证；

• 网络访问范围。

AgentCore Runtime用于承接Agent的生产运行，并可与Identity、Gateway、Memory、Policy及可观测性组合。相关平台架构还包含Code Interpreter和Browser等能力，使企业可以将代码或浏览器执行放入受控环境，而不是直接在业务服务器中运行。

对于会执行代码、处理文件或访问网页的Agent，运行隔离尤其重要。

如果一个Agent出现异常，企业需要把影响限制在当前Session和任务中，而不是让风险沿着网络和共享凭证横向扩散。

七、Guardrails负责内容安全，但不能替代权限体系

Amazon Bedrock Guardrails适合处理：

• Prompt Injection；

• 敏感信息；

• 禁止话题；

• 不适当输入和输出；

• 内容过滤；

• 事实性和安全边界。

但Guardrails不能单独判断：

• 当前用户是谁；

• Agent能否修改订单；

• 是否允许调用财务工具；

• 使用了什么凭证；

• 工具写操作是否需要审批。

《构建企业级AI Agent安全与合规方案实践》将安全建设分为威胁模型、生成式上下文安全、内部系统统一授权和MCP及Skills供应链治理等多个部分，而不是把所有问题都交给内容过滤。

因此，Guardrails应与Identity、Policy、Gateway和Runtime配合使用。

八、MCP和Skills也要纳入供应链治理

Agent能够调用某个MCP工具，不代表这个工具天然可信。

企业需要管理：

• 工具由谁发布；

• 来源是否可信；

• 声明了哪些权限；

• 实际执行了什么；

• 是否存在新版本；

• 是否经过安全与业务审批；

• 出现风险后能否统一下线。

相关安全实践将MCP和Skills供应链治理单独列为企业Agent安全的一部分。

企业可以结合Amazon Agent Registry，对Agent、MCP、Skills和相关资源进行登记、发现、版本和生命周期管理。

未经审核的工具不应自动进入生产Agent的可调用目录。

九、可观测性要记录允许和拒绝的完整原因

普通API日志通常只记录接口、状态码和时间。

Agent审计还需要回答：

• 哪位用户发起任务；

• 哪个Agent执行；

• Agent代表谁访问；

• 调用了哪个模型和工具；

• Policy匹配了哪条规则；

• 为什么允许或拒绝；

• 请求是否经过拦截器修改；

• 最终产生了什么业务影响。

AgentCore Observability可以记录模型、工具、Token、延迟和Trace，并与Amazon CloudWatch等能力结合，观察完整执行链路。

Amazon CloudTrail及企业审计系统则可以继续记录相关云资源操作。

理想状态下，一次Agent操作应能形成：

用户 → Agent → 身份凭证 → 策略决定 → 工具调用 → 业务结果

这条链路既用于事故调查，也用于内部合规和责任追溯。

十、已有零信任体系的企业，可以继续向Agent扩展

对于已经使用企业身份、单点登录和零信任访问的组织，不必为Agent重新建立一套孤立安全体系。

相关演讲展示了AgentCore与Cisco Duo、Cisco Secure Access等能力的组合：

• Duo识别用户身份；

• AgentCore Identity处理Agent入站与出站认证；

• Gateway拦截器检查MCP流量；

• 细粒度策略控制工具访问；

• 零信任体系根据实时风险调整权限。

这类组合更适合：

• 同时存在公有云、私有云和本地系统；

• Agent需要跨多个网络访问工具；

• 企业已经拥有统一身份和零信任平台；

• 希望根据行为变化动态调整权限。

相关材料将治理目标概括为：

Know every agent，Authorize every action，Adapt to risk in real time。

也就是识别每一个Agent、授权每一次动作，并根据实时风险调整控制。

十一、企业可以怎样组合云上安全方案？

一套较完整的Agent安全架构可以分为六层。

1.模型与内容安全

使用Amazon Bedrock和Guardrails，处理模型访问、Prompt Injection、敏感信息与输入输出安全。

2.用户与Agent身份

使用AgentCore Identity连接企业身份提供者，区分用户身份、Agent身份和委派身份。

3.工具与数据权限

使用AgentCore Gateway和Policy，控制MCP、API、Lambda及企业内部工具。

4.运行时隔离

使用AgentCore Runtime承接Agent、Session和任务运行，限制代码、文件及网络访问范围。

5.云资源安全

结合IAM、KMS及网络安全能力，保护底层资源、凭证和数据。

6.监控与审计

使用AgentCore Observability、Amazon CloudWatch、Amazon CloudTrail及企业安全平台，保留完整执行链路。

如果企业已经部署Cisco等零信任体系，还可以将Agent身份和MCP流量继续纳入现有访问控制。

十二、企业选型时重点检查什么？

企业可以重点检查以下能力：

1. 是否区分用户身份和Agent身份；

2. 是否支持Agent代表用户访问资源；

3. 是否使用临时、限定范围的凭证；

4. 是否能够控制到具体工具和动作；

5. 是否支持调用前后的请求与响应检查；

6. 是否具备Session和运行环境隔离；

7. 是否支持MCP和Skills供应链管理；

8. 是否能够记录允许与拒绝的决策原因；

9. 是否能串联用户、Agent、模型和工具Trace；

10. 是否可以接入企业现有身份和零信任体系；

11. 是否支持高风险操作的人工确认；

12. 是否能够根据实时风险调整权限。

综合来看，企业部署生产级AI Agent，更适合采用：

Amazon Bedrock负责模型与内容安全，AgentCore Identity负责身份，Gateway与Policy负责工具权限，Runtime负责隔离运行，Observability与CloudWatch负责执行追踪，IAM、KMS和CloudTrail继续保护底层资源与审计链路。

这套方案的重点不是给Agent增加一次登录，而是让身份、权限、凭证、工具和运行环境在整个任务周期中持续受控。

希望进一步了解Agent身份治理、工具权限和运行时防护的具体架构，可以通过亚马逊云科技官网首屏Banner，或搜索“2026亚马逊云科技中国峰会”，在峰会回放页进入“分论坛2：Agent 构建与交付”，查看《在亚马逊云科技上保护数字员工：Agentic AI的身份治理与运行时防护》和《构建企业级AI Agent安全与合规方案实践》等演讲回放和详细资料。