每个Agent都需要独立身份：KYA、MCP与Secretless Access怎么结合？

摘要： 企业部署多个 AI Agent 后，如果所有 Agent 共用一个服务账号或 API Key，审计日志只能证明“某个密钥调用了系统”，却无法回答是哪个 Agent、受谁委托、为何执行以及权限是否仍然有效。解决办法不是单独购买一个密钥保险箱，而是把 KYA（Know Your Agent）、MCP 授权与 Secretless Access 组合成三层控制：KYA 建立 Agent 身份档案和责任关系，MCP 规范 Agent 如何发现并访问工具，Secretless Access 依据已验证的工作负载身份按任务签发短期凭证。本文给出企业级架构、身份字段、OAuth/MCP流程、策略示例、90天落地步骤和风险边界。KYA目前仍是新兴治理框架，并非统一国际标准，企业应把它作为内部控制模型实施，而不是宣称已经满足某项不存在的认证。

核心结论

KYA、MCP 与 Secretless Access 的正确组合方式是：先用 KYA 回答“这个 Agent 是谁、属于谁、允许做什么”，再由 MCP 提供标准化工具连接和 OAuth 授权流程，最后用工作负载身份与短期令牌消除 Agent 持有长期密钥。三者分别对应治理、协议和凭证执行层，不能互相替代。

• 每个生产 Agent 都应有稳定且唯一的身份，不能只用模型名称、Prompt 名称或共享服务账号充当身份。
• KYA 是治理框架，不是现成认证协议：它需要记录所有者、用途、版本、模型、工具、数据、风险、审批人和生命周期。
• MCP 解决工具互操作与授权传输：远程 HTTP MCP 可依据 OAuth 2.1、受保护资源元数据、资源指示符和受众校验工作，但 MCP 本身不会自动判断业务动作是否合理。
• Secretless 不等于“系统里完全没有Secret”：核心是 Agent 不保存、看不到长期凭证，信任系统在运行时基于身份签发短期、限范围令牌。
• 最稳妥架构是双重身份链：同时保留发起任务的人类身份和实际执行的 Agent 身份，在每次工具调用中记录委托关系、任务、权限、凭证和结果。

为什么共享账号会让Agent治理失效

结论是：当多个 Agent 共用一个账号时，认证看似成功，问责却已经失败。

假设“客服Agent”“财务Agent”和“研发Agent”都通过同一个 automation@company 账号访问 CRM、网盘和 GitHub。当出现异常删除、敏感文件下载或错误合并时，日志只能看到相同主体。安全团队无法快速判断是模型误判、恶意提示注入、错误的工具路由、某个版本缺陷，还是人类操作员主动触发。

共享身份还会带来权限膨胀。为了让不同 Agent 都能工作，共享账号往往被赋予所有工具权限；一个只需读取知识库的 Agent，也间接获得写入 CRM 或部署生产系统的能力。一旦任一 Agent、MCP Server、日志平台或配置文件泄露密钥，攻击者获得的是所有能力的并集。

独立身份的价值不只是“日志更好看”，而是让企业实现四件事：按 Agent 最小授权、按任务签发凭证、按风险实时阻断、按单个 Agent 撤销权限。身份因此成为 Agent 控制面的主键。

KYA是什么：先认清概念成熟度

结论是：KYA 可以理解为“了解你的智能体”，用于持续证明 Agent 的来源、所有权、用途、能力和风险，但截至本文核验日期，它并不是像 OAuth、OpenID Connect 或 SPIFFE 那样具有单一权威规范的成熟标准。

2026 年以来，多家身份验证与安全机构使用 Know Your Agent 这一名称，常见定义包括：确认交互主体是否为 Agent；把 Agent 绑定到负责的人或组织；了解其用途、权限与运行环境；持续监测行为和风险。不同厂商的字段与产品实现并不完全一致，因此文章中的 KYA 清单属于综合治理建议，不代表某个官方标准。

企业可以把 KYA 看作 Agent 的“工商档案＋岗位说明书＋风险档案”。最低应回答：

KYA问题	必要字段	不合格示例
它是谁	agent_id、名称、版本、签名或证明	只写“GPT助手”
谁负责	业务Owner、技术Owner、安全审批人	只登记供应商
为何存在	明确业务用途、允许任务、禁止任务	“提高效率”
在哪里运行	环境、集群、工作负载身份、地域	不知道实际运行位置
能访问什么	MCP Server、工具、数据分类、Scopes	使用超级管理员账号
受谁委托	人类或上游Agent、任务ID、授权链	日志只记录最终账号
如何验证	评测集、策略版本、批准记录	只展示成功Demo
何时失效	到期、暂停、撤销、下线条件	永久有效

KYA 不应只在上线前填写一次。Agent 的模型、Prompt、Skills、工具和权限变化都可能改变风险，因此重大版本升级、Owner 变更、工具新增或异常行为出现时，应重新认证或提升审核等级。

独立Agent身份应该长什么样

结论是：生产 Agent 的身份应独立于模型、运行实例和人类用户，同时与它们建立可验证关联。

模型 ID 不能作为 Agent ID，因为同一模型可以服务数百个 Agent；容器 ID 也不适合作为长期业务身份，因为实例会重建；服务账号如果被多个 Agent 共享，同样无法精确归因。建议使用稳定的业务身份作为主标识，再为每次运行签发工作负载证明和任务凭证。

一个精简身份档案可以采用如下结构：

agent:
  id: agent://finance/invoice-reviewer/v3
  name: invoice-reviewer
  version: 3.2.1
  environment: production
  owners:
    business: finance-operations
    technical: agent-platform-team
    security_approver: iam-team
  purpose:
    allowed:
      - read_invoice
      - match_purchase_order
      - create_review_draft
    prohibited:
      - approve_payment
      - change_supplier_bank_account
  runtime:
    workload_id: spiffe://example.com/ns/finance/sa/invoice-agent
    model_policy: finance-approved-models
  mcp:
    servers:
      - finance-tools
    scopes:
      - invoices:read
      - review:draft
  risk:
    level: high
    human_approval: payment_related
  lifecycle:
    expires_at: 2026-12-31T23:59:59Z

这里同时包含稳定 Agent ID 与运行时工作负载 ID。前者用于资产盘点、Owner和政策绑定；后者证明“当前发起请求的进程确实在被批准的运行环境中”。一次具体任务还应生成唯一 task_id，把发起用户、Agent、会话和工具调用串联起来。

MCP负责什么，又不负责什么

结论是：MCP标准化了Host、Client与Server之间的资源、提示和工具交互，并为HTTP传输定义了OAuth授权框架，但业务级权限、Agent注册和风险决策仍需企业控制面补充。

MCP 2025-11-25 授权规范将受保护 MCP Server 视为 OAuth 2.1 资源服务器，MCP Client 作为 OAuth 客户端。MCP Server 通过 OAuth 2.0 Protected Resource Metadata 表明授权服务器位置；客户端发现授权服务器后请求令牌，并在访问 MCP Server 时发送 Bearer Token。

规范强调令牌必须为目标 MCP Server 签发，Server 必须验证受众；客户端不能把收到的令牌透传给下游系统。这一点非常重要：如果 MCP Server 接受任何上游令牌，或者把用户令牌原样转交给第三方 API，就会造成 confused deputy、权限越界和令牌泄露。

MCP 工具是模型可控制的能力。官方规范建议让用户能够看到工具暴露和调用，并能拒绝工具调用。企业落地时需要进一步将工具分级：只读查询可自动调用，创建草稿可条件执行，支付、删除、生产部署、外发消息、权限修改必须审批。

需要注意，STDIO 与远程 HTTP MCP 的凭证处理不同。MCP 基础规范指出，HTTP 传输应遵循授权规范；STDIO 通常从环境获取凭证。因此，把远程 OAuth 流程机械套到本地 STDIO Server 并不正确。本地 Server 仍应避免长期密钥散落在配置文件中，可通过本机工作负载代理或受控凭证注入实现 Secretless。

Secretless Access到底是不是“没有密钥”

结论是：Secretless 的准确含义是业务代码与 Agent 不持有长期静态Secret，而不是整个信任体系完全不使用密码学凭证。

TLS证书、短期访问令牌、签名密钥依然存在，但它们由身份系统、授权服务器、工作负载代理或云平台管理，Agent只在需要时获得短期、受限的访问能力。理想情况下，Agent无法读取用于签发凭证的根密钥，也不会把令牌写入Prompt、工具参数、日志或长期存储。

Secretless常见实现包括：

• 云工作负载身份：容器、虚拟机或Serverless任务用平台身份兑换短期云凭证；
• SPIFFE/SPIRE：工作负载经过节点与工作负载证明，获得短期SVID；
• OAuth Token Exchange：把受信工作负载证明兑换为面向特定资源的短期令牌；
• Identity-aware proxy：代理根据Agent身份、任务上下文和策略完成下游认证；
• 动态数据库凭证：每个任务或会话生成短期数据库用户，到期自动失效。

Secretless 的关键验收问题是：Agent 源代码、配置、环境变量和 Prompt 中是否存在长期凭证？凭证是否限制目标资源、Scope、任务和有效期？Agent终止后令牌是否自动失效？安全团队能否立即撤销单个 Agent 而不影响其他 Agent？

三者结合的推荐架构

结论是：推荐架构应包含Agent注册与KYA目录、工作负载身份、策略决策点、OAuth授权服务器、MCP Gateway和审计平台，模型不能绕过这些控制直接连接业务系统。

一次工具调用可按以下流程执行：

1. 用户在企业Host中发起任务，系统验证用户身份并生成 task_id。
2. Agent Runtime通过工作负载证明获得自身短期身份，例如SPIFFE SVID或云工作负载令牌。
3. KYA目录确认 agent_id 状态有效，加载Owner、用途、风险等级、允许工具与禁止动作。
4. 策略引擎同时评估用户身份、Agent身份、任务目的、目标MCP Server、工具、参数、时间、设备或环境。
5. 若符合策略，授权服务器签发面向目标MCP Server、短时有效、最小Scope的访问令牌。
6. MCP Client用该令牌调用MCP Gateway或Server；Server校验签发者、受众、到期时间与Scope。
7. MCP Server再次验证具体工具参数，并用自己的受控工作负载身份访问下游API，禁止令牌透传。
8. 高风险动作暂停并展示影响范围，由有权人员批准；批准结果绑定到任务和参数摘要。
9. 系统记录人类发起者、Agent、模型/版本、策略、令牌标识、工具参数摘要、结果和审批证据。
10. 任务完成或超时后，短期令牌失效；异常行为触发Agent隔离、凭证撤销和事件调查。

这条链路要保留两个Principal：human_principal 与 agent_principal。如果只保留人类身份，无法区分同一用户授权的多个Agent；如果只保留Agent身份，则无法知道它代表谁执行。

MCP授权配置示例

结论是：MCP Server至少要正确发布受保护资源元数据、验证令牌受众和Scope；授权服务器再把Agent身份与业务策略映射到短期令牌。

受保护资源元数据示例：

{
  "resource": "https://mcp.example.com/finance",
  "authorization_servers": [
    "https://auth.example.com"
  ],
  "scopes_supported": [
    "invoices:read",
    "review:draft"
  ],
  "bearer_methods_supported": ["header"]
}

策略引擎可采用类似下面的逻辑。示例是实现建议，不是MCP官方固定Schema：

def authorize_tool_call(ctx):
    agent = kya_registry.get(ctx.agent_id)

    if not agent or agent.status != "active":
        return deny("unknown_or_inactive_agent")

    if ctx.workload_id not in agent.allowed_workloads:
        return deny("workload_identity_mismatch")

    if ctx.tool not in agent.allowed_tools:
        return deny("tool_not_allowed")

    if ctx.action in agent.high_risk_actions:
        if not approval.verify(
            ctx.approval_id,
            task_id=ctx.task_id,
            parameter_hash=ctx.parameter_hash,
        ):
            return deny("bound_human_approval_required")

    return allow(
        audience=ctx.mcp_resource,
        scopes=minimum_scopes(ctx.tool),
        ttl_seconds=300,
    )

批准必须绑定具体参数摘要，不能允许用户批准“以后所有操作”。否则Agent可以在批准后更换收款账号、目标仓库或删除范围，形成批准重放。

为什么需要MCP Gateway

结论是：小型试验可以直接连接单个MCP Server，但企业拥有多个Agent和Server后，集中Gateway更适合执行统一身份、策略、审计和令牌交换。

Gateway可以承担Server登记、元数据校验、Agent准入、Scope映射、速率限制、数据防泄露、Prompt Injection检测、人工审批、调用日志和紧急阻断。它不应成为简单反向代理，更不能用一个超级账号代表所有Agent访问下游。

正确做法是让Gateway保留原始人类与Agent主体，并基于目标资源签发或兑换短期令牌。下游系统若支持细粒度身份，应能看见Agent或委托链；若只支持传统账号，Gateway至少要按Agent或风险域隔离账号，并在审计日志中保存强关联证据。

可继续参考 AI Stack Nav企业MCP Gateway教程，将身份控制、工具白名单和审计能力整合到统一入口。

多Agent委托如何保持身份链

结论是：Supervisor Agent委托Worker Agent时，Worker不能继承Supervisor的全部权限，必须产生新的受限委托凭证。

例如Research Agent让Browser Agent检索资料，再让Writer Agent生成草稿。三个Agent应有各自身份：Research只负责编排，Browser只有访问批准域名的读取权限，Writer只能访问研究结果和草稿库。如果把Research的通用Token直接传给Worker，任何下游Agent都可能获得超出任务需要的能力。

委托记录至少应包含上游主体、下游Agent、任务、允许工具、资源、最大步骤、有效期、预算和是否允许继续委托。默认不允许Worker再次转委托；确有需要时，应限制深度并保留完整链路。

建议审计事件使用以下字段：

{
  "task_id": "task_20260913_001",
  "human_principal": "user://company/alice",
  "agent_principal": "agent://research/main/v2",
  "delegated_agent": "agent://browser/reader/v1",
  "workload_id": "spiffe://example.com/ns/agents/sa/browser",
  "mcp_server": "web-research",
  "tool": "fetch_page",
  "policy_version": "agent-policy-18",
  "decision": "allow",
  "credential_ttl_seconds": 300,
  "trace_id": "TRACE_ID"
}

日志不应保存完整访问令牌、API Key、敏感Prompt或业务数据。可保存令牌唯一标识、参数哈希、脱敏摘要和证据位置，既能调查又降低日志泄露风险。

90天落地路线

结论是：不要一开始改造所有Agent。先选一个同时涉及人类委托、MCP工具和敏感资源的流程，验证完整身份链。

1. 第1—10天：盘点。 列出全部Agent、脚本、机器人、服务账号、API Key、MCP Server、Owner和数据范围，标记共享身份与无人负责资产。
2. 第11—20天：定义KYA字段。 确定唯一Agent ID、用途、Owner、版本、风险、工具、数据、禁止动作、到期与重新认证条件。
3. 第21—35天：建立工作负载身份。 在Kubernetes、云平台或本地运行时启用工作负载证明，避免依赖静态环境变量密钥。
4. 第36—50天：规范MCP授权。 为远程Server配置受保护资源元数据、OAuth发现、受众校验、最小Scope及401/403处理。
5. 第51—60天：接入策略引擎。 同时评估人、Agent、任务、工具、参数、环境与风险；为高风险动作建立绑定参数的审批。
6. 第61—70天：改造成Secretless。 删除Agent配置中的长期Secret，改用工作负载身份兑换5—15分钟短期凭证，并验证到期、撤销和轮换。
7. 第71—80天：攻击与故障测试。 测试Prompt Injection、令牌透传、Scope升级、重放、Owner离职、Server被替换、时钟偏差和日志中断。
8. 第81—90天：独立验收。 由非开发人员核对权限、审计、撤销和业务结果，输出准入清单、例外项与下一阶段计划。

优先阅读 AI Stack Nav Agent身份与权限治理内容，把这套身份链与现有Sandbox、MCP白名单、内容排除和人工审批结合。

如何测试组合是否真的有效

结论是：成功调用API只能证明“能用”，必须通过否定测试证明“越界时不能用”。

测试	预期结果	证明的控制
未登记Agent请求令牌	拒绝	KYA准入
已暂停Agent继续调用	立即拒绝或令牌快速失效	生命周期与撤销
Token发给错误MCP Server	401	Audience绑定
读取Token尝试写入	403	Scope最小化
Prompt要求泄露凭证	Agent无法读取长期Secret	Secretless隔离
高风险参数在批准后变化	拒绝并重新审批	参数绑定批准
Worker使用Supervisor权限	拒绝	委托降权
重放同一批准或请求	拒绝或幂等返回	防重放与幂等
Owner离职或Agent到期	禁止新任务	生命周期治理
审计系统不可用	高风险调用失败关闭	可追溯性

企业还应定期执行身份清理：无调用Agent进入观察期，无Owner Agent隔离，长期未更新或评测失败的Agent暂停，权限使用率持续偏低时自动建议降权。

常见错误与排查

401 Unauthorized

先检查令牌是否过期、签发者是否可信、aud 是否与MCP资源一致，以及客户端是否通过受保护资源元数据找到正确授权服务器。不要通过关闭受众校验来“解决”401。

403 insufficient_scope

确认工具要求的最小Scope，并让客户端按Server返回的Scope提示重新授权。不要给Agent永久增加通配Scope；如果动作超出KYA用途，应直接拒绝或重新审批。

Agent明明独立，日志仍显示同一账号

说明下游系统只看到了Gateway共享凭证。需要在Gateway日志中强制保留Agent和委托链；条件允许时，使用Token Exchange或每Agent短期账号把身份传播到下游。

Secretless后仍能在日志看到Token

Secretless只解决Agent不保存长期Secret，不会自动修复日志泄露。应在SDK、代理、MCP Server和APM层统一屏蔽Authorization头、Cookie、凭证字段与敏感工具参数。

风险、限制与注意事项

结论是：独立身份能缩小权限和提高问责，但不会自动解决模型幻觉、Prompt Injection、恶意工具或业务规则错误。

• KYA标准化不足： 各家定义不同，采购时要核对具体字段和接口，不以“KYA支持”四个字替代技术验收。
• 身份爆炸： Agent、版本、运行实例和短期任务身份数量巨大，需要自动注册、到期和Owner同步，不能依赖Excel手工维护。
• 伪装与克隆： 攻击者可能复制Agent名称和Prompt，身份必须绑定运行环境证明或密码学凭证，而不是自报名称。
• MCP Server供应链： Server或工具描述可能被篡改，应建立登记、签名、来源、版本、扫描与变更审批。
• 令牌交换风险： 授权服务器必须校验主体、受众、Scope与委托条件，禁止任意Token换取更高权限。
• 策略过于粗糙： files:write仍可能太宽，应进一步约束目录、仓库、数据分类、动作和参数。
• 紧急处置： 必须能暂停单个Agent、撤销令牌、阻断某个MCP Server并保留证据。
• 人工审批疲劳： 不是所有动作都弹窗。按风险分级，低风险自动化，高风险展示清晰影响与差异。

付款、删除数据、发送外部邮件、生产部署、修改账户和权限、执行生产数据库写入等操作，必须设置独立授权和人工审批。即使Agent身份完全可信，也不能推断它的每一次业务判断都正确。

事实依据与来源

本文将成熟规范与新兴概念分开处理，避免把厂商术语误写成正式标准。

• 官方规范事实： MCP 2025-11-25规范定义Host、Client、Server架构；远程HTTP授权以OAuth框架为基础，要求受保护资源元数据发现、令牌受众验证，并禁止接受或透传面向其他资源的令牌。
• 官方安全建议： MCP工具由模型控制，但规范建议保留人类查看与拒绝工具调用的能力。
• 工作负载身份事实： SPIFFE定义可验证工作负载身份及SVID机制，适合让运行实例获得短期身份；具体部署需要结合SPIRE、云平台或企业身份基础设施。
• 行业资料： 多家身份验证和安全机构在2026年使用KYA概念，核心集中在识别Agent、绑定人类或组织Owner、声明用途与权限、持续监控风险。
• 编辑判断： KYA、MCP、Secretless分别对应治理层、协议层和凭证层，是本文为了便于落地提出的三层模型，不是任何单一官方规范的固定术语。
• 实施建议： 身份Schema、策略代码、Gateway架构、审计字段、测试表和90天路线属于工程建议，需要根据企业IAM与合规要求调整。
• 尚待验证： KYA未来是否形成统一标准、不同MCP客户端对最新授权规范的支持程度，以及各平台能否传播Agent委托链，均需持续核验。

FAQ

每个Agent真的都需要单独服务账号吗？

需要独立身份，但不一定需要在每个下游系统创建永久服务账号。更好的做法是为Agent建立稳定业务身份，再通过工作负载证明和Token Exchange按任务获得短期令牌。遗留系统不支持联合身份时，才考虑隔离的代理账号。

KYA是国际标准或强制法规吗？

截至2026年9月13日，KYA是快速发展的行业治理概念，不是具有单一权威文本的统一国际标准。企业可以采用其思想建立Agent目录和风险流程，但不应宣称实施KYA就自动满足所有监管要求。

MCP是否自带Agent身份？

MCP有客户端实现信息、会话和OAuth授权框架，但这些不等于完整的企业Agent身份治理。稳定Agent ID、Owner、用途、风险、工作负载证明和生命周期仍需外部IAM/KYA控制面提供。

Secretless Access会不会完全没有Token？

不会。访问期间通常仍使用短期令牌、证书或签名。Secretless强调Agent不保存长期静态Secret，凭证由可信身份系统动态签发，并受时间、资源、Scope和任务约束。

MCP Server能否把用户Token传给下游API？

不应直接透传。MCP授权规范强调Server只接受为自己签发的令牌，客户端也不应向Server发送其他资源的Token。Server访问下游时，应使用自身工作负载身份或受控Token Exchange获得下游专用凭证。

人类已经登录，为什么还要Agent身份？

人类身份说明谁发起任务，Agent身份说明哪个软件主体实际执行。同一用户可能调用多个权限与风险不同的Agent；只记录用户会丢失执行主体，只记录Agent又会丢失委托人，因此两者都要保留。

多Agent协作时是否可以共享一个Token？

不建议。每次委托都应降权并签发面向Worker、任务和目标资源的短期凭证。共享Token会破坏最小权限和归因，并扩大任一Worker被攻击后的影响范围。

使用Vault就是Secretless吗？

不一定。如果Agent仍从Vault读取长期API Key并能把它输出到日志或Prompt，只是集中存储Secret。更接近Secretless的方式是由代理或身份系统替Agent完成认证，或只发放短期、不可跨资源使用的凭证。

本地STDIO MCP如何实现Secretless？

可让本机代理或Sidecar依据进程、容器或工作负载身份获取短期凭证，再代理下游请求。不要把长期Key硬编码在MCP配置或仓库中。STDIO与远程HTTP授权模型不同，需要单独设计。

第一阶段应该选什么场景？

选择权限清晰、结果可验证且失败可回退的场景，例如只读知识检索、代码仓库问题分析或工单分类。先证明身份、授权、撤销和审计闭环，再开放写入、发布或付款能力。

参考来源

• Model Context Protocol官方授权规范（2025-11-25）
• Model Context Protocol官方架构说明
• Model Context Protocol官方Tools规范与人机交互建议
• SPIFFE官方工作负载身份概览
• Sumsub：Know Your Agent风险框架
• Experian：Know Your Agent概念解读

工具评测文章

工具选型与提示词资料

适合阅读工具评测、工具推荐、对比测评类文章后继续转化。

工具选型表 按场景、价格、上手难度和核心能力筛选合适的 AI 工具。 查看资料包 提示词模板包 提供写作、运营、编程、图片和视频生成常用提示词模板。 查看资料包