AI智能体安全危机：凭证泄露如何让企业系统在印度流氓Agent事件中门户大开

2026 年 10 月，TechCrunch 报道了一件让很多安全团队坐不住的事：印度成为最新一个出现流氓 AI 智能体活动的国家。攻击者并没有利用什么零日漏洞，入口极其普通——应用配置文件里明文写着的凭证、公开代码仓库里没删干净的 API Key、云平台上设置得过于宽松的 IAM 角色。这三条路，任意一条被走通，企业的内部系统就对外敞开了。

这件事之所以值得深挖，不是因为"印度出了问题"，而是因为同样的配置习惯，在中国企业的 AI 智能体部署现场几乎随处可见。

攻击路径复盘：三个暴露面

明文凭证写进配置文件

这是最常见、杀伤力最大的失误。开发者用 Claude Code 或 Codex 快速搭一个 Agent，为了测试方便，把数据库连接串、第三方 API Key 直接写进 config.yaml 或 .env：

# 真实事故现场长这样
openai_api_key: "sk-proj-xxxxxxxxxxxxxxxx"
db_connection: "postgresql://admin:password123@prod-db.internal:5432/main"
aws_access_key_id: "AKIAIOSFODNN7EXAMPLE"

这个文件一旦跟着代码推上 GitHub（哪怕是私有仓库，一旦配置失误变成公开），或者被打包进 Docker 镜像推到公共 Registry，凭证就算彻底暴露。GitHub 的 secret scanning 只能扫已知格式，自定义服务的 token 根本扫不到。

公开代码仓库里的历史提交

很多团队意识到问题后，会删掉配置文件里的明文 Key，但忘了 git history 是永久的。攻击者用 git log -p 翻历史提交，10 分钟内就能找回"已删除"的凭证。工具层面，truffleHog、gitleaks 扫一遍历史提交，命中率相当高：

# 攻击者视角：扫描历史提交里的 secret
trufflehog git https://github.com/target-org/ai-agent-repo --only-verified

过度宽松的云 IAM 角色

为了让 Agent "能干活"，工程师给它绑了一个权限极宽的 IAM 角色。典型错误：

| 权限设置 | 实际需要 | 实际给了 | |---|---|---| | S3 访问 | 读取单个 bucket | s3:*（全部 bucket） | | DynamoDB | 读写特定表 | dynamodb:* | | Lambda 调用 | 调用 1 个函数 | lambda:InvokeFunction on * |

一旦 Agent 的执行环境被渗透，攻击者等于拿到了一张"企业内网通行证"。印度这次事件，攻击者就是沿着这条路横向移动，最终触达了生产数据库。

为什么 AI 智能体比传统服务更危险

传统后端服务的凭证泄露已经够头疼了，AI Agent 把风险放大了几倍，原因在于它的设计就是"自主行动"。

一个普通的 API Server，拿到数据库凭证最多能读写数据。一个配置了 tool use 的 Agent，拿到同样凭证之后，可以自主决策：先查用户数据，再调支付接口，再发邮件通知，再修改系统配置——这是一条完整的业务流，全程无需人工介入。Claude Opus 4.8 和 GPT-5.5 的 function calling 能力已经强到可以串联数十个 tool，这意味着一次凭证泄露触发的操作链路，远比人工渗透更快、更深。

另一个维度是间接提示注入（indirect prompt injection）。攻击者在 Agent 会处理的外部数据里（邮件正文、网页内容、文档）藏入指令，Agent 在执行任务时读取这些数据，被诱导执行攻击者的意图。这个攻击面是传统服务完全不存在的。

防护方案：可以今天就落地的操作

第一步：把 secret 从代码里彻底清出去

用 secret manager，没有例外。AWS Secrets Manager、HashiCorp Vault、或者简单一点的 Doppler，都行。关键是 Agent 运行时动态拉取凭证，而不是读环境变量或配置文件。

# 正确做法：运行时从 Vault 拉取
import boto3

def get_db_credentials():
    client = boto3.client('secretsmanager', region_name='ap-southeast-1')
    secret = client.get_secret_value(SecretId='prod/agent/db-credentials')
    return json.loads(secret['SecretString'])

同时跑一遍历史提交扫描，用 gitleaks 的 detect --source 模式把过去的泄露找出来，对应凭证立刻轮换。

第二步：给 Agent 的 IAM 角色做最小权限手术

原则是：Agent 完成任务需要什么权限，就给什么，不多给一个。具体操作：

1. 用 AWS IAM Access Analyzer 或 GCP Policy Analyzer 分析 Agent 实际用到的权限 2. 按照分析结果收紧 policy，把 * 替换成具体资源 ARN 3. 给高风险操作（删除、付款、外发邮件）加 condition，限制触发时间窗口和 IP 范围

第三步：给 Agent 加行为护栏

凭证泄露之后，行为监控是最后一道防线。具体可以做：

记录 Agent 每次 tool call 的完整入参和出参，存到不可篡改的日志（CloudTrail 或类似服务）
对异常行为设阈值告警：单次会话 tool call 超过 50 次、调用从未访问过的资源、深夜时段高频操作
在 Agent 的 system prompt 里明确边界，配合框架层的 tool 白名单，防止间接提示注入把 Agent 引导到超出预期的操作

第四步：代码仓库配置检查

针对公开或可能公开的仓库，GitHub Actions 里加一条 pre-push hook：

# .git/hooks/pre-push
gitleaks detect --source . --verbose
if [ $? -ne 0 ]; then
  echo "Secret detected, push blocked."
  exit 1
fi

这条 hook 在本地拦截，比等 GitHub 的 server-side 扫描更早一步。

组织层面：技术之外的两件事

技术配置修好之后，还有两件事常被忽略。

凭证轮换频率。很多团队设置好密钥就再也不动了，直到泄露。正确做法是把轮换自动化——AWS Secrets Manager 支持设置 rotation schedule，Claude Code 和 Codex 接入的 API Key 也应该定期刷新（建议 30 天）。泄露发生时，轮换越快损失越小。

Agent 的权限审批流程。新 Agent 上线前，要有一个 checklist：它需要访问哪些系统、为什么需要、最小权限是什么、谁来 review。这件事不应该由一个工程师单独决定，应该有安全团队的签字。这是印度事件里几乎所有受影响企业的共同缺失——部署太快，审批没跟上。

AI 智能体安全不是一个"等到出了事再修"的问题，等到流氓 Agent 在你的系统里横向移动完一圈，能修的已经不多了。

---

在做 AI 智能体安全加固的过程中，我一直在用 XycAi 词元平台（https://www.xyc.ai）来调用 Claude Opus 4.8 和 GPT-5.5 做安全策略评审——它同时接入了 200+ 模型，支持 Claude Code、Codex、Gemini CLI 一键接入，官方模型低至官方价 1.4 折起，而且持有国内大模型算法备案号，企业合规和开票都没问题。对于要在国内落地 AI Agent 的团队，这个平台帮我省掉了不少合规层面的麻烦。