AIPermission：本地 AI 权限网关

AIPermission：本地 AI 权限网关

一句话结论

AIPermission 的价值不在“又一个 MCP server”，而在把开发者机器变成本地、单用户、可审批的 connector gateway：AI assistant 可以通过 scoped token 操作 SSH、数据库、Redis、S3、Docker、Kubernetes、Mail 等目标，但不直接拿到私钥、数据库密码或 API 凭据。

为什么对用户重要

用户的 Hermes / llm-wiki 自动化已经具备长期 cron、文件写入、网络读取和知识库更新能力；下一阶段真正的风险是把更多真实系统连接给 agent 后，权限边界变得不可见。AIPermission 给出的可迁移模式是：给 AI controlled hands，不给 credentials。这比单纯在 prompt 里写“不要做危险操作”更接近 Harness-Engineering 的可执行边界。

机制 / 一阶原理

AIPermission 的核心抽象是 target、credential profile、token permission、approval、history/audit pipeline。凭据保存在本地加密 gateway 内，agent 只拿到针对某些 target/action 的 token；高风险 action 可以等待人工 Run/Decline；SSH 等 connector 还提供 live console，让人能看见 agent 正在做什么。

它刻意拒绝 hosted SaaS、多租户、团队 RBAC、LAN/public gateway，因为当前安全边界依赖 localhost、单用户和本地浏览器 session。如果把它暴露为共享服务，就需要另一套远程认证、CSRF、租户隔离、网络加固和 incident response。

与已有概念的关系

• 对 Loop-Engineering：无人 loop 接入真实系统前，应先有 token 过期、审批、审计和 revoke，而不是继承人的长期凭据。
• 对 Harness-Engineering：它把 action boundary 从自然语言约束下沉到 connector/action permission 与 approval ledger。

可执行启发

1. Hermes 高风险工具可按 connector/target/action 建模，而不是按“某个工具函数是否存在”建模。
2. cron job identity 应使用短期 scoped token；任务结束后自动 revoke 或过期。
3. 本地开发者场景优先选择 local-only gateway；不要过早把个人权限控制面做成远程多租户服务。
4. 日报/ingest 类低风险任务保持只读；涉及 SSH/DB/Docker/K8s 写操作时才进入 approval gate。

失败模式 / 边界

• local-only 不是生产团队 RBAC；误暴露到 LAN/public 会破坏假设。
• gateway 自身成为高价值本地凭据集中点，需要加密、备份、解锁 UX 和审计可靠性。
• 人工审批若只看 action 名而不看参数/上下文，仍可能批准危险操作。
• connector 越多，权限矩阵越复杂，需要定期做 policy lint。

深度判断

本轮晋升为正式 source 页，因为它直接命中 harness/runtime/control-plane 高权重主题，并提供可复用的 credential boundary、scoped token、approval 和 local-only security model；不是新闻或单工具浅介绍。

写入记录

• 2026-08-28 09:00 CST：新增 AIPermission 本地权限网关分析，提炼 local-only credential boundary、connector/action permission、approval/audit 对 Hermes 高风险工具治理的启发。