同一台机器上的所有 agent 属于同一个信任域，可以读彼此的文件和凭据。 独立工作目录和不同的 agent 身份都不构成安全隔离。
whoami = 本人 uid。以下全部可读：
~/Workspace/personal~/.ssh~/.pi/agent/auth.jsonMEMORY.md（含私人助手那份）权限位：~/ 750（staff 组可穿行，无 ACL 挡住），agents 目录 700（同账号下形同虚设）。
约束只能落在"取用前自检"这种软层，或者真的去拆账号和机器。前者是纪律，后者是边界。
文档可以靠"别去读"扛一阵。凭据不行：一个能读到 token 的进程，风险不在它读不读，而在一旦读了无法追溯——token 可以离机、可以等待、可以事后用。
同一个账号身份存在两份独立副本，refresh 各自独立：agent 侧的 auth 文件和 CLI 侧的 auth 文件。两份 JWT 指向同一个账号，跑着十个 CLI 进程。
后果：只撤销其中一份等于没撤，另一份照样续命。
所以换的不只是"不共享"，是可归因和可撤回这两件事。别把"换 key"本身当目的。
invalid_grant、旧 access 必须 401。验前先清本地缓存，否则缓存会掩盖失效撤销 refresh 不回收已签发的 access，后者活到 exp。实测 access 的 exp - iat 是整整十天。这段窗口按已泄露处置，不是已关闭。
一次全绿只等于那一次通过。要对两份副本、两类 token 各自都打一次失败调用，附时间和命令记下来。任一项缺失，结论只能写"部分验证"。
按根因排，最后一条是根。
agent 按它主人的身份取数据，不按提问的人取。同事问它，借的是主人的权限。
高权限查询的结果会沉淀进共享记忆，之后被低权限的人问出来。检索时查一次权限覆盖不了这个。
回答前不判断接收频道/私聊的成员范围。
现在要限制"agent 能读到什么"，只能去拆账号、拆机器、拆云凭据——而这件事发生在平台之外，全靠人手做。
平台能提供的锁只有"你在不在某个 Server"这一把。它解决"谁能找到这个 agent"，解决不了"这个 agent 能读到什么"。
能做到，但要人拆成一堆 Server × 一堆环境，成本随层级数和人数一起涨，而且没有任何机制保证不漏拆。