安全与权限
Chat Access
了解 Chat 用户进入 Agent 前的准入模型
Chat Access
Chat Access 是 Chat Plugin 的准入能力，只回答一个问题：某个外部 Chat 用户的私聊或群聊消息，是否可以进入指定 Agent。
它不是 Agent Core 权限，也不是通用 Role/Permission 系统。用户通过准入后，Chat Plugin 只把消息交给 Agent，不会向 Session 或其他 Plugin 传播角色和权限。
核心规则
- 默认拒绝：没有明确
allowGrant 时，消息不会进入 Agent。 - 按 Agent 隔离：访问 Agent A 的批准不会自动允许访问 Agent B。
- 按 Chat 账号隔离：身份键由
channel + issuer + subject_id组成，同一用户通过两个 Bot 访问时是两个 Principal。 - 范围明确：持久化 Grant 只有
direct和group；管理命令中的all会展开为两条 Grant。 deny和revoke不同：拒绝后不再生成请求；撤销后用户可以再次请求。
批准流程
未批准用户发送私聊消息时，Chat Plugin 会创建或复用一个 pending Request，并返回类似命令：
city plugin action chat access-approve assistant --input '{"request_id":"req_xxx"}' --token <token>管理员也可以先查看请求：
city plugin action chat access-snapshot assistant --input '{}' --token <token>群聊中的未批准消息默认静默拒绝，pending Request 仍会进入同一个管理列表。
数据保存位置
每个 Agent 独立保存：
<agent_project>/.downcity/chat/access.dbChat Access 数据库包含 Principal、Request、Allow/Deny Grant 和审计事件，不包含 Bot Token、App Secret 或消息正文。Chat Resource 完整 Item 单独加密保存在 City 全局数据库 ~/.downcity/downcity.db，Chat Plugin Binding 只保存 resource_ids。
与 City Auth 的区别
Agent Token 负责 HTTP 控制面认证。一个 Token 只属于一个 Agent，并拥有该 Agent API 的完整能力，不包含 User、Role 或 Permission。Chat Access 负责外部 Telegram、飞书或 QQ 用户能否向某个 Agent 发送消息。两者数据、身份和判定路径互不混用。