摘要：MCP Server 进入企业生产环境后，最重要的问题已经不是“Claude、Codex、Copilot 能不能连上”，而是“谁能访问哪个 Server、能调用哪些 Tool、Token 是否只对目标资源有效、高风险操作是否需要审批、出了问题能不能完整追溯”。MCP 2026-07-28 进一步强化了授权模型：请求可通过 Mcp-Method / Mcp-Name 在 Gateway 层路由和授权，OAuth 侧增加 issuer 校验、凭据 issuer 绑定，并继续推动最小 Scope 与集中式企业授权。2026 年 6 月稳定的 Enterprise-Managed Authorization（EMA）又允许企业通过 IdP 统一决定员工可以访问哪些 MCP Server。本文从架构、OAuth、Scope、RBAC/ABAC、Tool Policy、审批、Token Audience、SSRF、本地 Server、状态句柄、审计日志、SIEM 与事件响应入手，给出一套可以直接用于企业 MCP Server 的权限、安全与审计配置方案。
核心结论
企业 MCP Server 的安全边界不能只放在 System Prompt 或客户端确认框里，而要落实到身份、Token、Scope、Tool Policy、数据权限、网络、审批和审计七个确定性控制层。最推荐的落地方式是：企业 IdP/SSO 负责“你是谁”，OAuth Scope + Server Policy 负责“你能做什么”，Tool Schema 与业务 ACL 负责“你能操作哪些对象”，高风险动作通过 Human-in-the-loop 再确认，所有调用通过 Gateway 与 OpenTelemetry/SIEM 留下可追溯证据。
- 身份统一：公网 MCP 优先 OAuth 2.1；企业规模化部署优先评估 Enterprise-Managed Authorization，让 IdP 成为统一策略入口。
- 权限最小化：不要使用
*、all、full-access一类万能 Scope；读取、写入、删除、部署、发送应拆开。 - Token 必须绑定资源：MCP Server 必须验证 Token 是为自己签发的，禁止把客户端 Token 原样透传给下游 API。
- Tool 调用必须二次授权：有 Scope 不等于任何参数都能执行，还要检查 tenant、resource、金额、仓库、目录、域名和环境。
- 审计必须贯穿全链路：不仅记“用户登录”，还要记录 Server、Tool、目标资源、授权结果、审批、结果状态和关联 Trace ID，同时绝不能记录 Token 和 Secret。
如果企业还没有建立 AI 权限与审计框架，可以先参考 AI Stack Nav 的 企业使用 AI 工具前必须懂的权限、账单、数据和审计问题；如果是研发团队使用 Claude Code 或其他 Coding Agent 接入 MCP，可结合 Claude Code 权限与 MCP 安全配置教程 一并制定规则。
背景与主要变化：2026-07-28 为什么让企业 MCP 更容易治理
MCP 2026-07-28 把协议核心改为无状态请求/响应，移除了旧的协议级 Session，并把每次请求需要的版本、客户端信息和能力放到请求自身。对安全团队最直接的变化，是 HTTP Header 现在能携带 Mcp-Method 和适用场景下的 Mcp-Name，因此 API Gateway、WAF、Rate Limiter 和审计系统可以在不解析完整 JSON Body 的情况下，根据“调用的是 tools/call 还是 resources/read”“调用的是 search 还是 deploy”执行路由、限流、策略和日志。
同一版本还强化了 Authorization：Authorization Server 应返回 iss，Client 需要验证 issuer；客户端注册凭据要与签发它的 issuer 绑定，不能跨 Authorization Server 复用；DCR 已进入向 Client ID Metadata Documents（CIMD）迁移的路径。这些变化本质上都是在减少“同一个客户端同时连接很多 Server/IdP”时的身份混淆风险。
| 治理层 | 传统做法 | 企业 MCP 推荐做法 | 核心目的 |
|---|---|---|---|
| 身份 | 个人 Token / API Key | 企业 IdP + OAuth / EMA | 可入职、离职、分组和撤销 |
| Scope | 一次给全权限 | Baseline Scope + Step-up | 减小 Token 泄露爆炸半径 |
| Tool 权限 | Agent 有 Tool 就能调 | Scope + Policy + 资源级 ACL | 阻止越权参数和横向访问 |
| 高风险动作 | 靠 Prompt 约束 | 强制审批 / 二次确认 | 防止误删、误发、误部署 |
| 审计 | 普通应用日志 | 结构化事件 + Trace + SIEM | 事件可追溯、可告警 |
统一身份：企业不要让个人账号成为 MCP 权限根
企业 MCP 最先要解决“谁在调用”。如果员工各自把个人 GitHub、个人 Google、个人 SaaS Token 接到工作用 Agent，企业既无法统一撤销，也无法稳定区分个人和企业数据。MCP 的 Enterprise-Managed Authorization（EMA）扩展已经稳定，它允许组织把企业 IdP 设为 MCP Server 访问的权威策略来源，由管理员统一配置哪些用户、组和角色可以连接哪些 Server。
EMA 的价值不只是 SSO。它把入职、岗位变更和离职流程直接纳入 MCP：管理员在 IdP 中修改组或 Role，访问策略可以集中生效，不需要员工去每个 MCP Client、每个 Server 手工撤销授权。对于需要 SOC 2、ISO 27001、金融审计或内部安全审批的组织，这比“员工自己点 OAuth Consent”更适合规模化治理。
第一步：设计最小 Scope，不要把 MCP 权限做成万能开关
MCP 官方 Security Best Practices 当前专门增加了 Scope Minimization 指导，指出广泛 Scope 会扩大 Token 泄露后的影响、降低审计可读性并产生权限链式升级。企业最推荐的是“低风险基线 + 按操作 Step-up”。例如 GitHub MCP 不应只设计 github:full-access，而应拆成 github:repo:read、github:issue:write、github:merge、github:admin；文件系统也应拆成 list/read/create/update/delete/share_external。
用户第一次连接只拿低风险 Scope。当 Agent 第一次尝试写文件时，Server 返回 403，并只挑战当前操作真正需要的权限：
HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer
error="insufficient_scope",
scope="files:update",
resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"
这种 Step-up 比登录时一次授权“读、写、删、分享、发布全部权限”更符合最小权限原则。企业还应给 Scope 做版本管理，避免同名 Scope 在后台悄悄扩大语义。
第二步：Token 必须校验 Audience，禁止 Token Passthrough
MCP Authorization 要求 Client 在授权请求和 Token 请求中使用 RFC 8707 的 resource 参数标识目标 MCP Server，Server 必须验证收到的 Token 的确是为自己签发的。错误做法是把 MCP Client 给 Server 的用户 Token 原样转发给 GitHub、CRM 或内部 API；正确做法是 MCP Server 收到面向自身的 Token A，再以自己作为 OAuth Client 或服务身份向下游获取 Token B。
MCP Client
↓ token A：aud = MCP Server
MCP Server
↓ 独立 OAuth Client / service identity
Downstream API
↓ token B：aud = Downstream API
Token Validation 至少应检查签名、issuer、audience/resource、expiration、Scope 和当前 Subject 状态。生产环境不要手写完整 OAuth/JWT 校验器，应使用成熟、经过验证的库。
第三步：Scope 通过后，还要做 Tool 与资源级授权
拥有 github:issue:write 不代表用户可以修改企业所有仓库的 Issue。MCP Server 至少应执行两层判断：第一层 Scope Gate 判断“能不能调用这一类 Tool”；第二层 Resource Gate 判断“能不能对这个具体对象执行”。
{
"principal": {
"subject": "user_2381",
"tenant_id": "corp_001",
"groups": ["engineering", "platform"],
"roles": ["developer"]
},
"request": {
"mcp_method": "tools/call",
"tool": "update_issue"
},
"resource": {
"repository": "finance/core-api",
"environment": "production"
}
}
Policy Engine 可以返回 allow、deny 或 require_approval。这里真正的权限判断必须由代码、IAM 或 Policy Engine 完成，而不是让 LLM 根据自然语言决定。
第四步：利用 Mcp-Method / Mcp-Name 在 Gateway 做第一道 Gate
MCP 2026-07-28 的 Header 路由让 Gateway 可以针对不同 Tool 做粗粒度策略。例如 tools/list 允许普通认证用户，tools/call + search 设置普通限流，tools/call + deploy 只允许发布组，并要求 MFA/Change Ticket。Gateway 很适合做 WAF、速率限制、Server Allowlist 和第一层审计，但它不能替代 Server 内部的 Token、Scope 和资源级授权。
| MCP 请求 | Gateway 策略 | 示例 |
|---|---|---|
tools/list | 低风险认证 | 每用户 60/min |
tools/call + search | 普通限流 | 300/min |
tools/call + delete_file | 受管身份 + 审批 | 非生产 Client 拒绝 |
tools/call + deploy | 发布组专用 | MFA + Change Ticket |
第五步：高风险 Tool 强制 Human-in-the-loop
企业建议给 Tool 建立风险等级。R1 读取公开数据可以自动执行；R2 读取企业内部数据需要权限与 DLP；R3 写数据库、发邮件、修改 Issue 需要强日志和可回滚；R4 删除、付款、部署、权限变更、对外发布必须人工审批。
审批页不要只显示“AI 要调用 deploy”。应显示用户、Client、Tool、目标环境、关键参数、权限来源、风险理由、预计影响和关联工单。审批结果本身也要进入 Audit Event。
第六步：状态 Handle 不能当身份凭证
2026-07-28 MCP 没有协议级 Session。Server 如果需要跨请求保存状态，会使用 workflow_id、task_id 等显式 handle。官方 Security Best Practices 明确提醒：拥有 handle 不代表拥有权限。handle 应随机、不可预测、可过期，并在 Server 端绑定已经验证的用户 Subject/Tenant。
SELECT *
FROM workflows
WHERE tenant_id = :tenant_id
AND owner_subject = :subject
AND handle = :handle
AND expires_at > now();
第七步：处理 SSRF、Redirect 与网络出口
MCP Authorization Discovery 会访问 Protected Resource Metadata、Authorization Server Metadata 和 Token Endpoint。如果恶意 MCP Server 提供内网 IP、云 Metadata、localhost 或 DNS Rebinding 地址，服务器侧 Client 可能变成 SSRF 跳板。
- 远程 MCP 和 OAuth URL 生产环境强制 HTTPS。
- 默认阻止 RFC1918 私网、loopback、link-local、云 Metadata 地址。
- Redirect 每一跳重新校验，不盲目自动跟随。
- Server-side Client 使用 Egress Proxy / Network Policy。
- 处理 DNS Rebinding / TOCTOU，而不是只在第一次解析 IP 时检查。
- 授权发现网络与业务 Tool 网络尽量分离。
第八步：本地 stdio MCP 也要纳入企业 Allowlist
本地 MCP Server 是与 MCP Client 同用户权限运行的可执行程序。如果开发者从未知仓库复制 npx 或 Shell 安装命令，它可能读取 SSH Key、Home、环境变量或访问网络。企业应登记批准 Server 的来源、版本、Hash、启动命令、允许目录、网络域名和环境变量，并优先运行在 Sandbox/容器中。
如果一个 Server 只需要当前项目目录，就不应让它读取整个 ~/.ssh 或浏览器 Profile。可以结合 AI Stack Nav 的 Codex 权限安全与 AGENTS.md 教程，把 MCP Server 与 Coding Agent 的终端、文件权限统一治理。
第九步：审计日志应该记录什么
MCP 2026-07-28 已把旧 Logging 能力放入弃用路径，官方路线更偏向 stderr（stdio）和 OpenTelemetry 等结构化 Observability。MCP 并没有强制统一企业审计字段，所以下面是一套工程模板，而不是协议规定。
{
"timestamp": "2026-08-13T20:05:11Z",
"trace_id": "8ad7...",
"request_id": "req_9281",
"principal": {
"subject": "user_2381",
"tenant_id": "corp_001",
"auth_type": "enterprise_managed_authorization"
},
"mcp": {
"protocol_version": "2026-07-28",
"method": "tools/call",
"tool": "deploy"
},
"authorization": {
"required_scope": ["deploy:production"],
"decision": "require_approval",
"policy_id": "prod-deploy-v4"
},
"resource": {
"id": "payments-api",
"environment": "production"
},
"approval": {
"required": true,
"approver": "user_812",
"ticket": "CHG-20419"
},
"result": {
"status": "success",
"duration_ms": 1824
}
}
绝不能记录 Access Token、Refresh Token、Authorization Code、Client Secret、数据库密码和 API Key。Prompt 与 Tool 参数是否记录，则应根据数据分级做脱敏、摘要或完全不留正文。
第十步：OpenTelemetry + SIEM 形成全链路证据
OpenTelemetry 更适合 Trace/Metric/Log，SIEM 更适合长期安全调查、规则告警与身份关联。推荐让 Gateway、MCP Server、Policy Engine、Approval Service 和下游 API 共用 Trace ID，然后由 Collector 同时输出到 APM 和 SIEM。
典型告警包括：短时间大量 403 insufficient_scope、首次调用 R4 Tool、异常时间批量读取、Audience/Issuer 校验失败、SSRF 命中、State Handle 越权、未经批准的 Server 版本变化等。
第十一步：RBAC + ABAC + Tool Policy 配置模板
policies:
- id: repo-read
effect: allow
when:
group: engineering
tool: github_repo_read
- id: prod-deploy
effect: require_approval
when:
group: platform
tool: deploy
environment: production
require:
scope: deploy:production
mfa: true
change_ticket: true
approver_role: release-manager
- id: destructive-default-deny
effect: deny
when:
risk_tier: R4
approval: missing
这种 Policy 可以由 OPA、API Gateway、自研 IAM 或 IdP 条件访问实现。重点是策略必须在 Tool 真正执行前进行，并把决策结果写入审计。
第十二步：企业完整上线流程
- 建立 MCP Server Inventory：Owner、用途、环境、Transport、数据分类和风险等级。
- 统一企业身份：SSO/IdP，条件成熟时评估 EMA。
- 拆分 Scope：从只读基线开始，按操作 Step-up。
- 配置 Token Audience 与 issuer 校验。
- 建立 Tool Policy：Scope 后继续校验 tenant、resource、environment 和参数。
- 给 Tool 做风险分级，R4 强制审批。
- 配置 Gateway：Mcp-Method/Mcp-Name、WAF、Rate Limit、Allowlist。
- 配置 Egress 与 SSRF Protection。
- 建立本地 stdio Server Allowlist 与 Sandbox。
- 统一 Audit Schema 与 Trace ID。
- 接入 SIEM，配置高风险调用和授权失败告警。
- 执行越权、Token 混用、SSRF、Handle Hijacking 与 Prompt Injection 红队测试。
- 小范围灰度：先只读，再开放写入和高风险动作。
企业红队测试清单
| 测试 | 预期结果 |
|---|---|
| 拿 CRM Token 请求 GitHub MCP | Audience 校验失败 |
| 只有 files:read 调用 delete_file | 403 insufficient_scope |
| 用户 A 使用用户 B 的 workflow handle | 拒绝并产生安全事件 |
| OAuth Metadata 指向 169.254.169.254 | SSRF Protection 阻断 |
| 低权限组调用生产 deploy | Deny 或 Require Approval |
| Tool 参数访问其他 tenant | 资源级 ACL 阻断 |
| 日志中搜索 Bearer Token | 不应存在真实 Token |
对比与选型建议
| 场景 | 推荐方案 | 说明 |
|---|---|---|
| 个人/小团队远程 MCP | 标准 OAuth 2.1 + 最小 Scope | 先保证 Token、Audience、HTTPS 正确 |
| 中型企业 | 企业 SSO + OAuth + Gateway Policy | 集中身份与 Tool Policy |
| 大型多 MCP 企业 | EMA + IdP + Gateway + SIEM | 统一入离职、组策略和审计 |
| 高风险自动化 | 以上能力 + Approval Service | 部署、付款、删除等强制审批 |
| 本地开发 MCP | stdio + Allowlist + Sandbox | 本地进程也纳入企业治理 |
风险、限制与注意事项
EMA 不是自动安全。它解决集中身份与授权入口，但 Server 仍要执行 Tool 和资源级权限。Scope 也不是业务 ACL。拥有 db:write 不代表可以写所有数据库。Mcp-Name 不是可信身份。Header 很适合 Gateway 路由，但最终授权仍依赖 Token 和 Server Policy。
Audit Log 自身也属于敏感数据。它包含员工身份、资源 ID、调用时间和业务结果，应设置访问权限、保留周期、防篡改与最小化采集。安全团队还要持续观察 Scope Step-up 频率和审批耗时，避免权限太细导致员工转向未经治理的旁路工具。
第十三步：Secrets、服务账号与环境隔离怎么做
MCP Server 的安全配置经常在 OAuth 层做得很完整，却在下游 Credentials 上失守。例如 Server 为了调用数据库、GitHub、CRM 或内部 API，直接把管理员 Token 放进环境变量，并让所有 Tool 共用。这会造成一个严重问题：用户虽然只有低权限 Scope，但 MCP Server 在下游却拥有超级权限，一旦 Tool Policy 或代码出现漏洞，真正的爆炸半径由 Server Credential 决定。
推荐采用“三层身份”：
- 终端用户身份：来自 OAuth/EMA，用于判断是谁发起请求。
- MCP Server 服务身份：用于调用企业基础设施，但权限仅覆盖 Server 自身。
- 下游任务身份：高风险系统尽量使用 On-behalf-of、短期 STS Token 或按项目/租户派生的临时凭据，而不是共享长期管理员 Token。
开发、测试、生产必须使用不同 Credential。测试 Agent 不应持有生产数据库密码；生产 MCP Server 也不应继承开发者个人 GitHub PAT。Secret 应进入 Vault、云 Secret Manager、KMS 或受控环境注入，禁止写入 Git、.mcp.json、Dockerfile 和普通日志。
第十四步：Tool Schema、输入校验与“危险参数”控制
Tool 的权限不仅体现在“能不能调用”，还体现在参数能表达多大的操作空间。一个名为 execute_sql、参数只有自由文本 query 的 Tool，即使 Scope 是 db:read，也很难保证它永远只读；一个 http_request(url, method, body) Tool 几乎等价于把任意网络能力交给 Agent。
企业应尽量把通用 Tool 拆成窄 Tool，并利用完整 JSON Schema 限制参数：
{
"name": "get_customer_order",
"inputSchema": {
"type": "object",
"properties": {
"customer_id": {
"type": "string",
"pattern": "^cus_[A-Za-z0-9]+$"
},
"limit": {
"type": "integer",
"minimum": 1,
"maximum": 50
}
},
"required": ["customer_id"],
"additionalProperties": false
}
}
文件 Tool 应使用内部 file_id，而不是自由绝对路径；数据库 Tool 应选择预定义操作，而不是自由 SQL；网络 Tool 应限制协议、域名和方法；金额、数量、时间范围都设置上限。Schema 是第一层，Server 端仍要重新验证，因为不能假设 Client 或模型一定严格遵守 Schema。
第十五步：MCP Server 变更也必须纳入企业 Change Management
企业安全不仅要审“谁调用了 Tool”，还要审“Tool 本身什么时候变了”。一个原本只读的 search_customer 如果升级后新增写入副作用，客户端仍可能沿用旧信任判断。建议给 MCP Server 建立版本化发布流程：
- Server 新版本先进入测试 Registry。
- 比较
tools/list前后差异：新增、删除、描述、Schema、风险等级。 - 权限团队审查 Scope 是否新增或扩大。
- 安全测试高风险 Tool、SSRF、跨租户和 Prompt Injection。
- 生成 SBOM、镜像签名或包来源证明。
- 通过审批后进入生产 Registry。
- 生产客户端只允许受管版本范围。
对于本地 stdio Server，尤其要锁定 npm/pip/二进制版本，不能长期使用“每次启动自动拉最新版”。否则某次上游更新就可能在没有企业审批的情况下改变 Tool 行为。
第十六步：Rate Limit、配额与异常循环控制
Agent 与普通 API Client 的差异之一，是它可能因为模型循环、重试或错误规划在短时间内重复调用 Tool。权限正确不代表资源不会被耗尽，因此企业 MCP 还需要 Usage Governance。
| 控制项 | 建议维度 | 用途 |
|---|---|---|
| Rate Limit | subject + tool | 阻止单用户异常爆量 |
| Concurrency | tenant + risk tier | 限制并发高风险动作 |
| Daily Quota | department / project | 控制成本与数据读取量 |
| Retry Budget | request / workflow | 防止 Agent 无限重试 |
| Data Volume | rows / files / bytes | 限制批量外带数据 |
例如一次客户查询最多返回 50 条、单用户每分钟最多调用 20 次敏感搜索、一次 Workflow 最多自动重试 3 次。超过阈值时应失败并提示人工处理，而不是允许模型“换一个 Prompt 再试”。
第十七步：事故响应——发现异常 MCP 调用后怎么处置
企业要在上线前就定义 MCP Security Incident Runbook。真正发生 Token 泄露、越权访问或恶意 Server 时，不能临时讨论“先关哪个系统”。建议采用以下顺序：
- 阻断：禁用 Server、Tool、Client 或相关 Scope，必要时在 Gateway 直接拦截。
- 撤销：Revoke Access Token / Refresh Token、下游 Service Credential，并在 IdP 移除用户访问。
- 保全证据：冻结相关 Trace、Audit Event、Policy Decision、Approval 与版本信息。
- 分析影响：确认访问了哪些资源、是否跨 tenant、是否存在外发/写入/删除。
- 检查持久化：排查 Agent Memory、缓存、任务 Handle、队列和下游系统是否留下恶意状态。
- 恢复：从可信版本重新启用 Server，重新签发 Credential。
- 回归：把事件转成自动化测试和 SIEM Rule，防止同类问题再次发生。
如果企业的 MCP 连接了 GitHub、数据库、邮箱和 CRM，事件调查需要跨系统关联；这也是为什么每次 Tool Call 都应该有统一 Trace ID 和稳定 Subject ID，而不能只记录一行“tool call failed”。
第十八步：审计完整性与日志访问权限
“有日志”不等于“可审计”。如果 MCP Server 管理员可以随意删除本地日志，或者不同系统时间不同步，事故后仍然无法还原真实过程。企业可以增加：
- 集中 Collector，Server 不作为唯一日志存储。
- 生产节点只允许追加或转发，不允许普通应用账号删除安全日志。
- 统一 NTP/时间源，所有事件使用 UTC 时间戳。
- 关键 Audit Event 写入不可变存储或启用 WORM/Retention Lock。
- 审计日志读取本身也记录审计，限制安全、合规和授权调查人员访问。
- 对高敏感字段做字段级脱敏，不允许“为了审计”无限采集。
企业最好同时定义三种日志：应用日志用于排错，Observability 用于性能和 Trace，Security Audit 用于访问、权限、审批与事件调查。三者可以共享 Trace ID，但保存周期和访问权限不必相同。
事实依据与来源
内容核验日期：2026-08-13。
MCP 2026-07-28 官方已确认：新规范采用无状态核心，支持通过 Mcp-Method 和 Mcp-Name Header 进行路由与计量，并进一步强化 Authorization，包括 RFC 9207 issuer 校验、客户端凭据与 issuer 绑定，以及从 DCR 向 CIMD 迁移。参见 MCP 官方：The 2026-07-28 Specification。
OAuth 与 Scope 官方已确认：MCP Authorization 采用 OAuth 2.1 模型，要求客户端使用 RFC 8707 Resource Indicators，Server 验证 Token 针对自身资源；官方安全文档明确禁止 Token Passthrough，并建议使用短生命周期 Token、HTTPS、最小权限 Scope 与运行时 Step-up Authorization。参见 MCP：Understanding Authorization 与 MCP：Security Best Practices。
Enterprise-Managed Authorization 官方已确认：EMA 扩展已于 2026 年 6 月稳定，允许企业 IdP 集中维护批准 MCP Server 和访问策略，按 Group、Role 与条件访问规则授权，并支持集中撤销与统一审计。参见 MCP：Enterprise-Managed Authorization。
编辑实施建议：本文的风险分级、Audit Event JSON、RBAC+ABAC YAML、SIEM 告警规则、Server Inventory 与 13 步上线流程属于基于官方协议整理的企业工程模板，并非 MCP 规范强制格式。不同企业应根据 IdP、网关、SIEM、行业合规和数据等级调整。
仍需核实：EMA 属 MCP Extension，客户端、Server 和 IdP 的实际支持情况可能继续变化；上线前应再次检查所用 MCP Client、Server 和企业身份平台是否支持当前扩展版本。
FAQ
1. MCP Server 企业环境一定要使用 OAuth 吗？
远程 HTTP MCP 如果涉及用户数据、企业 API 或需要区分用户权限，强烈建议使用标准 OAuth 授权模型。stdio 本地 Server 不使用同一套远程 OAuth 流程，但仍需要环境变量、Sandbox、文件和网络权限控制。
2. Enterprise-Managed Authorization 和普通 OAuth 有什么区别？
普通 OAuth 通常由每个用户分别授权每个 MCP Server；EMA 把企业 IdP 变成集中策略入口，管理员可以统一控制员工能访问哪些 Server，并通过企业组、Role 和条件访问规则决定权限，更适合规模化企业管理。
3. 已经有 Scope，为什么还需要 RBAC/ABAC？
Scope 只能说明 Token 拥有哪些能力，不能表达所有业务对象权限。例如拥有 files:update 的用户仍可能只能修改某个部门文件夹。资源级 ACL/RBAC/ABAC 必须由 MCP Server 再次校验。
4. MCP Server 可以直接把用户 Token 转给 GitHub、CRM 吗？
不应该。MCP 官方明确禁止 Token Passthrough。Client 给 MCP Server 的 Token 应以 MCP Server 为 Audience；Server 调用下游 API 时应使用为下游 Resource 单独签发的 Token 或服务身份。
5. MCP 审计日志要不要记录 Prompt 和 Tool 参数？
应根据数据分类决定。身份、Tool 名、资源 ID、授权结果和执行状态通常应记录；完整 Prompt 和 Tool 参数可能包含敏感数据，需要脱敏、最小化或只保留 Hash/摘要。任何情况下都不应记录 Access Token、Refresh Token 或 Secret。
6. 如何防止一个用户拿到另一个用户的任务 handle？
handle 必须随机、可过期，并在 Server 端绑定经过 Token 验证的 Subject/Tenant。每次请求都重新验证“当前 caller 是否拥有该 handle”，不能把 handle 本身当成身份凭证。
7. 本地 stdio MCP 为什么也有安全风险？
因为 stdio Server 是本地可执行进程，通常拥有与 MCP Client 相同的用户权限。恶意安装命令或第三方包可能读取文件、密钥和网络。企业应建立 Server Allowlist、版本锁定、目录权限和 Sandbox。
8. Gateway 有 Mcp-Method / Mcp-Name 后，还需要 Server 内授权吗？
需要。Gateway 适合做第一层路由、限流和粗粒度策略，但 Server 仍必须验证 Token、Scope、Tool 参数和具体资源权限。安全决策不能只依赖客户端可见的 Header。
9. MCP Server 的审计日志应该保存多久？
没有统一 MCP 标准。应根据企业的安全事件响应、行业法规、隐私要求和存储成本制定，同时为日志本身设置访问控制和删除政策。
参考来源
- Model Context Protocol：The 2026-07-28 Specification
- Model Context Protocol：Understanding Authorization in MCP
- Model Context Protocol：Security Best Practices
- Model Context Protocol：Enterprise-Managed Authorization
- IETF RFC 8707：Resource Indicators for OAuth 2.0
环境配置与 Docker 工作流
适合阅读安装部署、本地配置、服务器搭建和自动化流程类文章后继续转化。
