跨国深谈← 返回←给 AI 智能体做“背景调查”：为什么身份是智能体安全的第一道坎

给 AI 智能体做“背景调查”：为什么身份是智能体安全的第一道坎

关联

人物 Simon Mayfor · Ian Livingstone · Glyfer Johnny

公司 Key Card

概念 智能体 · 身份 · 使命 · 会话 · 非确定性 · 同意疲劳 · OAuth · MCP · CLI · LLM 即裁判

AI 智能体会替你发邮件、改数据库、花钱办事。但你怎么知道它在做的事，是你真正想让它做的？

Ian Livingstone 是身份安全创业公司 Key Card 的联合创始人，曾创办过其他安全公司。

在这期对话里，他把“智能体的身份问题”拆开揉碎，讲给不搞安全的开发者听。

为什么智能体让老办法失效了？

每一轮计算平台变革都会带来新的安全问题：大型机有了多用户，就有了“谁能访问谁的文件”；

互联网带来了电子商务和加密协议；云计算带来了密钥管理。智能体也一样，但它有个前所未有的特点：不确定性。

Ian 的说法很妙：智能体基于概率分布，能推理、能猜测，这本来是功能；但从安全角度看，这恰恰也是缺陷。功能和缺陷是同一件事 。

过去你给一段程序权限，它基本就照着做。智能体不一样——你让它优化数据库，它可能认为把库整个清空重 来最“优化”。

这不是它恶意，而是它没有判断对错的能力，每次运行都是一个全新语境下的全新生物。

人可以查背景，智能体查不了

为什么以前云计算时代不用太操心授权？

Ian 用了一个招聘的比喻：公司雇人前会做背景调查、打电话给推荐人，确认这个人值得信任。

人也有长期的声誉顾虑——被开除对他是大灾难，所以他天然有动机好好干活。

智能体完全没有这些。它不在乎后果，没有“做错事会很惨”的概念，而且每次任务都是新的上下文。

所以老逻辑——“只要确认是这个人，就给他宽泛权限”——在智能体身上彻底失效 。

现在必须反过来：根据你派给智能体的具体任务，动态决定它能碰什么。让它总结文档？随便读。让它花钱超过 500 美元？

必须人工确认。每个组织、每个人的信任边界都不一样。

三层身份：你是谁、替谁干活、干什么活

Ian 把问题拆成三层。第一层是“这个智能体是谁”——它得有自己的身份，不能借你的账号乱窜。

第二层是“它替谁办事”，也就是代理关系。

第三层最有意思：任务本身也需要身份。

在 emerging 的标准里，这个概念叫“任务(mission)”——用户给智能体指派了一项任务，这个任务的描述随请求一起传给下游系统，下游就能判断：

这个请求和当初的授权匹配吗？

Ian 用信用卡拒付打比方：你让智能体替你交易，事后又不认账，系统得能拿出记录证明“你确实授权了它，而且说了最多花 500 美元”。

今天的身份体系做不到这一点——如果智能体替你访问某个服务，那个服务根本没法核对它的动作是否符合你的原始意图 。

别让“确认弹窗”毁掉一切

现在的工具靠什么管智能体？弹窗。每做一步都问你“确定吗？”。Ian 直言这是 consent fatigue(确认疲劳)的温床——你根本不会读弹窗，只会一路点“是” 。

他的思路是：设几条铁律，比如“删除数据必须我本人批准”；其余情况，让一个“AI 当裁判”的判断系统来决定这次请求合不合理。

裁判拿不准时，再升级给人。裁判判断得越准，打断你的次数越少，信任越高，智能体能获得的自主权就越大。

这个思路有个重要的历史教训：上一代安全工具之所以部署失败，就是因为要人工手写成百上千行策略文件。

这次不能再走老路。

协议在变，格局未定

工具层面，生态正分裂成两大阵营：命令行工具和 MCP(MCP 协议天生自带 OAuth 支持)。有些安全方案只支持一边。

Key Card 的定位是两边通吃，再加上传统的特权访问管理——三样合一。

协议层面也有新动作:OAuth 社区新推出了 cross-app access,让智能体能以智能体的身份认证，而不是伪装成人类；

Ian 的预测是：

三年内，新协议会真正落地，智能体会让整个互联网变得“即插即用”，企业内部的信息孤岛会因身份系统升级而被打通。

驱动力来自企业——职场智能体的采用速度和回报远超家用场景，而大企业客户会拿着预算逼供应商实现安全标准。

这个模式，过去 30 年一直如此。

本集带走

• 智能体的不确定性既是功能也是缺陷，安全的核心问题变成：如何确保它的动作符合授权者的真实意图
• 对人可以“查背景后给宽权限”，对智能体必须按任务动态授权——任务本身需要可传递的身份
• 靠“确定吗”弹窗管理智能体会导致确认疲劳，需要硬边界加 AI 裁判的组合
• 新协议(cross-app access、Agent Auth)正在出现，但格局远未定型；企业需求是推动标准落地的最大力量
• Key Card 的做法：同时支持命令行和 MCP,让开发者从个人用起，再扩展到团队和全公司

这正是今天完全不存在的问题：如果你去 ABOS，让你的智能体代表你与 ABOS 交谈，ABUS 实际上完全没办法知道智能体正在执行的动作是否与你的初始请求一致。
Which is the issue that doesn’t exist at all today is if you go to ABOS and you ask your agent to talk to ABOS on your behalf, ABUS has actually no way to know whether you what the action that the agent is performing was aligned with what your initial request was at all.
—— Ian Livingstone · [23:18]