AI Agent 安全危机：54% 企业已发生事故，凭证共享漏洞如何成为下一个重大威胁

事故已经发生，只是你还不知道

VentureBeat 近期披露了一份覆盖 107 家企业的调研报告，结论直接：54% 的受访企业已经确认发生过 AI Agent 安全事故，或者经历了"险些出事"的 near-miss 场景。这不是预警，是已经发生的现实。

更让人不安的数字藏在后面——只有约 1/3 的企业 为每个 Agent 配置了独立的 scoped identity。换句话说，绝大多数企业的 Agent 在共用凭证运行，一个 Agent 被攻破，等于整个凭证池暴露。

这个问题不是"AI 太强大了所以危险"这种哲学层面的担忧，而是非常具体的工程失误：开发团队把 Agent 当工具脚本在用，却给了它生产环境的数据库读写权、S3 bucket 的全量访问、甚至 Slack/GitHub 的 OAuth token。权限边界从来没划清楚过。

凭证共享：一个被低估的攻击面

典型的问题场景长这样：一家公司部署了三个 Agent——一个负责处理客服工单、一个做内部知识库检索、一个跑定期数据报告。为了方便，DevOps 团队给这三个 Agent 配了同一套服务账户凭证，存在环境变量里，或者硬编码在 .env 文件中。

# 常见的危险配置
OPENAI_API_KEY=sk-...
DB_CONNECTION_STRING=postgres://admin:password@prod-db:5432/main
AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=...

这套凭证被注入到三个 Agent 的运行环境里，没有任何 scope 限制。客服 Agent 理论上只需要读取工单表，但它持有的凭证能写入整个数据库。一旦这个 Agent 遭遇 prompt injection 攻击——攻击者在用户提交的工单里嵌入恶意指令——Agent 就可能被操控执行超出预期的操作。

Prompt injection 在 Agent 场景下的危害远超普通 LLM 交互，因为 Agent 具备工具调用能力。攻击者不需要让模型"说错话"，只需要让它调用错误的 tool，传入精心构造的参数。

更隐蔽的风险在于 credential leakage through context：Agent 在处理任务时可能将 API key、connection string 等敏感信息写入日志、塞进向量数据库的 embedding，或者通过 function call 的参数暴露给下游服务。这些泄露路径在传统安全审计中几乎不会被覆盖。

权限蔓延的系统性根源

AI Agent 安全问题的根源不是某个具体的 bug，而是开发节奏和安全节奏之间的结构性错位。

维度	现状	应有状态
身份管理	多个 Agent 共用服务账户	每个 Agent 独立 identity + scoped token
权限粒度	宽泛的 read/write 权限	最小权限原则，按任务动态授权
审计日志	无或混在应用日志里	Agent 操作独立可追溯日志
凭证生命周期	长期静态 token	短效 token + 自动轮换
异常检测	无	基于行为基线的实时告警

这张表里的"现状"列，描述的正是那 54% 企业里相当比例的真实配置。问题不在于没有技术手段解决，而在于这些手段在 Agent 快速铺开的过程中被跳过了。

产品团队看到 Agent 能用、能跑通 demo，就开始推进上线；安全团队往往在事后才介入，等到要做 audit 的时候，Agent 已经在生产环境跑了几个月，凭证散落在十几个地方。

可操作的防御框架

针对上面的风险，以下是一套可以立即开始落地的防御动作，按优先级排列：

第一步：为每个 Agent 创建独立的服务账户

在 AWS 里是独立 IAM Role，在 GCP 是独立 Service Account，在 Azure 是独立 Managed Identity。这一步成本极低，但收益是隔离爆炸半径。一个 Agent 的凭证泄露不会横向扩散到其他 Agent。

第二步：实施最小权限，用 IAM Condition 精确收口

// AWS IAM Policy 示例：限制 Agent 只能读取特定 S3 前缀
{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::company-data/agent-reports/*",
  "Condition": {
    "StringEquals": {
      "aws:RequestedRegion": "us-east-1"
    }
  }
}

不要给 s3:*，不要给 arn:aws:s3:::*。

第三步：对所有 Agent 的 tool call 做输入校验和输出审计

在 Agent framework 层（无论是 LangGraph、AutoGen 还是自研编排层）加拦截器，对 tool call 的参数做白名单校验，对输出做敏感信息扫描。推荐使用 detect-secrets 或 trufflehog 集成进 CI pipeline，同时在 Agent runtime 里做实时扫描。

第四步：把 Agent 的操作日志接入 SIEM

Agent 每次调用工具、每次访问外部 API，都应该产生结构化日志，字段包括 agent_id、session_id、tool_name、input_hash、output_hash、timestamp。这些日志接入 Splunk、Datadog 或 OpenSearch，设置异常行为告警（例如：某 Agent 在非工作时间突然调用了从未使用过的 API endpoint）。

第五步：定期做 Agent 的 red team 测试

专门针对 prompt injection 的测试不能用传统渗透测试替代。可以用 Garak、PyRIT 等工具对 Agent 做系统性的对抗测试，重点测试：恶意用户输入能否操控 Agent 调用敏感工具、Agent 是否会在响应中泄露 system prompt 或凭证、多 Agent 协作场景下恶意指令能否通过 Agent A 传播到 Agent B。

安全债迟早要还

从 2025 年下半年开始，AI Agent 的部署速度明显加快。用 Claude Code、Codex、Gemini CLI 这类编码 Agent 做自动化开发流程的团队越来越多，这些工具本身设计上已经考虑了权限边界，但企业内部自研的 Agent 和基于 API 组装的 workflow，安全设计往往是欠缺的。

54% 这个数字会继续升高，除非开发流程里把 Agent 身份管理和权限设计当作和代码质量同等重要的事情来做。安全债和技术债一样，借得越晚，利息越高。

---

如果你的团队在接入各类 Agent 和模型 API 时遇到多账户管理混乱、合规要求复杂的问题，可以看看 XycAi 词元平台。它提供 OpenAI 兼容接口，一个 key 接入 200+ 全球模型，支持 Claude Code、Codex、Gemini CLI 一键切换，持有大模型算法备案号，企业合规和发票都能走正规流程。在权限管控越来越严格的背景下，把模型访问收归统一的、可审计的 API 网关，本身也是降低凭证泄露风险的一步。