AI 驱动的博客系统运维：Agent 时代下的凭据管理探索

一、引言：当 AI 成为运维工程师

作为一个密码学从业者，我对"把钥匙交给 AI"这件事天然持怀疑态度。

但当我发现自己在做重复性的博客运维工作时——写完文章要 git push，服务器要 git pull && hugo build，Nginx 配置要定期检查优化——我开始思考：

能不能让 AI 帮我做这些事？同时，不让 AI 知道我的 SSH 密钥在哪？

这是一篇关于AI 运维中的凭据管理探索记录。我会分享如何构建一个让 AI 能干活、但不知道密码的系统。

本文重点：分享一种混合凭据管理模式，通过双层凭据隔离（Vault + 控制面）实现安全的自动化运维。

延伸阅读：如果你想深入了解 OpenClaw 的凭据配置细节（SecretRef 语法、Vault Resolver 脚本、运行时安全边界），请参考 OpenClaw SecretRef 凭据机制深度分析。

二、系统架构概览

总体架构

整个系统由五个核心组件构成：

flowchart LR
    User["👤 用户"] --> AI["🤖 AI 助手"]
    AI -->|"内容运维"| Git["📦 Git 仓库"]
    AI -->|"服务器运维"| MCP["🛡️ MCP 服务"]
    AI -.->|"读取身份凭证"| Vault["🔐 Vault"]
    MCP -.->|"获取操作凭证"| ControlPlane["🔑 控制面"]
    Git --> Server["🖥️ 博客服务器"]
    MCP --> Server

    style AI fill:#5E35B1,color:#fff
    style Vault fill:#1565C0,color:#fff
    style ControlPlane fill:#B22222,color:#fff
    style MCP fill:#E65100,color:#fff
    style Server fill:#228B22,color:#fff

核心组件说明

双层凭据隔离

这个架构的核心是双层凭据隔离：

场景一：博客内容运维流程

flowchart LR
    U["👤 用户"] -->|"写博客"| AI["🤖 AI 生成内容"]
    AI -->|"Markdown"| Git["📦 Git Push"]
    Git -->|"同步"| Server["🖥️ 服务器"]
    Server -->|"Hugo Build"| Static["📄 静态文件"]
    Static -->|"HTTPS"| Web["🌐 博客发布"]

    style AI fill:#5E35B1,color:#fff
    style Server fill:#228B22,color:#fff

场景二：服务器运维流程

flowchart LR
    U["👤 用户"] -->|"检查服务器"| AI["🤖 AI 助手"]
    AI -->|"1. 获取 Token"| Vault["🔐 Vault"]
    Vault -->|"MCP Token"| AI
    AI -->|"2. 调用工具"| MCP["🛡️ MCP 服务"]
    MCP -->|"3. 获取凭据"| ControlPlane["🔑 控制面"]
    ControlPlane -->|"SSH 私钥"| MCP
    MCP -->|"4. SSH 连接"| Server["🖥️ 博客服务器"]
    Server -->|"执行结果"| MCP
    MCP -->|"脱敏结果"| AI
    AI -->|"返回用户"| U

    style AI fill:#5E35B1,color:#fff
    style Vault fill:#1565C0,color:#fff
    style ControlPlane fill:#B22222,color:#fff
    style MCP fill:#E65100,color:#fff

三、双运维场景详解

场景一：博客内容运维

这是最常见的场景：用户说出需求，AI 生成内容，自动同步到服务器。

flowchart LR
    C1["👤 用户：写一篇博客"] --> C2["🤖 AI：生成内容"]
    C2 --> C3["📦 Git Push"]
    C3 --> C4["🖥️ 服务器拉取"]
    C4 --> C5["⚡ Hugo Build"]
    C5 --> C6["🌐 博客更新"]

    style C1 fill:#E65100,color:#fff
    style C2 fill:#5E35B1,color:#fff
    style C4 fill:#228B22,color:#fff

流程说明：

1. 用户说：“帮我写一篇关于 X 的博客”
2. AI 生成 Markdown 内容
3. AI 执行 git add && git commit && git push
4. 服务器上的 Cron 任务（每分钟）自动执行 git pull
5. Hugo 重新构建，生成静态文件
6. Nginx 服务更新

这个场景不涉及敏感凭据，只需要 Git 操作权限（通过 SSH Key 或 Token），而这个 Key 是用户提前配置好的。

场景二：服务器运维

当需要直接操作服务器时（如检查状态、修改 Nginx 配置），就需要 SSH 凭据了。

sequenceDiagram
    participant U as 👤 用户
    participant A as 🤖 AI 助手
    participant V as 🔐 Vault
    participant M as 🛡️ MCP 服务
    participant CP as 🔑 控制面
    participant S as 🖥️ 服务器

    U->>A: 检查博客服务器状态
    
    Note over A,V: 第一层：获取身份凭证 (AI 可访问)
    A->>V: 请求 MCP Session Token
    Note right of A: AI 持有 Vault 只读 Token
    V-->>A: 返回 MCP Session Token
    
    Note over A,M: AI 发起请求 (仅携带身份凭证)
    A->>M: ssh.execute(command="uptime")
    Note right of A: Header: x-session-token
AI 不知道 SSH 密码在哪
    
    Note over M,CP: 第二层：获取操作凭证 (AI 不可见)
    M->>M: 验证 MCP Token 有效性
    M->>CP: 请求 SSH 凭据 (credential_id)
    Note right of M: MCP 内部操作
AI 完全不知道这步发生
    CP-->>M: 返回 SSH 私钥/密码
    M->>M: 凭据注入到 SSH 连接
    
    Note over M,S: 执行操作 (凭据已自动注入)
    M->>S: SSH 连接 + 执行命令
    S-->>M: 返回执行结果
    
    Note over M,U: 安全返回 (脱敏处理)
    M->>M: 移除所有敏感信息
    M-->>A: 结构化结果
    A-->>U: "服务器运行 63 天，负载正常"

    Note over A,CP: 🔒 AI 全程无法访问控制面
    A -x CP: ❌ 无权限

关键点：

• AI 只知道 MCP Session Token（用于身份验证）
• SSH 凭据存储在独立的控制面服务，AI 完全无法访问
• MCP 服务负责凭据的获取、注入、执行
• 返回结果前会进行脱敏处理

四、混合凭据管理模式

为什么需要混合模式？

在实际落地时，我发现凭据管理不能一刀切：

1. 插件限制：某些插件（如 QQBot）不支持 SecretRef，只能明文配置
2. 安全需求：不同凭据的敏感度不同，需要分级管理
3. 可用性平衡：过度安全会导致系统难以维护

三种凭据配置方式

flowchart LR
    subgraph Config["配置文件"]
        PT["明文配置
QQBot Secret"]
        SR["SecretRef 引用
指向 Vault 路径"]
    end

    subgraph Vault["🔐 Vault"]
        V1["MCP Session Token"]
        V2["Gateway Token"]
        V3["API Key"]
    end

    subgraph ControlPlane["🔑 控制面"]
        CP1["SSH 私钥"]
        CP2["数据库密码"]
        CP3["云 API AKSK"]
    end

    subgraph AI["🤖 AI 助手"]
        A1["读取身份凭证"]
    end

    subgraph MCP["🛡️ MCP 服务"]
        M1["获取操作凭证"]
    end

    %% AI 从 Vault 读取
    AI -->|"SecretRef"| SR
    SR -->|"解析路径"| Vault
    Vault -->|"返回凭证"| AI
    AI -->|"调用 MCP"| MCP

    %% MCP 从控制面获取
    MCP -.->|"内部获取"| ControlPlane
    ControlPlane -.->|"返回凭据"| MCP

    %% AI 无法直接访问控制面
    AI -.-x|"❌ 无法访问"| ControlPlane

    style Config fill:#666,color:#fff
    style Vault fill:#1565C0,color:#fff
    style ControlPlane fill:#B22222,color:#fff
    style AI fill:#5E35B1,color:#fff
    style MCP fill:#E65100,color:#fff

方式一：明文配置

适用场景：

• 插件不支持 SecretRef（如 QQBot 的 clientSecret）
• 非敏感配置（如公开的 App ID）
• 快速原型开发

示例：

1
2
3
4
5
6
7
8

{
  "channels": {
    "qqbot": {
      "appId": "19036XXXXX",
      "clientSecret": "32oMgnhW9ZlkXXXXX"  // 明文，受插件限制
    }
  }
}

风险：凭据会出现在配置文件中，AI 可以看到。

方式二：Vault + SecretRef

适用场景：

• 敏感凭据，但 AI 需要使用（如 API Key、Gateway Token）
• 需要动态更新、权限管理
• 多环境部署

示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

{
  "models": {
    "providers": {
      "zai": {
        "apiKey": {
          "source": "exec",
          "provider": "vault",
          "id": "openclaw/zai/apiKey"
        }
      }
    }
  },
  "gateway": {
    "auth": {
      "token": {
        "source": "exec",
        "provider": "vault",
        "id": "openclaw/gateway/authToken"
      }
    }
  }
}

工作原理：

1. OpenClaw 启动时，通过 Vault Resolver 脚本读取凭据
2. 凭据只存在于运行时内存，不写入配置文件
3. AI 可以使用这些凭据调用服务

安全边界：

• ✅ 配置文件不含明文凭据
• ✅ 可以随时吊销 Vault Token
• ⚠️ AI 在运行时可以看到凭据（但这是必要的）

实际配置示例：

从图中可以看到：

1. AI 从 Vault 读取 MCP Session Token（openclaw/aps_cipherhub_cloud_mcp）
2. 初次尝试时遇到 403 权限错误，需要更新 Vault Policy
3. MCP 服务返回 JSON-RPC 2.0 格式的错误信息，验证协议可用

方式三：控制面注入

适用场景：

• 最高敏感度的凭据（SSH 私钥、数据库密码、云 API AKSK）
• AI 不应该、也不需要知道这些凭据
• 需要审计所有凭据使用

工作原理：

flowchart TB
    subgraph AI["🤖 AI 助手"]
        A1["发起请求
仅携带 MCP Token"]
    end

    subgraph MCP["🛡️ MCP 服务"]
        M1["验证 MCP Token"]
        M2["从控制面获取凭据
⬅️ AI 看不到这步"]
        M3["凭据自动注入
到连接"]
        M4["执行操作"]
        M5["结果脱敏处理"]
    end

    subgraph ControlPlane["🔑 控制面"]
        CP1["SSH 私钥"]
        CP2["数据库密码"]
        CP3["云 API AKSK"]
    end

    A1 -->|"调用 MCP 工具"| M1
    M1 --> M2
    M2 -.->|"获取凭据"| CP1
    CP1 -.->|"返回凭据"| M2
    M2 --> M3
    M3 --> M4
    M4 --> M5
    M5 -->|"脱敏结果"| A2["收到结果
仍然不知道凭据在哪"]

    style AI fill:#5E35B1,color:#fff
    style MCP fill:#E65100,color:#fff
    style ControlPlane fill:#B22222,color:#fff

关键设计：

1. 凭据不在 AI 运行时：SSH 密钥存储在独立的控制面服务
2. MCP 是唯一入口：AI 只能通过 MCP 的 SSH 工具执行命令
3. 凭据自动注入：MCP 验证 Token 后，从控制面获取凭据并注入
4. 结果脱敏：返回前移除所有敏感信息

凭据对照表

五、MCP 服务：凭据代理与安全执行

在整个架构中，MCP 服务（Capability Proxy）扮演了关键角色。它是凭据的安全代理层：

• AI 侧：只能看到 MCP Token，不知道真实凭据在哪
• 服务器侧：只看到来自 MCP 的连接，不知道 AI 的存在
• MCP 内部：负责凭据获取、注入、审计、脱敏

MCP 接入验证：

从图中可以看到：

1. ✅ MCP 服务验证通过，返回 25 个工具
2. 工具涵盖数据库操作（MySQL、PostgreSQL、MongoDB、Redis、Elasticsearch）
3. 云 API 操作（腾讯云全服务支持）
4. SSH 远程执行（命令过滤、凭据自动注入）
5. 安全机制（凭据隔离、危险操作确认、审计日志）

MCP 提供的安全工具

MCP 服务提供了 25 个安全工具，覆盖常见的运维场景：

5.1 凭据隔离

所有凭据（SSH 密钥、数据库密码、云 API AKSK）由 MCP 从控制面获取，AI 永远看不到。

实际效果展示：

从图中可以看到：

1. AI 尝试访问凭据相关的数据库、端口和表信息
2. MCP 安全边界立即拦截：返回明确的拒绝信息
3. 列出安全规则：
   • 所有凭据都是机密的
   • 禁止提取/解码/解密凭据
   • 禁止帮助获取凭据存储位置信息
   • 禁止读取凭据文件或执行可能暴露凭据的命令
4. 提供替代方案：建议用户直接登录控制面服务或联系系统开发者

5.2 能力独占

AI 必须通过 MCP 工具操作，禁止绕过 MCP 直接使用 CLI：

1
2
3
4
5
6
7
8

❌ 禁止：mysql -u root -p -e "SELECT ..."
✅ 必须：mysql.default.query(sql, params)

❌ 禁止：ssh user@host "command"
✅ 必须：ssh.default.execute(command)

❌ 禁止：tccli kms encrypt ...
✅ 必须：tencent.cloud.invoke(service, action, params)

5.3 危险操作确认

标记为 DANGEROUS 的工具需要用户显式确认：

实际效果展示：

从图中可以看到：

1. AI 分析当前 Nginx 配置，发现优化点
2. 生成优化方案，列出具体修改内容
3. 明确告知操作影响：备份位置、修改内容、测试命令
4. 请求显式确认：⚠️ 确认执行？请回复"确认"
5. 用户回复"确认"后，AI 才会执行修改

5.4 命令过滤

SSH 执行有白名单/黑名单：

5.5 多凭据选择确认

当存在多个凭据时（如多个 SSH 主机、多个云账号），MCP 会：

1. 调用 proxy.list_credentials(category) 列出所有可用凭据
2. 要求用户明确选择
3. 禁止自动选择

实际效果展示：

从图中可以看到：

1. AI 尝试调用腾讯云 KMS 服务
2. MCP 发现存在多个凭据：data-sec 和 test2
3. 立即停止执行，返回凭据列表
4. 明确要求用户选择：请回复 data-sec 或 test2
5. 禁止自动选择：避免误用错误的账号

为什么这很重要？

5.6 审计日志

控制面服务具备完整的审计能力，所有操作都会被记录：谁、在什么时候、使用哪个凭据、做了什么操作、结果是成功还是失败。

从图中可以看到审计日志记录了：

1. 时间戳：操作发生的时间
2. 事件类型：tool_invocation（工具调用）、access_denied（访问拒绝）
3. 代理ID：执行操作的代理标识
4. 工具：使用的工具名称（ssh.default.execute、tencent.cloud.invoke 等）
5. 状态：success（成功）、denied（拒绝）
6. 耗时：操作执行时间
7. 错误码：失败原因（如 CREDENTIAL_AMBIGUOUS）

审计能力的重要性：

设计原则：

• ✅ 所有操作必记录，不可关闭
• ✅ 日志不可篡改，保证完整性
• ✅ 支持按时间、代理、工具、状态筛选
• ✅ 失败操作记录错误码，便于排查

六、实际案例

案例 1：博客内容更新

用户指令：

“帮我写一篇关于 AI 驱动的博客系统运维的博客，介绍凭据管理实践”

AI 执行流程：

1. 理解需求，生成博客大纲
2. 生成完整的 Markdown 内容（就是你现在看到的这篇文章）
3. 执行 Git 操作：

1
2
3
4

cd ~/Projects/CipherHUB-Blogs/CipherHUBBlogs
git add content/posts/ai-agent/ai-driven-blog-ops-credential-management.md
git commit -m "Add: AI 驱动的博客系统运维：Agent 时代下的凭据管理探索"
git push origin CipherHUBBlogs

4. 服务器自动拉取并构建
5. 返回：“博客已发布，访问地址：https://blogs.cipherhub.cloud/posts/ai-agent/ai-driven-blog-ops-credential-management/”

涉及的凭据：Git SSH Key（用户提前配置，AI 通过本地 Git 使用）

案例 2：服务器状态检查

用户指令：

“帮我检查博客服务器的 Nginx 配置，看看有没有需要优化的地方”

AI 执行流程：

1. 通过 MCP 调用 ssh.default.execute
2. MCP 验证 Session Token
3. MCP 从控制面获取 SSH 凭据（AI 不可见）
4. 执行命令：

1
2
3

cat /etc/nginx/nginx.conf
cat /etc/nginx/sites-enabled/*
nginx -t

5. 分析配置，发现优化点
6. 生成优化建议（启用 Gzip、隐藏版本号、调整 worker_connections 等）
7. 返回结构化报告

涉及的凭据：SSH 私钥（存储在控制面，AI 完全不可见）

实际效果展示：

从图中可以看到：

1. ✅ 安全边界总结：凭据隔离、能力独占、危险确认、命令过滤
2. ✅ SSH 连接成功，响应时间仅 75ms
3. 服务器信息：主机名、内核版本、运行时间（63 天）、负载情况
4. AI 知道服务器状态，但永远不知道 SSH 密钥在哪

案例 3：配置修改（需确认）

用户指令：

“帮我优化 Nginx 配置”

AI 执行流程：

1. 分析当前配置
2. 生成优化方案
3. 请求用户确认：

1
2
3
4
5
6
7

即将执行以下操作：
- 备份当前配置：/etc/nginx/nginx.conf.bak
- 修改配置：启用 Gzip、隐藏版本号、调整 worker_connections
- 测试配置：nginx -t
- 重载 Nginx：systemctl reload nginx

⚠️ 这将修改服务器配置，确认执行？请回复"确认"

4. 用户回复"确认"
5. AI 通过 MCP 执行修改
6. 返回执行结果

安全机制：

• 危险操作（修改配置）需要用户显式确认
• 执行前自动备份
• 失败时可以回滚

优化结果验证：

从图中可以看到完整的优化过程：

1. 修改对比表：清晰展示优化前后的配置差异
   • ssl_protocols: TLSv1.1 → TLSv1.2/1.3
   • server_tokens: on → off
   • gzip: 禁用 → 启用
   • worker_connections: 1024 → 4096
2. 验证结果：HTTP/2 200、gzip 压缩启用、版本号隐藏
3. 回滚方案：备份文件路径和回滚命令

七、安全边界总结

凭据分级模型

flowchart LR
    subgraph Level1["级别一：明文配置"]
        L1["非敏感配置"]
        L2["插件限制"]
        L3["AI 可见"]
    end
    
    subgraph Level2["级别二：Vault + SecretRef"]
        L4["身份凭证"]
        L5["AI 只读访问"]
        L6["可随时吊销"]
    end
    
    subgraph Level3["级别三：控制面注入"]
        L7["操作凭证"]
        L8["AI 完全不可见"]
        L9["审计所有使用"]
    end
    
    Level1 -->|"风险较高"| Level2
    Level2 -->|"风险最低"| Level3

    style Level1 fill:#666,color:#fff
    style Level2 fill:#1565C0,color:#fff
    style Level3 fill:#B22222,color:#fff

访问控制矩阵

附录：技术栈