MCP 不是安全边界：AI 智能体的数据级访问控制怎么做
MCP 没有死。MCP 也不是你的安全边界。第一句话修正了吸引眼球的结论，第二句话修正了代价更高的架构错误。
Model Context Protocol 的全称是模型上下文协议，不是“Model Content Protocol”。它标准化了 AI 应用发现和调用工具、资源与提示词的方式，因此能降低集成和治理成本。但它不会自动证明调用方有权读取某位客户的电话号码、修改一张发票或导出一份文档。如果一个能写代码的 AI 智能体持有更宽的凭据，还能通过 shell、SDK 或直接 API 到达同一系统，那么狭窄的 MCP 工具只是推荐路径，不是不可绕过的边界。
这一区别直接影响 CTO、创始人和安全团队采购智能体基础设施。协议可以让安全行为更容易实现，只有工作负载无法绕过的执行点，才能让不安全行为真正失败。需要 OAuth 流程和多租户实现细节时，可以继续阅读单独的企业级 MCP 授权参考架构。本文先回答更前面的问题：信任边界究竟应该放在哪里？
需要一套安全团队能批准的智能体访问控制设计？
规划生产级审查最短答案是什么？
MCP 是接口边界，授权是策略决策。真正的安全边界，是身份到每个受保护动作或数据对象之间不可绕过的执行点集合。
判断方法很简单：智能体能否通过其他路径拿到同样的数据，或造成同样的副作用？如果可以，MCP 服务器就不是完整边界。直接 API、数据库连接、浏览器会话、本地文件、消息队列和云 SDK 等替代路径，都必须执行相同或更强的控制。
| 层级 | 它定义什么 | 它不保证什么 |
|---|---|---|
| MCP | 工具、资源与提示词的发现、schema 和调用，以及可选的 HTTP 授权框架 | 下游系统中的对象级、行级或字段级权限 |
| API | 通用服务契约及其操作 | 如果没有身份与授权执行，就不保证最小权限 |
| 智能体 harness | 运行时暴露哪些工具、shell 命令和网络 | 无法保护 harness 之外可用的凭据或路径 |
| 安全边界 | 在受保护读写前不可绕过、失败即拒绝的决策 | 无法保护它没有覆盖的资源与路径 |
MCP 的设计目的，是限制 AI 智能体能做什么吗？
MCP 能帮助缩小接口，但缩小接口不等于强制限制。MCP 工具有输入 schema，客户端可以只向智能体展示与任务相关的少量工具，而不是整套 REST API。当前 MCP schema 还定义了 readOnlyHint 和 destructiveHint 等 annotation。规范明确指出，这些只是 hint。如果 annotation 来自不受信任的服务器，客户端不得据此做安全决策。
MCP 的 HTTP 授权规范增加了有价值的 OAuth 控制。Resource Indicators 让 token 面向指定 MCP 服务器，安全指南还禁止把入站 token 直接透传给下游 API。这些控制回答的是：“这个 token 是否为这台服务器签发？”它们没有完整回答：“这个主体是否能为了当前客服任务，查看客户 42 的 contact_email 字段？”
第二个问题需要业务上下文和资源上下文，应该由确定性的授权系统回答，而不是交给 prompt 或模型判断。
能写代码的智能体可以绕过 MCP 吗？
如果执行环境提供了其他可用路径和凭据，可以。如果外围系统移除或严格限制了这些路径，就不可以。
会写代码不等于自动拥有所有 API 的访问权。智能体仍然需要网络可达性、凭据、可执行工具和权限。这正是“MCP 已死”论点遗漏的部分。代码生成确实改变了威胁模型，但沙箱、出口 allowlist、工作负载身份和最小权限凭据，可以让生成的代码在批准路径之外没有实际能力。
正确结论不是“MCP 没用”，而是：不要把方便的接口误认为不可绕过的控制。MCP 对类型化发现、统一工具调用、凭据隔离和审计 hook 仍然有价值。只有当运行时无法绕开它，而且下游资源仍会再次检查授权时，它才是可信的控制点。
AI 智能体的访问控制应该放在哪里？
在可行范围内尽量靠近受保护资源，同时让前面的层级提前降低风险。“数据级访问控制”不等于某个神奇的数据库功能。它意味着最终决策包含具体对象、操作和数据分类，而且每一条访问该对象的路径都受控。
| 控制层 | 必须执行的决策 | 示例 |
|---|---|---|
| 委托身份 | 谁发起请求、哪个智能体执行、代表谁执行 | 短期 token 分开记录人类主体与智能体 actor |
| 沙箱与出口 | 哪些文件、进程、主机和协议可达 | 客服智能体能访问客户服务，不能连接生产数据库 |
| 工具或 API 策略 | 当前允许哪个操作与哪些参数 | 退款金额低于批准阈值时才能执行 |
| 对象或行策略 | 主体能读取或修改哪些具体记录 | 只返回分配给该用户客服队列的客户 |
| 字段保护 | 当前目的真正需要哪些属性 | 没有回拨权限时只返回掩码电话号码 |
| 审计与撤销 | 决策能否解释、停止和调查 | 记录主体、actor、目的、对象、字段、策略版本和结果 |
这个分层模型与成熟安全实践一致。NIST 零信任架构把保护重点从网络位置转向资源。NIST 的 ABAC 指南会同时评估主体、对象、操作与环境属性。智能体是带着上下文行动的非人实体，只要上下文没有在调用链中丢失，成熟的授权模型仍然适用。
真实客服任务中的数据级访问控制是什么样？
先看那篇热门观点中的例子：
retrieve_customer_by_email(email)狭窄的工具名听起来比通用 GET /customers endpoint 更安全，但这还不够。邮箱参数可能指向用户租户之外的客户，工具也可能返回任务根本不需要的字段。能写代码的智能体还可能直接调用底层 API，共享的服务凭据甚至可能带有管理员权限。
一条可审计的请求需要完整的决策上下文：
subject: user_184
actor: support_agent_7
purpose: resolve_ticket
action: customer.read
resource: customer_42
requested_fields: [name, plan, last_invoice_status]
tenant: acme_eu
ticket: ticket_912
environment: production
执行顺序必须是确定性的：
- 从经过验证的身份中得到 tenant、subject 和 actor，绝不能相信模型写入的参数。
- 检查工单关系，以及该用户对具体客户对象的权限。
- 只允许当前客服目的真正需要的字段。
- 即使 MCP 网关已经允许工具调用，API 与数据层仍要执行同样的检查。
- 响应中返回策略决策 ID，支持审计和撤销分析。
对于关系型数据，PostgreSQL 行级安全可以限制某个数据库角色能读取或修改哪些行。启用 RLS 却没有适用策略时，系统默认拒绝。对于共享文档和多层组织关系，OpenFGA 这类细粒度关系模型可以回答：这个用户或委托智能体，是否能对这个对象执行这个操作。它们只是实现示例，不代表必须购买某个产品。
字段级加密能让“数据本身”成为边界吗？
加密可以增强边界，但不能替代授权。
如果同一个过度授权的智能体运行时能要求密钥服务解密所有邮箱，那么静态密文并没有改变实际权限。只有当密钥释放或重新识别也绑定到经过验证的身份、目的、对象、字段和时间，而且明文只出现在最小可信组件中时，系统才真正降低了风险。
不同密码学控制适合不同任务：
- Envelope 或字段级加密：限制哪些服务与身份能够恢复敏感字段。
- Tokenization 或 pseudonymization：让大多数工作流使用稳定替代值，无需看到原值。Google Cloud 文档说明了可逆与不可逆方案。
- 脱敏与掩码：在数据到达模型前移除任务不需要的内容。
- 短期、受众绑定凭据：缩小被盗凭据的可用范围与时间。
实用原则是：先授权，再最小化，最后才解密。不要先释放一整套数据，再要求模型忽略它本来就不该看到的字段。
"狭窄的 MCP 工具有价值。只有当智能体无法绕过它，而且受保护资源会独立执行同一身份和策略时，它才真正成为边界。"
MCP 与 API 安全，应该选哪个？
通常两者都要。MCP 和 API 解决的是不同层级的问题。MCP 为智能体客户端提供标准的发现与调用契约，API 则仍然是许多 MCP 服务器背后的长期服务接口。无论选哪一个，都不能省略对象级授权。
| 场景 | 推荐形态 | 安全前提 |
|---|---|---|
| 多个智能体客户端需要同一组精选工具 | 在现有服务前增加 MCP | 网关身份加下游重新授权 |
| 一个确定性工作流只调用一个服务 | 直接 API 或 SDK 可能更简单 | 受限工作负载身份与对象策略 |
| 智能体能执行任意代码 | MCP 加沙箱和出口策略 | 没有更宽凭据，也没有绕过网络路径 |
| 字段高度敏感 | 数据代理或专用检索服务 | 字段最小化、受控解密和完整审计 |
| 多租户与多个下游系统 | MCP 网关、策略引擎和租户级数据控制 | tenant 来自验证后的 claim，绝不来自工具输入 |
OAuth 流程、audience 校验、token exchange 和租户隔离的具体实现，请继续阅读企业级 MCP 授权架构指南。需要判断知识、连接与流程层如何组合时，请看MCP、RAG、Agent Skills 与 Custom GPTs 对比。
采购 MCP 或智能体平台时，应该问哪些问题？
商业风险不取决于供应商是否有一页写着“企业级 MCP 网关”的幻灯片。你需要证据，证明它声称的边界能承受绕过测试。
- 身份传播：每一跳的日志能否区分用户、智能体、服务与下游 actor？
- 替代路径：什么机制阻止 shell 代码、浏览器自动化或直接 API 客户端使用更宽凭据？
- 授权粒度：策略能否包含工具、参数、tenant、对象、关系、字段、目的与风险？
- 失败即拒绝：策略引擎、身份提供方或密钥服务不可用时，系统会怎样处理？
- 凭据设计：token 是否短期、受众绑定，并通过交换获得下游 token，而不是直接透传？
- 数据最小化：敏感字段能否在模型推理前被掩码、tokenize 或完全移除？
- 审计证据：一个决策 ID 能否串联用户意图、策略评估、工具调用、下游 API 与返回字段？
- 撤销：某个用户、智能体、租户、服务器或策略版本多久能失去权限？
- 对抗测试：供应商是否愿意演示被拒绝的跨租户读取和直接 API 绕过？
如果答案是“prompt 告诉智能体不要这样做”，那就没有安全边界。如果答案是“MCP 工具是只读的”，请继续问哪个组件验证了这个声明。官方 MCP schema 已经提醒：工具 annotation 是提示，不是可信事实。
MCP 真的死了吗？
没有。更准确也更有用的结论是：MCP 是基础设施，不是权限本身。标准协议可以降低集成成本、让工具可发现、把部分凭据与模型隔离，并提供一致的检查点。这些能力都有价值。
真正的问题，是团队让 MCP 承担了它没有声称能完整完成的任务。MCP 无法补救管理员 token、无限制 shell、扁平多租户数据库，也无法修复只在登录时做一次授权的服务。解决方法不是丢弃 MCP，而是重新设计身份、执行与数据访问，让协议运行在真实信任边界之内。
实施检查清单
- 盘点智能体运行时到敏感数据与副作用的每一条路径。
- 移除长期管理员凭据，并隔离执行环境。
- 分别传播被委托的人类身份与智能体 actor。
- 在执行前检查工具与参数策略。
- 在下游服务的具体对象或数据行上重新授权。
- 数据到达模型前先最小化字段，再控制解密或重新识别。
- 使用短期、受众绑定 token，并为下游 audience 进行 token exchange。
- 用同一个 correlation ID 和策略决策 ID 串联完整调用链。
- 测试直接 API 绕过、跨租户读取、禁止字段与已撤销身份。
最终思考
MCP 是有价值的标准接口，但不是完整安全边界。API 是强大的服务契约，默认也不是边界。真正可执行的边界，是智能体无法绕过的一整条链：受限执行、委托身份、针对操作和参数的确定性策略、资源侧对象授权、字段最小化或受控解密，以及能证明每次决策的审计记录。先建好这条链，再在互操作性和工具生态能降低运维成本的地方使用 MCP。
主要资料
- Model Context Protocol 授权规范，2025-11-25
- Model Context Protocol 安全最佳实践
- MCP schema 中的工具 annotation
- RFC 8707，OAuth 2.0 Resource Indicators
- RFC 9700，OAuth 2.0 安全最佳实践
- NIST SP 800-207，零信任架构
- NIST SP 800-162，基于属性的访问控制
- PostgreSQL 行级安全策略
- OpenFGA 细粒度授权概览
- Google Cloud Sensitive Data Protection，假名化
- AWS Security Blog，基于 MCP 的安全智能体访问模式