AI Agent 安全危机：54% 企业已中招，凭证共享正在成为失控的权限定时炸弹

54%，这个数字比大多数人预想的要高

VentureBeat 近期披露了一份覆盖 107 家企业的 AI Agent 安全调研，结论相当直接：超过 54% 的受访企业已经发生过经确认的 AI Agent 安全事故，或与事故擦肩而过。不是"担心可能发生"，是"已经发生了"。

更让人警觉的细节藏在另一组数字里——只有约三分之一的企业为每个 Agent 分配了独立的、权限受限的身份（scoped identity）。换句话说，剩下三分之二的企业，Agent 要么共享同一套服务账号凭证，要么直接用人类员工的账号跑任务。这意味着一旦某个 Agent 被注入恶意指令、出现 prompt injection，攻击面就不再是单个任务，而是整个企业的数据库、代码仓库、邮件系统。

这个问题之所以被低估，有一个很具体的原因：Agent 的上线速度远远跑在安全策略前面。研发团队今天用 Claude Code 或 Codex 搭一个自动化 Agent，明天就接入了生产数据库的读写权限，安全团队甚至不知道这个 Agent 存在。

---

凭证共享：最容易被忽视的攻击面

凭证共享（credential sharing）在传统软件开发里就已经是反模式，在 AI Agent 场景里问题被放大了好几倍。原因在于 Agent 的行为本质上是不确定的——同样的 prompt，在不同上下文、不同模型版本下可能产生完全不同的工具调用序列。

一个典型的高风险配置大概长这样：

# 危险：多个 Agent 共用同一个 service account
OPENAI_API_KEY: sk-prod-xxxx
DB_CONNECTION: postgres://admin:password@prod-db:5432/main
AWS_ACCESS_KEY_ID: AKIA...
AWS_SECRET_ACCESS_KEY: xxxx

这套配置被三个不同功能的 Agent 共享——一个负责客服回复，一个负责数据报告生成，一个负责代码审查。任何一个 Agent 出问题，攻击者获得的都是完整的数据库管理员权限和 AWS 全量访问权。

Prompt injection 是触发凭证滥用最常见的路径。攻击者在用户输入、网页内容、甚至 PDF 附件里嵌入隐藏指令，让 Agent 在完成正常任务的同时，顺手把凭证发到外部端点，或者执行数据外泄操作。2025 年以来，已有多起公开披露的案例涉及多租户 SaaS 平台上的 Agent 被横向移动攻击。

---

权限最小化：开发者可直接落地的操作清单

理论讲够了，下面是具体能做的事情。

1. 每个 Agent 独立身份，绝不共享凭证

用 AWS IAM Role、GCP Service Account 或 Azure Managed Identity 给每个 Agent 单独创建身份。权限范围严格按照任务需要裁剪：

# 创建只读 S3 权限的 Agent 专用角色
aws iam create-role --role-name agent-report-reader \
  --assume-role-policy-document file://trust-policy.json

aws iam attach-role-policy --role-name agent-report-reader \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

2. 短生命周期 Token，拒绝长期凭证

Agent 每次执行任务前动态申请临时 Token，有效期设为任务执行时间的 1.5 倍，任务结束立即吊销。AWS STS AssumeRole 配合 --duration-seconds 900（15 分钟）是个合理的起点。

3. 工具调用白名单 + 参数校验

不要让 Agent 自由调用所有可用工具。在 MCP（Model Context Protocol）或自定义工具层加入显式白名单，并对高风险参数做 schema 校验：

ALLOWED_TOOLS = {"read_file", "search_docs", "send_email"}

def call_tool(tool_name: str, params: dict):
    if tool_name not in ALLOWED_TOOLS:
        raise PermissionError(f"Tool {tool_name} not permitted for this agent")
    validate_params(tool_name, params)  # JSON Schema 校验
    return execute(tool_name, params)

4. 全链路审计日志，工具调用必须可溯源

每一次工具调用记录：调用时间、Agent ID、调用者 prompt 摘要（脱敏）、参数、返回值 hash。没有日志，安全事故发生后的溯源就是盲人摸象。

控制措施	覆盖的风险	实施复杂度
独立 scoped identity	横向移动、权限扩散	低
短生命周期 Token	凭证泄露后的持续利用	中
工具白名单	Prompt injection 导致的未授权操作	中
全链路审计日志	事后溯源、合规审计	低
输入/输出内容过滤	Prompt injection、数据外泄	高

5. 隔离执行环境

生产数据相关的 Agent 跑在独立的网络段，出站流量做白名单。Agent 容器不挂载宿主机敏感目录，禁止访问 instance metadata endpoint（169.254.169.254），防止通过 SSRF 偷取云厂商凭证。

---

安全策略滞后的结构性原因

为什么安全控制跟不上 Agent 的扩张速度？调研数据揭示了一个现实困境：企业的 AI 部署往往由业务线或研发团队主导，安全团队在很多情况下是事后才知道某个 Agent 上线的。加上当前 Agent 框架（LangChain、AutoGen、CrewAI 等）的默认配置几乎不包含权限隔离机制，开发者图省事直接用现成配置推进，安全债就这样一笔笔累积下去。

Anthropic 最近完成了 15 亿美元的版权和解，Google 也在持续迭代 Gemini 3 系列模型能力——模型层的演进速度有目共睹。但模型越强、Agent 的自主决策能力越强，权限管理失控的后果就越严重。一个能自主写代码、调 API、发邮件的 Agent，如果拿着管理员凭证在生产环境里跑，任何一步判断失误都可能是灾难性的。

从 54% 这个数字来看，大多数企业的 AI Agent 安全还处在"出了事才知道有问题"的阶段。在 Agent 数量指数级增长的当下，这个窗口期不会太长。

---

我在写这篇文章的过程中一直在想一个问题：开发者用什么平台调用这些模型，其实也直接影响安全基线。如果你在用 Claude Code、Codex 或 Gemini CLI 做 Agent 开发，XycAi 词元平台（https://www.xyc.ai）是个值得看一眼的选项——200+ 全球模型 OpenAI 兼容 API 统一接入，持大模型算法备案号、可开全球发票，对需要合规落地的企业来说省去不少麻烦。三大 CLI 工具都支持一键接入，Claude Opus 4.8 等官方模型价格低至官方价 1.4 折起，日常研发成本控制得住。