Ongrid安全机制完全解析：写权限总闸、审批流程、全链路审计与密钥管理-育师

AI Agent
人工智能
大模型
RAG
运维
可观测性
根因分析
后端

【免费下载链接】ongrid

An ops AI Agent that understands your infrastructure, finds the root cause, and fixes it — right from Slack, Telegram, Lark or DingTalk.

项目地址：https://gitcode.com/gh_mirrors/on/ongrid

点击查看免费下载

Ongrid 是一个能理解你的基础设施、自动定位根因并直接修复问题的运维 AI Agent（ops AI Agent），支持从 Slack、Telegram、飞书或钉钉直接驱动。本文完整解析 Ongrid 的四大安全机制：写权限总闸、人工审批流程、全链路审计与 AES 加密密钥管理，帮助你在放心让 Agent 动手修生产之前，先看懂它的防御纵深。

为什么运维 AI Agent 必须有"安全笼子"？

让大模型直接执行systemctl restart nginx、rm这类命令，听起来很爽也很危险。Ongrid 的设计哲学一句话就能概括：

默认只读，逐层放行，全程留痕。

具体拆成四层防线：

层级	机制	作用
第一层	写权限总闸（Agent Write Gate）	全局开关，默认关闭，Agent 只能读
第二层	人工审批收件箱（Approval Inbox）	高危动作先排队，人点"批准"才执行
第三层	命令沙箱（cmdpolicy）	Edge 侧只读白名单，写命令直接被拒
第四层	审计日志 + 加密密钥库	谁在何时改了什么，凭据不落明文

写权限总闸：默认只读，fail-safe 设计

Ongrid 中 Agent 能否执行"改变主机状态"的命令，由一个管理员级全局开关AgentWriteEnabled控制。它的实现体现了典型的fail-safe（失败即安全）原则：配置行不存在、读取出错，一律解析为false——开箱即用的 Agent 是纯只读的，管理员必须显式打开才会解锁写能力。

核心判定逻辑见 agent.go，配套的请求级传递机制在 host_write.go：运行时解析一次开关状态并写入请求上下文，所有写工具在执行前都要读取这个标记。

命令分类器：宁可多报，不可漏报

以host_bash工具为例（bash_basetool.go），每条命令都会先经过本地写命令分类器isHostBashWriteCommand：

判成写：进入审批提案流程，用户批准后执行；
判成读：仍以只读模式下发给 Edge，最终由 Edge 侧命令策略兜底裁决；
总闸关闭：写命令直接返回blocked，绝不执行。

分类器对rm / mv / cp / chmod / chown / dd、systemctl restart、docker rm等写操作，以及; && ||、重定向、$()、反引号等危险 shell 语法都做了保守识别——判错成"写"最多多一次人工确认，判错成"读"则由 Edge 沙箱兜住，这个不对称设计是整个链路的关键。

审批流程：高危动作必须过"人工收件箱"

Ongrid 的审批子系统（approval/usecase.go）是一个"人提案—人确认"（human propose-confirm）收件箱：

Propose：Agent 或工作流产出高危动作时，不直接执行，而是把动作标题、摘要、负载（Payload）与发起者记入待办列表，状态为pending；
Approve / Reject：管理员工在收件箱界面人工裁决。批准时系统调用该动作类型（Kind）注册的 Executor 真正执行，并落库执行结果（executed/failed）；拒绝则仅记录原因，不执行任何东西；
防双花：只有pending状态的行才能被裁决，杜绝重复批准导致的重复执行。

值得注意的是RunApproved路径（bash_basetool.go）：只有审批通过后执行的命令才允许携带Unrestricted标志绕过 Edge 命令策略——这个标志永远不会被 Agent 主动下发，只有"用户批准过的那条原命令"才能享受。

双保险：AI reviewer 的 SOP 二审

除了人工收件箱，Ongrid 还内置了一个 AI 二审机制：ReviewGate装饰器（review_gate.go）拦截所有write/destructive级别的工具调用，spawn 一个只读权限的 reviewer worker（定义见 reviewer.md）做静态审查。它的裁决规则相当严格：reject 是默认选项，approve 必须同时满足"有对应 SOP 覆盖、无并行同类操作、回滚路径已知"三条。

全链路审计：谁在何时改了什么，一笔不落

Ongrid 的审计子系统（audit/usecase.go）有两条值得学习的设计原则：

审计不阻塞业务：Emit写入失败只记 warning，绝不把错误抛回业务链路——安全记录不能成为可用性瓶颈；
curated（精编）而非流水账：HTTP 中间件（middleware/audit.go）只记录显式标注了规范 Action 的用户操作（登录、CRUD、审批裁决等），而不是给每个 POST 请求生成无意义的http_post_xxx行。

审计行包含操作者（UserID / Email / Role）、来源 IP、User-Agent、动作、资源、结果（success/failure/denied）与结构化负载，并要求调用方在传入前自行脱敏密钥。系统还内置每日 03:00 的保留期清理任务（RunRetention），按配置的保留天数自动清理过期记录。

更妙的是审计日志的反向利用：ListChanges接口专门服务于根因分析（RCA）场景——当故障发生时，Agent 会查询"症状出现前谁改了什么"，失败的尝试（denied）也会被纳入，因为"有人在事故前试图改动 X"本身就是根因线索。

密钥管理：AES-256-GCM 加密的凭据库

Agent 干活难免需要访问数据库、调用 LLM API，凭据如何存放？Ongrid 的凭据库（secret/usecase.go）提供三重保护：

存储加密：字段值经 AES-256-GCM 密封后才落库（secretbox.go），密钥派生自环境变量ONGRID_SECRET_KEY（未配置时回退到已持久化的ONGRID_JWT_SECRET，均独立于数据库）——光靠拖库永远拿不到明文凭据；
API 脱敏：列表 / 详情接口只暴露字段名，永不返回字段值；
只写不读：系统托管类凭据（如集成配置直接写入的密钥）支持 write-only 模式，失败时按不可变名称补偿删除。

密文采用v1:版本前缀 + base64 编码的格式，为将来更换加密算法预留了平滑轮换空间。

安全机制源码速查

想深入验证本文内容，可以直接阅读以下核心模块：

写权限总闸：setting/agent.go 与 basetool/host_write.go
审批收件箱：biz/approval/usecase.go、tools/decorators/review_gate.go
Edge 命令沙箱：edgeagent/cmdpolicy/policy.go、cmdpolicy/sandbox.go，策略示例见 bash-policy.example.yaml
全链路审计：biz/audit/usecase.go、server/middleware/audit.go
加密密钥库：biz/secret/usecase.go、pkg/secretbox/secretbox.go

总结

Ongrid 的答案是：AI Agent 可以"动手"，但必须活在层层设防的安全边界里——默认只读的写权限总闸、人工裁决的审批收件箱、只读白名单的命令沙箱、不可绕过留痕的全链路审计，以及 AES-256-GCM 加密的凭据库，五道闸门共同把"让 AI 修生产系统"从一句口号变成可落地、可审计、可回滚的工程实践。这也是任何想把运维 AI Agent 引入生产环境前，值得对照检查的安全基线。