AI Agent 凭据安全架构思考：执行层隔离与凭据三要素

一、Agent 的本质

Agent = LLM 推理 + 环境上下文 + Skills/MCP 执行

组成部分	作用
LLM 推理	理解意图、规划步骤、生成调用指令
环境上下文	当前状态、历史对话、可用资源
Skills/MCP	具体的工具调用能力（API 封装、操作方式）

这个公式看似简单，却隐含了一个关键的安全问题：当 Agent 需要调用外部服务时，凭据该如何处理？

二、核心矛盾：LLM 能看到一切

当 Agent 需要调用云服务、企业微信等外部系统时，面临一个根本性矛盾：

1
Agent 需要凭据才能调用 → LLM 能看到 Agent 运行时的一切 → 凭据可能泄露

LLM 的"视力"问题：

凭据进入运行时 → LLM 可能在 reasoning 中分析它
可能在回复中不小心输出它
可能被 prompt injection 骗出来

这不是理论风险。如果 token 在 Agent 运行时存在，LLM 就能"看到"它。即使使用临时 token（有效期 2 小时甚至 1 天），在这个时间窗口内，凭据依然可能被泄露。

三、本质解法：执行层隔离

原则：LLM 只决定"做什么"，不接触"怎么做"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
┌─────────────────────────────────────────┐
│              LLM 层                      │
│  输出意图：call("service", action, args) │
│  （不含任何凭据）                         │
└─────────────────┬───────────────────────┘
                  ↓
┌─────────────────────────────────────────┐
│           执行引擎（隔离层）               │
│  1. 解析意图                              │
│  2. 从安全存储注入凭据（LLM 不可见）       │
│  3. 执行 API 调用                        │
│  4. 返回结果（过滤敏感信息）               │
└─────────────────────────────────────────┘

隔离的两种实现方式

方式	原理	优点	缺点
外部代理	独立二进制服务，所有 Agent 调用都经过它	通用、无侵入	多一跳、架构复杂
内部 Hook	在 Agent 框架层做占位符替换，运行时注入凭据	紧密、低延迟	需改造 Agent 代码

共性目标：凭据永远不进入 LLM 的上下文窗口。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
# ❌ 错误：token 进入 LLM 上下文
def skill_send_message(to, content):
    token = get_token()  # LLM 能看到这个变量
    response = requests.post(url, headers={"Authorization": f"Bearer {token}"}, ...)
    return f"发送成功，使用的 token 是 {token[:8]}..."  # 泄露

# ✅ 正确：执行层隔离
def skill_send_message(to, content):
    # LLM 只传入 to 和 content
    # token 在执行层注入，LLM 看不到
    return execute_with_auth(
        service="wechat",
        action="send_message",
        params={"to": to, "content": content}
    )

四、概念澄清：凭据 vs Skills

在讨论 Agent 安全时，有两个概念经常被混淆：

概念	本质	作用
凭据	权限的载体	决定 Agent 能做什么（AKSK 的 IAM 策略、Token 的 scope）
Skills/MCP	调用方式的封装	决定 Agent 知道怎么用（API 格式、参数结构）

关键认知：

Skills 不表达权限范围
Skills 不需要"被授权"
Agent 最终能执行什么操作，直接取决于它能使用哪些凭据

1
2
3
凭据 → 云厂商 IAM 策略 → 定义权限边界
                ↓
         Skills 调用 API → 凭据权限决定成功或 403

所以问题不是"Skills 怎么授权"，而是"用户如何把自己的调用能力安全地委托给 Agent"。

五、凭据安全的三个维度

判断 Agent 是否安全执行操作，取决于三点：

维度	说明	风险差异
权限大小	凭据被授予了哪些操作权限	权限越大，泄露后影响越大
生存周期	凭据有效期多久	长期凭据泄露后难补救，短期 token 风险窗口小
生效范围	凭据能在哪里使用	公网可用 = 泄露后风险无限放大；内网/特定机器 = 泄露影响可控

关键认知：生效范围是最后一道防线。即使凭据泄露，如果它只能在特定内网或特定机器上使用，攻击者也难以利用。

1
2
3
4
5
凭据泄露风险 = 权限大小 × 生存周期 × 生效范围

例如：
- 公网 AKSK + 完全权限 + 永久 → 风险极高
- 内网 Token + 只读权限 + 2小时 → 风险可控

风险等级对照

场景	权限	周期	范围	风险等级
云厂商主账号 AKSK	完全控制	永久	公网	🔴 极高
子账号只读 AKSK	只读	永久	公网	🟠 高
临时 STS Token	限定操作	1-12小时	公网	🟡 中
内网专用 Token	限定操作	1天	内网	🟢 较低
TEE/HSM 内凭据	限定操作	永久	不可导出	✅ 最安全

六、总结

Agent 安全的核心是执行层隔离，让 LLM 不接触凭据
凭据是权限载体，Skills 只是调用方式，两者解耦
判断凭据安全性三要素：权限大小、生存周期、生效范围

最后，用一段话概括本文的核心观点：

AI Agent 的本质是 LLM 推理 + 环境上下文 + Skills/MCP 执行。其中凭据安全的核心矛盾在于：LLM 能看到运行时的一切，凭据一旦进入上下文就可能泄露。解决这个问题的本质是执行层隔离——让 LLM 只决定"做什么"，不接触"怎么做"。在概念上要区分清楚：凭据是权限的载体，决定 Agent 能做什么；Skills/MCP 是调用方式的封装，只表达"知道怎么用"，不表达权限范围。而判断 Agent 是否安全执行操作，看三点：权限大小（凭据被授予了什么操作能力）、生存周期（凭据有效期多久）、生效范围（凭据能在哪里使用）。

一、Agent 的本质#

二、核心矛盾：LLM 能看到一切#

三、本质解法：执行层隔离#

隔离的两种实现方式#

四、概念澄清：凭据 vs Skills#

五、凭据安全的三个维度#

风险等级对照#

六、总结#