让 AI 排查 Ubuntu，却不能擅自修复：Maat 如何把权限交还给操作系统
让 AI 助手帮忙排查 Linux 服务故障，最直接的办法是给它一个 Shell。但 Shell 也意味着模型可能执行重启、改文件甚至联网操作；而日志本身还可能包含攻击者写入、试图诱导模型的文本。Maat 是一个面向 Ubuntu 的开源 MCP 服务器，选择了更窄的权限边界：让 Agent 查看主机状态、整理证据并提出修复计划，但真正改变系统前必须由人确认，权限由 Ubuntu 的安全机制执行。
它目前处于 developer preview，不能当成成熟的通用远程运维平台。其设计适用于希望让 Agent 帮忙读日志、定位故障，却不愿交出任意 Shell 权限的 Ubuntu 管理者。
先观察，再提出计划
Maat 把流程分成观察与执行两侧。MCP 服务运行在严格限制的 Snap 中，读取 systemd 单元、日志、进程、磁盘等状态；它会对日志脱敏、归并相似行并压缩输出，每项发现带有证据 ID。模型可基于这些信息提出一个有类型的动作计划，例如重启指定的失败服务，但不能直接运行命令。
计划交由独立的 maatctl 检查和展示。它会重新校验计划内容与证据，再由操作者确认；实际系统操作经 polkit 授权，之后还会检查结果。操作步骤进入哈希链审计记录，并在 systemd journal 中保存检查点。这样做并不意味着绝对安全，但把“模型说要做什么”和“主机实际允许做什么”拆成不同的信任边界。
更关键的是，项目把限制放在内核强制执行的 Snap confinement（AppArmor 与 seccomp）上，而不只依赖提示词或应用层判断。README 的设计说明称，受限服务没有网络接口，不能写用户目录或重启服务；项目也提供 maat selftest 用于检查本机的隔离行为。工具注解中的“只读”本身只是提示，真正的权限边界仍要由运行环境落实。
在 Ubuntu 上试跑
项目 README 给出的 Snap 安装示例如下。接口连接会授予读取系统日志、系统状态和挂载信息所需的权限；若要访问 journal，还需将当前用户加入 systemd-journal 组并重新登录：
sudo snap install maat --edge for iface in log-observe system-observe mount-observe; do sudo snap connect "maat:$iface" done sudo usermod -aG systemd-journal "$USER" # 重新登录后执行自检与诊断 maat selftest maat diagnose
maat diagnose 可在没有 AI 的情况下生成确定性诊断报告，适合先验证读取链路和输出质量。接入 MCP 客户端时，README 展示了 Claude Code 和 OpenCode 的配置方式：
claude mcp add maat -- maat mcp opencode mcp add maat -- maat mcp
排查过程中，Agent 使用 Maat 的只读工具查看状态、筛选失败单元和日志证据；只有提出计划后，人才使用 maatctl 审阅并确认。切勿把“建议动作”理解为自动修复：设计目标恰恰是阻止模型未经人类批准直接更改主机。
适用边界与落地检查
Maat 与运行在隔离容器中的通用 Agent 沙箱并不相同：排查主机需要读取真实主机状态，因此它把 MCP 读取端限制在 Ubuntu 主机上的受限 Snap，再将执行动作交给用户态的独立程序和 polkit。其 README 标注当前为开发预览，并公开了特定 Ubuntu 虚拟机上的自测证据；这不能替代你自己的发行版、硬件和策略验证。
上线前建议至少检查三件事：第一，在测试虚拟机运行 maat selftest，确认本机 Snap 接口和 AppArmor 行为符合预期；第二，逐项审查 MCP 客户端配置及用户组变更，避免把工具误以为“零权限”；第三，查看审计记录与恢复流程，并先用无 AI 的 maat diagnose 熟悉报告格式。若要管理非 Ubuntu 系统或跨主机运维，不能仅凭项目定位推断它支持这些场景。
Maat 值得关注之处，是把 Agent 运维中的权限问题转化为清晰的系统设计：模型负责解释证据和形成建议，操作系统及管理员负责授权。它不会消除模型误判，也不应取代备份、变更流程和人工复核；但当你不希望排障助手拿到任意 Shell 时，这种“可观察、可建议、不可自行执行”的架构提供了值得评估的路线。