问题不在「模型坏了」，在「钥匙太大」
@rahulxbt1 写了一份很直白的清单：多数 AI 代理事故，不是模型存心作恶，而是代理拿着一把远超任务需要的钥匙。一句任务定义、一个独立账号、一个沙箱、一份能读的日志——听起来基础，却正好是账号安全与稳定使用里最常被省掉的四样。
五条可执行规则
1. 先写清任务和爆炸半径
用一句话写「这个代理只做 X」。再问：一旦失控，最坏会弄坏什么？如果答案是「一切」，权限就过大，先缩小再启动。
2. 代理用单独账号，别共用你的个人/管理员登录
个人登录一旦交给代理，审计分不清是人点的还是模型点的；吊销代理权限时，也容易误伤你自己。单独账号（或至少单独 API Key / 工作区）是隔离的第一步。
3. 钥匙从小到大，而不是一次给满
- 优先只读，确认需要再开写；
- 白名单目录、仓库、域名、工具；
- 能用短时效凭证就不用长期主 Key；
- 密钥不要贴进提示词，也不要放在代理随手可读的路径。
4. 不可逆操作设人工闸门
发邮件、花钱、删数据、上线、转账——让代理起草，你来确认。再加硬顶：单次运行消费上限、速率限制、最大动作次数。系统提示里写「永远不要做 X」不算安全控制。
5. 把「读不可信内容」和「碰真实账户」拆成两个代理
网页、邮件、文档、工具返回值都可能夹带隐藏指令（提示注入）。一个既读外网、又握支付/生产密钥的会话，损失面最大。日志要记下每次工具调用；并确保你能在一分钟内吊销该代理的令牌。
落地时常见的偷懒方式（尽量别犯）
- 为了「先跑通」把个人 Anthropic / GitHub / 云账号直接交给代理；
- 把主 Key 写进提示词或仓库「临时测试」，事后忘记删；
- 跳过审批，让代理在真实环境里直接部署或发送；
- 假设系统提示里的禁令等于权限边界。
正确顺序永远是：窄任务 → 独立身份 → 最小钥匙 → 闸门与日志 → 确认行为正常后再一点点放开。
和 Claude 账号安全的关系
这和「别买共享号」「别把主 Key 塞进陌生第三方」是同一类防守：缩小信任边界。代理越能干，越要用账户与密钥设计，而不是靠模型「自觉」。
如果你想在一台常开、整机独享的新加坡 Mac mini 上长期跑 Claude Code，Zumac.Ai 提供整机租用 ¥999/月起，咨询 Telegram @singatao。
