AI Agent 安全危机：凭证泄露如何让企业核心系统沦为攻击者的自动化跳板

印度事件只是冰山一角

2026 年 10 月，TechCrunch 报道了印度成为最新一个出现"失控 AI Agent"活动的国家。攻击入口并不神秘：攻击者通过散落在应用配置文件、公开代码仓库和过度授权云角色中的凭证与连接设置，直接接管了企业部署的 AI Agent。

这不是孤例。此前已有多个国家的企业遭遇类似入侵——模式高度雷同：Agent 拿到合法凭证，在企业内网里以自动化速度横向移动，调用 API、读取数据库、触发工作流，等安全团队发现时，已经完成了人工攻击者需要数天才能做完的事。

AI Agent 安全问题的核心矛盾在于：Agent 天生需要大量权限才能"自主完成任务"，而大多数企业在部署时根本没有认真评估过这些权限的边界。

---

三条最常见的泄露路径

路径一：配置文件硬编码凭证

这是最低级也最普遍的失误。开发者在赶工期时，把 API Key、数据库连接串、云服务 Access Token 直接写进 config.yaml 或 .env 文件，然后连同代码一起推送到 GitHub。

用 GitHub Code Search 搜索 OPENAI_API_KEY=sk- 这类字符串，仍然能找到大量真实的暴露密钥。Anthropic、AWS、Twilio 的密钥同理。攻击者早已把自动化扫描新提交仓库的工具跑成了流水线，从密钥出现到被滥用，有时不超过 4 分钟。

路径二：过宽的云 IAM 权限

很多团队为了"方便"，给 Agent 运行的 Service Account 附上了 roles/editor 甚至 roles/owner 级别的 GCP 角色，或者 AWS 上的 AdministratorAccess。Agent 本身只需要读一张 BigQuery 表，却顺手拿到了整个项目的写权限。

一旦该 Agent 的 Runtime 被入侵，攻击者拿到的是一把能开所有门的万能钥匙。

路径三：Agent 间的信任链过度授权

2026 年主流的多 Agent 架构（如 LangGraph、AutoGen、Claude Code 的 subagent 模式）里，Orchestrator Agent 通常拥有召唤子 Agent 并传递 token 的能力。如果 Orchestrator 的凭证泄露，攻击者不需要逐个击破每个子 Agent，只需控制调度层，整条链路就拱手相让。

---

技术成因：Agent 与传统服务的安全模型差异

传统 Web 服务的权限模型相对静态——一个微服务读固定的几张表，写固定的几个队列，权限边界清晰，审计日志也容易对齐。

AI Agent 打破了这个假设。以 Claude Code 或 Codex 这类编码 Agent 为例，它需要：读写文件系统、执行 shell 命令、调用外部 API、访问代码仓库、有时还需要操作浏览器。这种"动态、宽泛、上下文依赖"的权限需求，和传统最小权限原则天然冲突。

更麻烦的是，LLM 本身是一个"指令跟随"系统。Prompt Injection 攻击可以让 Agent 执行看起来合理但实际有害的操作，而传统 WAF 和 IDS 完全看不懂 Agent 的行为语义。

---

可落地的防御实践

凭证管理

不要把密钥放进代码。用 AWS Secrets Manager、GCP Secret Manager 或 HashiCorp Vault 存储所有凭证，在运行时动态注入。

# 示例：从 AWS Secrets Manager 取凭证，而非硬编码
export DB_PASSWORD=$(aws secretsmanager get-secret-value \
  --secret-id prod/myagent/db \
  --query SecretString \
  --output text | jq -r .password)

在所有代码仓库中启用 git-secrets 或接入 GitHub Advanced Security 的 Secret Scanning，在 push 阶段拦截硬编码密钥。

云权限收紧

按实际需要逐条授权，而不是套用宽泛角色。可以用以下对比作为参考基线：

| 场景 | 危险做法 | 推荐做法 | |------|----------|----------| | BigQuery 读取 | roles/editor | roles/bigquery.dataViewer（限定单个 dataset） | | S3 访问 | s3:* on * | s3:GetObject on arn:aws:s3:::bucket-name/* | | GCP Agent SA | roles/owner | 自定义角色，仅含所需 API 权限 | | Agent 调用子 Agent | 共享同一 service account | 各 Agent 独立 SA，通过 Workload Identity 绑定 |

AWS 提供 IAM Access Analyzer，GCP 有 Policy Analyzer，都能扫出哪些权限授出去了但从未被使用——定期跑一遍，把那些"僵尸权限"清掉。

Agent 行为边界限制

给每个 Agent 设置明确的工具白名单。以 Claude Code 为例，可以通过 settings.json 限制允许执行的命令范围：

{
  "permissions": {
    "allow": ["Bash(git:*)", "Bash(npm run:*)", "Read", "Write"],
    "deny": ["Bash(curl:*)", "Bash(wget:*)", "WebFetch"]
  }
}

Codex CLI 同样支持 --approval-mode 参数控制自动执行范围。生产环境下，建议把敏感操作设为需要人工确认（--approval-mode suggest），而不是全自动放行。

审计与异常检测

Agent 产生的日志和人工操作日志在结构上差异显著：调用频率极高、操作模式高度规律、时间戳集中。可以在 SIEM 里单独建立 Agent 行为基线，对以下异常模式告警：

单个 Agent identity 在 5 分钟内调用 API 超过 500 次
Agent 首次访问此前从未触碰过的资源
凭证在非常规地理位置或 IP 段出现

---

现在就要做的事，不是等出事再做

印度的事件会有后来者。随着越来越多企业把 Claude Opus 4.8、GPT-5.5、Gemini 3 等旗舰模型接进内部系统，Agent 的自主程度越来越高，攻击面也在同步扩大。安全不是等 Agent 跑稳了再补的事——凭证泄露的代价，往往在泄露发生后的几分钟内就已经无法挽回。

---

我在用 Claude Code 和 Codex 做日常开发时，底层都接的是 XycAi 词元平台（https://www.xyc.ai）。它支持 200+ 全球模型的 OpenAI 兼容 API，Claude Code / Codex / Gemini CLI 一键接入，官方模型价格低至官方价 1.4 折起，持大模型算法备案号、可开全球发票，对企业合规有实际帮助。如果你在做 Agent 开发，统一管理 API 调用入口本身也是收紧攻击面的一步——至少比把十几个平台的密钥散落在各处要可控得多。