面向 Enterprise AI Agents 和 MCP Tools 的安全护栏
1. Introduction
agentic AI systems 的关键特征是其自主性和推理能力，这使它们能够将复杂任务分解为更小的可执行任务，然后以一种能够在需要时监控、反思，并调整 / 自我纠正执行过程的方式来编排它们的执行。基于这一点，
agentic AI has the potential to disrupt almost every business process prevalent in an enterprise today.
所以，我们基本上可以将一切 agentify，从一个 客户服务台 到工业流程，例如 HVAC optimization；甚至可以利用 agents 来构建底层的软件、数据和 ML engineering pipelines。为了实现这一 agentification 过程，我们需要一门新的整体性学科，覆盖整个 agentic lifecycle（Fig. 1）：
从捕获 agentic use-case requirements 开始
到设计 agents（good agent hierarchy 应该是什么样子？适用的 agentic skills & tools 是什么？）
到在 agentic platform 上对它们进行 secure & scalable 实现
再到这些 agents 的治理与维护。
在这个 agentification 过程中，需要牢记的一些原则：
常见倾向是把手工流程 1-to-1 映射为 agentic 流程。这是一种 低效映射。设计者应牢记，agent 并不受例如 HR processes 的约束 :) 因此，software agent 可以做不同的事情，而且做事方式也可以不同于人类。
同时，从 security 角度看，正如人类往往是链条中最薄弱的一环，单个 agent 也可能破坏整个执行过程。因此没有例外；如果某个 agent 失控，我们也不会知道该怪谁、罚谁、解雇谁等等。所以建议以同样的最高标准设计所有 agents，并配合 logging、observability 和 responsible AI guardrails。
Today, AI agents are exposed via ad-hoc endpoints, leading to fragmented security, operational, and compliance controls.
如果没有良好架构设计的 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 的 security 方面。更具体地说，我们定义标准化且可扩展的交互安全模式，涵盖：
users → applications → agents → tools → (data) source systems。
2. Agentic AI Reference Architecture
Fig. 2 说明了 agentic AI platform 的关键组件，它们构成了第 3 节所述 security patterns 的基础：
Reasoning layer：用于分解复杂任务，并调整其执行以达成给定目标；
Agentic marketplace / registry：用于管理现有和可用的 agents、tools 和 models；
Orchestration module：用于编排和监控（observe）multi-agent systems 的执行；
Integration module：通过 MCP tools 与 enterprise systems 集成，例如 ERP、CRM、KB repositories；
用于 agents 之间数据和上下文共享的 shared memory management；
Governance layer，包括 explainability、privacy、security、安全护栏等。
给定一个 user task，agentic AI platform 的目标是识别（compose）一个能够执行该任务的 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，就需要一个 systemintegration 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”，它通过三个主要构件实现互操作性：
Resources：这是 server 可以提供给 AI 的结构化数据。例如代码片段、文档片段或数据库查询结果；任何能增加事实性上下文的内容。
Prompts：是 server 可以提供的预制指令或模板。可以理解为用于摘要文本或以特定风格生成代码的保存提示词。
Tools：指 AI 可以请求 server 执行的实际动作。在 retrieval 侧，这包括查询数据库、搜索网页等。
通过对这些内容进行标准化，任何使用 MCP 的 AI system 都可以通过任意兼容的 MCP server 理解如何请求数据（resources）、提供指令（prompts）或执行动作（tools）。
鉴于复杂 agents 的长时间运行特性，memory management 对 agentic AI systems 至关重要。
This entails both context sharing between tasks and maintaining execution context over long periods.
这里的标准方法是将 agent information 的 embedding representation 保存到向量存储数据库中，以支持 maximum inner product search (MIPS)。为了快速检索，通常使用 approximate nearest neighbors (ANN) 算法，它在准确性与速度之间进行权衡，返回近似 top k-nearest neighbors，同时带来巨大的速度提升。关于这一主题的详细讨论，请参阅我之前关于 Long-term Memory for Agentic AI 的文章。
最后是 governance 层。我们需要确保用户针对某个任务共享的数据，或者跨任务的用户 profile data；只会与相关的 agents 共享（table / report authentication 和 access control）。有关为实现良好治理的 AI agent platform 所需关键维度的讨论，包括 hallucination guardrails、data quality、privacy、reproducibility、explainability、human-in-the-loop (HITL) 等，请参阅我之前的 article on Responsible AI Agents。
3. Security Patterns for Agentic Interactions
3.1 Applications to Agents
我们首先定义通过 AI gateway 的 user / application 到 agent interaction 的安全模式。端到端基于 AI gateway 的安全架构如 Fig. 3 所示。
该 security pattern 包含以下组件：
Users 和/或 applications 调用 AI agents。
Marketplace：基于 REST 的 registry，用于发现 agents、tools 和 models，并指定 capabilities、metadata 和 endpoints。
AI gateway：API management (AMIP) layer，负责对所有交互强制执行 security、routing、throttling、guardrails。
IAM providers：我们考虑 human users 使用 Entra ID，applications 使用 service principals（managed identities）。
（尽管 Entra ID 是 Azure 特有的，但其他平台上的等效 IAM solutions 同样适用于这里描述的 security patterns。）Memory：维护 user session context 和 conversation state（用于 multi-turn conversations）。
(Open)telemetry：用于 monitoring、compliance 和 analytics 的集中式 logging。
Fig. 4 展示了详细的 user（通过 application / UI）到 agent 的安全流程，关键步骤如下：
User 在 business application / UI 中发起交互。
App 使用 authorization code + PKCE (Proof Key for Code Exchange) 通过 Entra ID 对 user 进行认证。
Entra ID 向 app 签发 user access token。
App 使用 header 中的 user access token 调用 AI gateway（APIM）
AI gateway 与 Entra ID 执行 on-behalf-of (OBO) exchange，获取下游 agent token；aud (audience) = agent.
AI gateway 验证 tokens 并强制执行 policies（JWT validation，针对 agent scope / user role）。
AI gateway 将带有已验证上下文的请求转发给 agent。
Agent 在 agent level 对 user 进行 authorization。
Agent 执行业务逻辑处理，然后将 response 返回给 user（通过 application / UI）。
AI gateway 和 agent 都会将带时间戳的 invocation details 记录到 OTel platform。
3.2 Agents to MCP Tools (MCP Server and Client)
在本节中，我们将前面的 user / application / UI 到 agent 安全模式扩展到 agent 到 tools 的 interation（通过 MCP），以适配 agent 需要调用 tools 来完成其功能的场景。
在最简单的形式下，MCP client 会向 authorization server 请求一个 OAuth 2.0 access token，然后再使用该 access token 调用 MCP server API。OAuth 2.0 specification 定义了从 authorization server 获取 OAuth 2.0 access token 的不同流程。这里最相关的流程是：Token Exchange (TE)。
该 TE 流程可供 MCP client 使用，以便在代表用户的情况下，用传入的 access token（由上游系统获取）向 authorization server 交换出一个新的 access token。
因此，当 MCP client 以用户的 on-behalf-of (OBO) 方式运行，并服务近实时用例时，就会使用 TE flow。
通常，AI agents 和 MCP servers 必须不要将从上游系统收到的 access tokens 传播到下游 systems；除非它们都部署在同一个 runtime platform 中
token propagation must not cross application boundaries, esp. those residing in different security domains according to the OAuth 2.0 specification.
请注意，在没有 user-agent context 的长时间运行 process 中，基本上是后台运行的 batch process，相关的 security flow 应为：Client Credential Grant (CCG).
CCG 是专为 machine-to-machine (M2M) communication 设计的 OAuth 2.0 flow。它允许 backend application 或 automated service 以自身名义安全地进行认证并直接访问 resources，完全消除了任何 human user interaction 的需要。在这种情况下，
the **** CCG flow is used by an MCP clien_t_ (embedded within an AI agent - Fig. 2) to obtain a new access token from an authorization server based on its own (machine) identity.
Security flow: AI agent (MCP client) → MCP server → MCP tools API
基于以上背景，我们概述 Fig. 5 中展示的一个 reference AI agent（MCP client）与 MCP server 的交互步骤：
Agent 使用 access token 通过 user / application 被调用（sub-section 3.1）。
传入的 access token 明确是为 agent 而发放的，不能用于调用其他 agents 或 MCP servers。更具体地说，token 中的 sub (subject) claim 标识原始 user。aud (audience) claim 标识 agent 为 token 的预期接收方。token 的 scope 仅对应 AI agent 所需的权限。AI Agent 需要调用一个 tool（对应的 MCP server）来完成其功能：
agent 不能仅仅把从 user / application 收到的 access token 直接传播给 MCP server，主要有两个关键原因：
- Lineage
: 如果直接传播，下层 tool（由 MCP server 调用）就无法知道是 MCP server 在发起调用。它看起来会像是 application 发起的调用——从而破坏 auditability。 - Scope
: 收到的 token 可能具有与 MCP server 所需不同的权限范围。 因此 AI Agent 会执行 token exchange (TE)：agent 向 auth server 的 token endpoint 发起调用，并提供以下信息：（自身 credentials、收到的 access token、新 token 的 scope 和 audience）。
Authorization server 验证来自 AI agent 的传入请求。如果验证通过，它会签发一个新的、限 scope 的 access token，明确发给 MCP server。新 token 中的 sub (subject) claim 仍然标识原始 user——从而保留 user context。
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 中检索数据时 - 请参见 Fig. 3_. (_Agentic memory 也被视为一种 data storage platform，因此适用类似的 security patterns。)
如你现在应该已经注意到的那样，用于 token generation、validation 和 exchange 的 security pattern 保持不变；只要一次交互（在本例中是 MCP tool 与 storage platform 之间）跨越 security domains，就需要进行 token exchange。端到端 security pattern 如 Fig. 6 所示。
4. Agentic Guardrails
到目前为止，我们主要从 authentication / authorization 的角度关注了 agentic security，而所提出的流程需要与 guardrails 集成，以便为 enterprise AI use-cases 提供更全面的 risk management harness。
与其创建一份新的 agentic risks 列表，我尝试整合下面两个参考资料中识别出的风险：
OWASP whitepaper：Agentic AI - Threats and Mitigations, 2025。
IBM whitepaper：Accountability and Risk Matter in Agentic AI, 2025。
R1–15 指的是 [1] 中识别出的风险。括号 () 中的是 [2] 中对应的风险。R16：Persona-driven Bias，例如，这一点非常有意思，它已在 [2] 中被识别，但在 [1] 中缺失。
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 need to be specific to the underlying use-case, and implemented in their respective platform components / layers - which has a direct impact on the overall solution architecture.
agentic AI component 的 risk-architecture mapping 如 Fig. 7 所示。
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。