Agent 出事的新闻，九成不是模型"叛变"，是凭证给错了。这周 HN 上三件事撞在一起：一篇说根本没有 rogue agent，Meta 的 Muse 被指无视用户权限，Nvidia 想给每个 agent 配个看门狗芯片。它们讲的是同一件事的两面——边界在模型外面，不在模型里面。我的立场挺土的：凭证永远不进 prompt，每个任务签一个带 scope 和过期时间的短期令牌，日志只留令牌 ID。
凭证不是 agent 的知识，是它的动作权限
HN 上有篇《Agents don't need memory, they need documentation》在讲 agent 记忆，我想说的是它的反面：很多人把凭证当文档塞进 context。.env 读进来、config 拼进 system prompt、tool 描述里直接写 "use this API key"。这条线一越，prompt injection 的性质就变了——不再是"诱导模型说错话"，而是"诱导模型用你的身份做事"。
"反正 system prompt 用户看不见"这说法我不接受。system prompt 会进日志、进 trace、进第三方 eval 平台、进微调数据集。而且模型自己会把它复述出来，不是恶意，就是它觉得那是上下文的一部分。见过 agent 在解释自己为什么这么做时，把整段配置念出来的——包括 key。
"没有 rogue agent" 这篇框架是对的
eoinhiggins 那篇的核心论点我基本同意：没有 agent 自己"叛变"，只有授权过宽加审计缺失。"Rogue agent"这个词很有害，它把工程问题包装成科幻问题，然后讨论就滑向"要不要对齐"，而不是"这个 token 的 scope 为什么是 *"。
反面意见我也听过，而且有一半道理：prompt injection 防不住，所以凭证管理是治标。对，注入确实防不住。但你控制不了模型读什么，你能控制它拿到什么。把爆炸半径从"整个云账号"压到"一个只读的 S3 前缀、一个很短的 TTL"，这是工程今天就能做的事。治标也比分不清影响面强。
Meta Muse 那事，权限检查不该放在模型里
AppleInsider 的报道我没法验证细节，但模式很熟：agent 拿到的凭证比它需要的大，或者权限检查发生在 agent 的"建议层"，而不是真正执行的那一层。
这是最常见的坑——把权限判断交给模型。模型说"我不该删这个"，不等于它删不掉。真正的边界必须在模型外面：在 API gateway、在 token 的 scope 上、在数据库的角色上。模型只是发起方。
短期令牌的麻烦，恰恰是它的价值
Nvidia 要给每个 agent 配看门狗芯片，硬件熔断听着很爽。但看门狗是最后一道闸，它管"停下来"，管不了"这个 agent 本来就不该有删库的权限"。凭证粒度这件事，芯片替不了。
短期令牌的代价是真实的：得有个签发服务，得处理过期重签，得跟现有的长期 key 体系共存一段时间，多一跳延迟。我不打算说这些不存在。换来的是出事时你有一个明确的时间窗口和一个明确的 scope，而不是一把从很久以前就躺在那里的 key。
scope 应该随任务收窄。做 code review 的 agent 不需要 write 权限，跑数据聚合的不该能 DROP TABLE。这话说起来像废话，但真实配置里大多数是"先给全权，回头再收"——然后就没有回头。
日志只留 token ID，比想象中难
执行起来是：日志记 token ID、任务 ID、签发时间和 scope 快照，不记令牌本身，也不记它换来的敏感数据。听着简单，但不少 tracing 工具默认把整个 request/response 打进去，包括 Authorization header。你接上它那一刻，红线就破了。
Cloudflare 这周发的 cf CLI算正面例子——复用的就是 Cloudflare API token 那套 scoped + 过期的模型，agent 侧不用发明新东西。Pi pod那种沙箱是另一个方向的隔离，但沙箱替代不了凭证管理：一个能出网的沙箱里的 agent，拿着全权 key，照样能把账号清空。
我现在大概是这么做的
- 凭证从环境变量进，由执行层在 tool 调用时注入，模型看不到明文。
- 每个任务签一个令牌，scope 按任务声明，TTL 按任务时长给，宁可短了重签。
- 审计日志只记 token ID 加 scope 快照，不记明文。
- 长期 key 只存在于签发服务里，agent 永远碰不到。
也许半年后回头看，这套会被某个平台做成默认，就像现在没人自己手写 OAuth。但在那之前，别给 agent 一把万能钥匙。出事的时候，你得能说清楚它当时能做什么——这句话说出来，比什么看门狗都管用。