作者：Haozhen
编辑：Siqi
| | / | |
01.
Agent 本质上是一个非确定的软件系统
Agent 是一种概率性、非确定性的软件系统。以 Coding Agent 为例，当开发者指令其“检查日志、创建 Issue、修复并提交 PR"时，Agent 需自主补全大量未明确的信息：
- 自主选择日志系统（如 Datadog 或 CloudWatch）及工单系统（如 Jira 或 GitHub）；
- 自主决定代码修改范围、本地命令执行及 PR 提交目标；
- 自主判定代码变更的归属名义。
左右滑动查看更多图表
与传统应用按预设程序运行不同，Agent 根据上下文、可用工具及前序结果动态决策执行路径。这种差异带来了四大安全挑战：
- 行为不可穷举：Agent 在推理过程中动态发现工具（如 MCP Server、本地命令），企业难以预先审查其将访问的所有资源。
- 跨系统组合风险：Agent 跨越多个系统执行任务，单个合规操作串联后可能引发数据泄露（如将日志中的敏感信息写入公开 PR）。
- 委托链信息丢失：任务经 Sub-agent 或多层工具调用传递后，末端 API 往往无法追溯原始发起者及完整链路。
- 审批疲劳：Agent 执行速度远超人工，高频确认窗口会导致用户盲目点击允许，失去安全管控意义。
示例：Agent 分别合规获取读取日志、创建工单和提交 PR 权限，若将日志个人信息写入工单并引用至公开 PR，组合动作将导致数据泄露。
02.
现有身份系统为什么不适用 Agent？
现有身份系统无法准确描述 Agent 行为
传统身份系统分为两类：面向人的身份系统（Human Identity）和面向工作负载的身份系统（Workload Identity）。前者假设人会自我判断权限，后者假设程序行为由预写代码决定。
Agent 兼具两者特征：既需 Human Identity 说明代表谁，又需 Workload Identity 调用系统。因此，Agent Identity 被定义为一种“委托关系”：规定哪些用户可将何种权限委托给哪些 Agent，并明确使用条件及下游传递规则。
长期凭证导致权限固化
当前多数 Agent 依赖长期有效的 API Key 或.env 密钥，一旦获取即可行使全部权限，即“环境权威”（Ambient Authority）。这种模式无法实现最小权限原则。
案例：长期凭证引发的过度授权
某事故管理 Agent 持有一枚云服务 API Key 连续处理五张工单，该凭证同时包含续签证书、重启服务及扩容权限（即"Kitchen Sink"权限）：
- 工单 1-2：正常处理备用电源故障及 TLS 证书续签；
- 工单 3：因拥有数据库连接字符串，直接删除了计费数据库且无法确认备份状态；
- 工单 4-5：利用同一凭证重启冻结服务并扩大容量，产生额外费用。
可见，长期凭证使 Agent 在执行低风险任务时拥有了高风险操作的潜在能力。
03.
Agent-native 身份系统六要素
企业需将授权机制从静态“门禁”升级为动态“控制平面”，在每次操作前重新校验上下文。理想的 Agent 身份系统应具备以下六项能力：
- 独立可识别性：Agent 应作为独立主体被记录，拥有稳定且可加密验证的身份，无需与每个目标系统单独注册。
- 实时动态授权：授权判断应从 Token 签发时移至实际操作发生前，综合考量用户委托、任务目标、运行环境等 Context。
- 渐进式信任（Progressive Trust）：权限随任务推进动态调整。系统可缩小过宽请求、要求人工确认高风险操作，或在信息不足时暂缓执行。
- 零常驻权限（Zero Standing Privileges）：任务结束后凭证立即失效，避免 Agent 在无任务时持有有效访问权。
- 全链路审计：日志需清晰记录委托关系、实际授予权限及决策依据，确保跨 Agent 链路的可追溯性。
- 意图约束：最难但最关键的一点，确保 Agent 权限始终受限于用户初始目标（Goal）和意图（Intent），防止任务偏离。
04.
企业如何管理 Agent 的身份与权限？
企业部署 Agent 前，常面临员工私自安装工具并申请权限的"Shadow IT"问题。由于下游日志仅记录员工账号，安全团队难以区分操作来自人工还是 Agent。
建议策略：
- 发现与识别：通过异常权限申请、新程序出现或超高频请求等信号识别 Agent 存在。
- 建立安全区：先批准部分 Agent 在有限资源范围内运行，随信任积累逐步扩大访问范围。
- 逐项审批：对新接入的 Agent 或工具进行严格的资源访问审查。
05.
Agent Identity 市场的切入路径
目前市场参与者主要分为三类：
- 大型安全厂商：如 Microsoft Entra Agent ID、Okta for AI Agents，将 Agent 视为新身份对象，沿用现有权限规则。
- 模型厂商：如 Anthropic，在模型产品内嵌身份控制（如限制 Claude 访问的 Slack 频道）。
- 初创公司：如 Oasis Security、Keycard，专注于非人类身份管理及动态授权。
从解决的问题来看，主要存在两个切入点：
- 生命周期管理：发现 Agent、登记负责人、审查权限及停用（如 Oasis Security）。
- 运行时授权：在工具调用瞬间判断是否执行，签发短期凭证（如 Keycard、Arcade.dev）。
Keycard 作为 Agent-native 代表，强调权限应随任务动态变化。其近期与 Smallstep 集成硬件认证能力，并成为 Okta Cross App Access 首批支持厂商，展现了融合趋势。
06.
案例研究：Keycard
团队背景与创立
Keycard 成立于 2025 年，创始团队包括前 Manifold CTO Ian Livingstone、前 Heroku/Snyk 高管 Matthew Creager 以及 Passport.js 作者、前 Auth0/Okta 专家 Jared Hanson。团队获 a16z、Acrew Capital 等机构 3800 万美元投资。
从左到右：Matthew Creager、Ian Livingstone、Jared Hanson
团队最初旨在解决服务间身份问题（面向机器的 SSO），后随 Agent 普及转向动态授权领域，致力于管理“谁把什么权限交给了哪个 Agent"。
产品定位与工作流
Keycard 提供安全令牌服务（STS）和授权策略治理。其核心流程如下：
- 用户登录 IdP 并委托 Agent 访问资源；
- Agent 提出工具调用请求，OAuth Client 向 Keycard 申请凭证；
- Keycard 结合用户委托、应用身份、目标资源及 Policy 进行实时判断；
- 审核通过后，Keycard 签发仅限本次操作、短时效的 Access Token；
- MCP Client 使用该 Token 访问资源，任务结束权限即刻回收。
Keycard 如何在每次工具调用前审核权限并签发短期 token
该技术基于 OAuth 2.0 和 RFC 8693 Token Exchange 标准，并关注 AARM、AAuth 等新兴协议的演进。
AARM（Autonomous Action Runtime Management）：要求安全系统在 Agent 执行前拦截请求并结合 Context 判断。
AAuth（Autonomous Authorization）：旨在让 Agent 使用可验证加密身份，并将委托信息带入授权过程。
效果对比：接入 Keycard 后的工单处理
复用前述事故管理案例，接入 Keycard 后：
- 物理故障：正常转交，日志清晰记录委托链；
- TLS 续签：仅授予“续签”Scope，无其他云操作权限；
- 删除数据库：因违反 Policy，直接拒绝签发凭证；
- 重启服务：需人工确认，且校验值班人员权限，无权限则阻止；
- 扩容：需人工确认，值班人员有权限则签发临时 Token。
结论：Keycard 并未改变 Agent 的决策逻辑，而是通过动态授权机制，确保每一步操作均在可控、最小化的权限范围内执行。
排版：陈宇聪