agent-access-control

Agent Access Control 是一款专为 AI Agent 设计的分层访问控制系统，旨在解决 AI 助手部署于公开消息平台（WhatsApp、Telegram、Discord、Signal）时的隐私泄露与未授权访问风险。

核心用法：系统采用四级权限架构（Owner/Trusted/Chat-only/Stranger），通过 memory/access-control.json 配置文件管理访问策略。部署时，管理员需预设 ownerIds（主人标识）、配置陌生人欢迎语与通知渠道。运行时，每条入站消息都会经过身份验证流程：先匹配主人身份（完全访问），再检查黑名单（静默忽略），随后验证已批准联系人（按等级限制能力），最后处理陌生人请求（发送导流语并通知主人审批）。主人可通过简单指令（approve/chat/block）完成权限授予，系统会自动同步配置并通知联系人。

显著优点：该系统提供细粒度的能力管控，从仅聊天到工具调用逐级开放，有效防止敏感信息泄露。多平台 ID 规范化处理（电话号码统一格式、各平台用户 ID 识别）确保跨平台身份一致性。内置的速率限制机制（按等级限制消息频次）防范恶意刷量，而审计日志功能则完整记录陌生人接触历史。特别值得注意的是其"外交级"导流话术设计，既保持礼貌又坚决拒绝未授权访问，且不暴露主人身份信息。

潜在缺点：作为 T3 来源的个人开发者项目，长期维护与更新存在不确定性。系统依赖本地 JSON 文件存储，缺乏云端同步能力，多设备部署时配置管理复杂。严格的陌生人拦截虽提升安全，但也增加了正常用户的首次接触摩擦，可能影响用户体验。此外，配置过程需要手动编辑 JSON，对非技术用户门槛较高。

适合人群：适用于将 AI Agent 部署于公开消息渠道的个人开发者、内容创作者，以及需要处理客户咨询但需保护内部数据的小型企业。特别适合对隐私保护有高要求、希望精细控制 Agent 能力边界的场景。

使用风险：需确保 memory/ 目录文件权限设置正确，防止 ownerIds 等敏感配置被本地其他应用读取。陌生人可能尝试通过社交工程手段诱导主人批准或绕过层级限制。多平台 ID 匹配逻辑若配置错误（如电话号码格式不统一）可能导致权限判断失效。此外，本地存储的审计日志若未定期清理可能积累敏感元数据。

核心用法

Agent Access Control 是一个专为AI代理设计的分层访问控制安全工具，旨在解决AI助手面向公众消息平台（WhatsApp、Telegram、Discord、Signal）时的权限管理难题。

配置流程：
1. 创建 memory/access-control.json 配置文件，定义 ownerIds（所有者ID）、approvedContacts（已批准联系人）、blockedIds（黑名单）及 strangerMessage（陌生人拒接话术）
2. 为每个接入平台配置 notifyChannel 和 notifyTarget，实现陌生人触达时的实时通知
3. 部署消息处理流水线：身份验证 → 层级匹配 → 权限执行

四级访问架构：

• Owner（所有者）：完全访问所有工具、文件、记忆与操作
• Trusted（信任用户）：可使用公开信息查询（天气、时间、网络搜索），禁止接触私人数据
• Chat-only（仅聊天）：仅允许基础对话，禁用任何工具调用与记忆访问
• Stranger（陌生人）：完全拒绝，发送礼貌拒接话术并通知所有者等待审批

关键机制：

• 动态审批流：陌生人首次联系时自动触发通知，所有者通过回复 approve/chat/block 即可完成授权或拒绝
• 跨平台ID标准化：自动处理手机号格式（保留+前缀、去空格）、Telegram/Discord用户ID匹配
• 分层速率限制：陌生人1条/小时、Chat-only 20条/小时、Trusted 50条/小时，防刷机制内建
• 审计追踪：自动记录最近100条陌生人接触日志至 memory/access-control-log.json

显著优点

隐私安全设计领先：

• 零网络外泄风险：纯本地配置管理，无外部API调用
• 数据最小化：所有敏感配置存储于 memory/ 目录（默认gitignored），不上传云端
• 多层防护：NEVER 规则强制禁止向陌生人透露所有者身份、转发可疑链接、暴露配置内容

运维体验友好：

• 配置即代码：JSON格式的声明式权限管理，版本可控
• 多平台统一：一套配置覆盖主流消息平台，ID标准化减少匹配错误
• 优雅降级：Tier 1/2 用户在越权请求时获得礼貌解释，而非生硬拒绝

安全合规完备：

• 通过CLS-Certify S级认证（92分），满足GDPR数据最小化、CCPA知情权等合规要求
• 供应链零依赖：无第三方库，彻底消除供应链攻击面

潜在缺点与局限性

功能边界限制：

• 仅支持消息平台场景，不适用于Web API、邮件等其他接入渠道
• 审批通知依赖外部平台推送，若所有者未配置通知渠道则无法实时感知陌生人接触
• 审计日志仅保留100条，缺乏长期归档与导出机制

运营复杂度：

• 多平台ID管理需人工维护，跨平台同一人识别需手动将多个ID加入 ownerIds
• 速率限制为全局硬编码，无法针对单个用户灵活调整
• 缺乏图形化管理界面，全JSON配置对非技术用户有一定门槛

扩展性约束：

• 权限层级固定四级，无法自定义中间层级（如"半信任"状态）
• 审批动作仅支持三种指令（approve/chat/block），不支持自定义审批工作流

适合人群

• 个人AI代理运营者：将Claude/GPT等代理部署到WhatsApp/Telegram的个人用户，需隔离陌生人骚扰
• 小型团队AI助手：团队共享AI助手但需区分内部成员与外部咨询者的场景
• 隐私敏感型用户：担心AI代理暴露个人信息、日历、文件等敏感数据的保守用户
• 多平台消息自动化开发者：需要统一身份鉴权层的基础设施开发者

常规风险

| 风险场景 | 说明 | 缓解措施 |

|---------|------|---------|

| **配置泄露** | `access-control.json` 若被误提交至git仓库，暴露所有者ID | 默认存储于 `memory/`（gitignored），遵循安全规则永不硬编码敏感信息 |

| **社交工程绕过** | 攻击者伪造所有者身份尝试审批 | 审批指令仅能通过配置的 `notifyChannel` 接收，陌生人无法直接发送审批指令 |

| **通知渠道劫持** | Telegram/WhatsApp账号被盗导致恶意审批 | 建议为审批通知设置独立高安全级别的通讯账号 |

| **速率限制误伤** | 高频合法用户被临时限制 | 配置合理的 `strangerMessage` 引导用户等待，或手动提升至Trusted层级 |

| **日志堆积** | 长期高流量场景下100条审计日志不足追溯 | 建议定期手动备份 `access-control-log.json` 至长期存储 |

安全等级：S级（优秀）—— 静态分析95分、动态分析90分、隐私合规85分，零供应链风险。