企业级 Agentic AI 安全护栏：Agent 与 MCP Tools 的零信任架构设计

1. Introduction

Agentic AI 系统的关键特征，在于它的自主性与推理能力：它能把复杂任务拆解成多个更小的可执行任务，再以可监控、可反思、可调整、可自我纠正的方式编排这些任务的执行。正因如此，Agentic AI 几乎有能力重构今天企业里绝大多数业务流程。无论是客户服务台，还是工业场景中的 HVAC optimization，甚至构建底层软件、数据和 ML engineering pipelines，都可以被「agentify」。

要实现这种 agentification，我们需要一门覆盖整个 Agentic Lifecycle 的新整体性学科。这个生命周期大致包括：

• 捕获 agentic use-case requirements
• 设计 agents，例如合理的 agent hierarchy、适用的 agentic skills 与 tools
• 在 agentic platform 上对 agents 进行 secure 与 scalable 的实现
• 对这些 agents 进行治理与维护

在这个 agentification 过程中，有几个原则值得牢记。

首先，常见倾向是把手工流程 1:1 映射成 agentic 流程，但这通常是一种低效映射。设计者要清楚，agent 并不受诸如 HR processes 的约束，software agent 既可能做不同的事情，也可能以不同于人类的方式做事。

其次，从安全角度看，正如人类常常是链条中最薄弱的一环，单个 agent 也可能破坏整个执行过程。如果某个 agent 失控，我们甚至不知道应该归责于谁。因此，所有 agents 都应当以同样的最高标准设计，并配合 logging、observability 以及 responsible AI guardrails。

今天，AI agents 常常通过 ad-hoc endpoints 暴露，导致安全、运营与合规控制高度碎片化。如果缺少良好设计的 agentic security architecture，我们会面临几类风险：

• Security vulnerabilities：由于 authentication 与 authorization 实现不一致
• Operational inefficiencies：由于 monitoring 与 telemetry 碎片化
• Compliance risks：由于 audit trails 不充分，以及 unauthorized data access 或 data governance 问题
• Scalability challenges：缺少集中式、policy based 的 rate limiting 与 throttling
• Poor user experience (UX)：缺少标准化的 agent、tool 和 model discovery、invocation patterns 以及 user access control

本文将深入讨论 agentic lifecycle 的安全层面，更具体地说，是定义标准化且可扩展的交互安全模式，覆盖：

users → applications → agents → tools → (data) source systems

2. Agentic AI Reference Architecture

下图说明了 agentic AI platform 的关键组件，它们也是第 3 节安全模式的基础：

• Reasoning layer：用于分解复杂任务，并调整执行以达成目标
• Agentic marketplace / registry：用于管理现有和可用的 agents、tools 和 models
• Orchestration module：用于编排并监控 multi-agent systems 的执行
• Integration module：通过 MCP tools 与 enterprise systems 集成，例如 ERP、CRM、KB repositories
• Shared memory management：用于 agents 之间共享数据和上下文
• Governance layer：包括 explainability、privacy、security、安全护栏等

给定一个 user task，agentic AI platform 的目标是识别并组合出一个能够执行该任务的 agent 或一组 agents。因此，我们首先需要一个 reasoning module，负责把任务分解为子任务，再由 orchestration engine 编排各个 agent 的执行。

Chain of Thought（CoT）是当前使用最广泛的分解框架，用于把复杂任务转换为多个可管理任务，也帮助我们理解模型的思考过程。另一方面，ReAct（reasoning and acting）框架允许 agent 批判性地评估自身行动和输出，从中学习，并随后优化计划或 reasoning process。

Agent composition 意味着必须存在一个 agent marketplace 或 agent registry，并对 agent capabilities 与 constraints 有清晰描述。例如，Agent2Agent（A2A）protocol 定义了 Agent Card 的概念，这是一个 JSON 文档，相当于 agents 的数字名片。它包含以下关键信息：

Identity: name, description, provider information.
Service Endpoint: The url where the A2A service can be reached.
A2A Capabilities: Supported protocol features like streaming or pushNotifications.
Authentication: Required authentication schemes (e.g., "Bearer", "OAuth2") to interact with the agent.
Skills: A list of specific tasks or functions the agent can perform (AgentSkill objects), including their id, name, description, inputModes, outputModes, and examples.

当需要编排多个 agents 时，就需要一个 system integration layer 来支持不同的 agent interaction patterns，例如 agent-to-agent API、面向人类消费输出的 agent API、由人触发 AI agent，以及带 human in the loop 的 AI agent-to-agent。底层 Agent OS platform 必须支持这些 integration patterns。

我们采用 Anthropic 最近提出的 Model Context Protocol（MCP），把 AI agents 连接到企业数据所在的外部 systems 或 tools。MCP 被称为 AI models 的「USB-C」，它通过三个主要构件实现互操作性：

1. Resources：server 可以提供给 AI 的结构化数据，例如代码片段、文档片段或数据库查询结果，任何能增加事实性上下文的内容。
2. Prompts：server 可以提供的预制指令或模板，例如用于摘要文本或以特定风格生成代码的保存提示词。
3. Tools：AI 可以请求 server 执行的实际动作，例如在 retrieval 侧查询数据库、搜索网页等。

通过将这些内容标准化，任何使用 MCP 的 AI system 都可以通过任意兼容的 MCP server 理解如何请求数据、提供指令或执行动作。

由于复杂 agents 往往具有长时间运行的特征，memory management 对 agentic AI systems 至关重要。这既包括跨任务共享上下文，也包括在长时间内维护执行上下文。这里的标准方法是把 agent information 的 embedding representation 保存到向量存储数据库中，以支持 maximum inner product search（MIPS）。为了快速检索，通常使用 approximate nearest neighbors（ANN）算法，它在准确性与速度之间做权衡，返回近似 top k-nearest neighbors，同时带来显著的速度提升。关于这一主题，可以参考 Long-term Memory for Agentic AI 的相关讨论。

最后是 governance 层。我们需要确保用户针对某个任务共享的数据，或者跨任务的 user profile data，只会与相关 agents 共享，包括 table/report authentication 与 access control。至于实现良好治理所需的关键维度，如 hallucination guardrails、data quality、privacy、reproducibility、explainability、human-in-the-loop（HITL）等，可进一步参考 Responsible AI Agents 的讨论。

3. Security Patterns for Agentic Interactions

3.1 Applications to Agents

我们先定义通过 AI gateway 的 user / application 到 agent 交互安全模式。端到端基于 AI gateway 的安全架构如下图所示。

该 security pattern 包含以下组件：

• Users 和/或 applications 调用 AI agents。
• Marketplace：基于 REST 的 registry，用于发现 agents、tools 和 models，并指定 capabilities、metadata 和 endpoints。
• AI gateway：API management（APIM）layer，负责对所有交互强制执行 security、routing、throttling、guardrails。
• IAM providers：human users 使用 Entra ID，applications 使用 service principals（managed identities）。虽然 Entra ID 是 Azure 特有的，但其他平台上的等效 IAM solutions 同样适用于这里描述的安全模式。
• Memory：维护 user session context 和 conversation state，以支持 multi-turn conversations。
• (Open)telemetry：用于 monitoring、compliance 和 analytics 的集中式 logging。

上图展示了 user 通过 application / UI 到 agent 的详细安全流程，关键步骤如下：

1. User 在 business application / UI 中发起交互。
2. App 使用 authorization code + PKCE（Proof Key for Code Exchange）通过 Entra ID 对 user 进行认证。
3. Entra ID 向 app 签发 user access token。
4. App 使用 header 中的 user access token 调用 AI gateway（APIM）。
5. AI gateway 与 Entra ID 执行 on-behalf-of (OBO) exchange，获取下游 agent token；aud (audience) = agent。
6. AI gateway 验证 tokens 并强制执行 policies，例如 JWT validation、针对 agent scope 或 user role 的校验。
7. AI gateway 将带有已验证上下文的请求转发给 agent。
8. Agent 在 agent level 对 user 进行 authorization。
9. Agent 执行业务逻辑处理，然后将 response 返回给 user。
10. AI gateway 和 agent 都会将带时间戳的 invocation details 记录到 OTel platform。

3.2 Agents to MCP Tools（MCP Server and Client）

本节把前面的 user / application / UI 到 agent 安全模式扩展到 agent 到 tools 的交互，尤其针对 agent 需要调用 MCP tools 来完成功能的场景。

在最简单的形式下，MCP client 会向 authorization server 请求一个 OAuth 2.0 access token，然后再使用该 access token 调用 MCP server API。OAuth 2.0 specification 定义了从 authorization server 获取 access token 的不同流程，其中最相关的是 Token Exchange（TE）。

TE 流程可供 MCP client 在代表用户的情况下使用：用传入的 access token，即上游系统获取的 token，向 authorization server 交换出一个新的 access token。因此，当 MCP client 以用户的 on-behalf-of（OBO）方式运行，并服务近实时用例时，就会使用 TE flow。

通常，AI agents 和 MCP servers 不应把从上游系统收到的 access tokens 直接传播到下游 systems，除非它们都部署在同一个 runtime platform 中。按照 OAuth 2.0 specification，token propagation 不得跨越 application boundaries，尤其是位于不同 security domains 中的边界。

另外，在没有 user-agent context 的长时间运行 process 中，基本上是后台运行的 batch process，对应的安全流程应为 Client Credential Grant（CCG）。

CCG 是专为 machine-to-machine（M2M）communication 设计的 OAuth 2.0 flow。它允许 backend application 或 automated service 以自身名义安全认证并直接访问 resources，完全无需 human user interaction。在这种情况下，CCG flow 由嵌入在 AI agent 中的 MCP client 使用，基于自身 machine identity 从 authorization server 获取新 access token。

Security flow: AI agent (MCP client) → MCP server → MCP tools API

基于以上背景，下图展示了 reference AI agent（MCP client）与 MCP server 的交互步骤：

1. Agent 使用 access token 通过 user / application 被调用。传入的 access token 明确是为 agent 而发放的，不能用于调用其他 agents 或 MCP servers。更具体地说，token 中的 sub（subject）claim 标识原始 user，aud（audience）claim 标识 agent 是 token 的预期接收方，token 的 scope 仅对应 AI agent 所需权限。

2. AI Agent 需要调用某个 MCP server 对应的 tool 来完成功能时，不能直接把从 user / application 收到的 access token 传播给 MCP server，主要有两个关键原因：

   • Lineage：如果直接传播，下层 tool 就无法知道是 MCP server 在发起调用，它看起来会像是 application 发起的调用，从而破坏 auditability。
   • Scope：收到的 token 可能具有与 MCP server 所需不同的权限范围。因此，AI Agent 会执行 token exchange（TE）：agent 向 auth server 的 token endpoint 发起调用，并提供自身 credentials、收到的 access token、新 token 的 scope 和 audience。

3. Authorization server 验证来自 AI agent 的传入请求。如果验证通过，它会签发一个新的、限定 scope 的 access token，明确发给 MCP server。新 token 中的 sub（subject）claim 仍然标识原始 user，从而保留 user context。

4. Agent 使用交换后的 access token 调用 MCP server。正如前面提到的，由于 token propagation 存在风险，MCP server 可能还会执行另一次 token exchange 来调用下游 tools API，除非两者都部署在同一个 application / platform domain 中。

3.3 Data Retrieval from（downstream）Source Systems

本节通过聚焦 data retrieval，补全 agentic security lifecycle。也就是说，当 agents 需要从 memory、structured 或 unstructured data sources 中检索数据时，Agentic memory 也被视为一种 data storage platform，因此适用类似的安全模式。

到这里你会发现，用于 token generation、validation 和 exchange 的安全模式保持不变：只要一次交互跨域安全边界，就需要进行 token exchange。在本例中，这个边界出现在 MCP tool 与 storage platform 之间。端到端安全模式如下图所示。

4. Agentic Guardrails

到目前为止，我们主要从 authentication / authorization 角度讨论 agentic security。但所提出的流程还需要与 guardrails 集成，才能为 enterprise AI use-cases 提供更全面的 risk management harness。

与其重新创建一份 agentic risks 列表，不如整合以下两份资料中识别出的风险：

1. OWASP whitepaper：Agentic AI - Threats and Mitigations，2025
2. IBM whitepaper：Accountability and Risk Matter in Agentic AI，2025

R1–15 对应第一份资料中识别出的风险，括号中是第二份资料中对应的风险。R16 是 Persona-driven Bias，它在第二份资料中被识别出来，但在第一份资料中缺失，这一点也很有意思。

• R1: Misaligned & Deceptive Behaviors（Dynamic Deception）
• R2: Intent Breaking & Goal Manipulation（Goal Misalignment）
• R3: Tool Misuse（Tool/API Misuse）
• R4: Memory Poisoning（Agent Persistence）
• R5: Cascading Hallucination Attacks（Cascading System Attacks）

Security Vulnerabilities

• R6: Privilege Compromise
• R7: Identity Spoofing & Impersonation
• R8: Unexpected RCE & Code Attacks

Operational Resilience

• R9: Resource Overload
• R10: Repudiation & Untraceability

Multi-agent Collusion

• R11: Rogue Agents in Multi-agent Systems
• R12: Agent Communication Poisoning
• R13: Human Attacks on Multi-agent Systems

Human Oversight

• R14: Human Manipulation
• R15: Overwhelming Human in the Loop
• R16: Persona-driven Bias

从风险缓解的角度看，一个值得关注的问题是：这些缓解措施通常被交给一个中央 guardrails layer 处理，但这并不现实。Guardrails 必须与底层 use-case 高度相关，并应在各自的 platform components 或 layers 中实现，这会直接影响整体 solution architecture。

Agentic AI component 的 risk-architecture mapping 如下图所示。

5. Conclusion

尽管 agentic AI systems 的优势显而易见，但它们也是难以安全且可扩展执行的复杂系统。由于 agentic systems 的非确定性和多层架构，要覆盖 users → applications → agents → tools → (data) source systems 的安全链路，确实是一项非常有挑战性的任务。

为此，我们概述了 security patterns、architectural components、guardrails 和治理机制，目标是覆盖整个 agentic lifecycle 的 security 与 compliance。

Agentic AI security 仍处于早期阶段，但其重要性正在快速上升。随着 agents 开始执行更长的、带 memory 的任务，在 multi-agentic 场景中与 tools 协作，并处理越来越复杂的数据工作流，建议尽早基于 zero-trust 和 security best principles 将 security by design 纳入其中。这有助于提升 trust，并加速企业对 agentic workflows 的 adoption。

关于 Agentic AI 的更多架构、安全与工具链实践，也欢迎在云栈社区继续交流，例如查阅后端与架构以及安全、渗透与逆向相关主题。