安全与权限
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，并返回类似命令：
downcity chat access approve req_xxx --agent assistant管理员也可以先查看请求：
downcity chat access requests --agent assistant --status pending群聊中的未批准消息默认静默拒绝，pending Request 仍会进入同一个管理列表。
数据保存位置
每个 Agent 独立保存：
<agent_project>/.downcity/chat/access.db数据库包含 Principal、Request、Allow/Deny Grant 和审计事件，不包含 Bot Token、App Secret 或消息正文。Chat 账号和密钥仍保存在 City 全局数据库 ~/.downcity/downcity.db，Agent 配置只保存绑定的 channelAccountId。
与 City Auth 的区别
City Auth 负责 HTTP/Console 控制面的登录认证和路由权限，例如谁能调用管理 API。Chat Access 负责外部 Telegram、飞书或 QQ 用户能否向某个 Agent 发送消息。两者数据、身份和判定路径互不混用。