OWASP 2026 LLM 十大风险与全新 Agent Control Standard：Agent 开发者必须改什么

OWASP GenAI 安全项目在 2026 年 8 月 3 日发布了 2026 版 LLM 应用十大风险，随后于 9 月 1-2 日正式揭晓，一同推出的还有全新的 Agent Control Standard，项目社区成员也已突破三万人。该清单在头 48 小时内下载量就突破一万。最受关注的变化只有一个名次移动：Excessive Agency（过度自主权）从第六位升至第三位。这正是最贴近 Agent 的风险，也是最多团队至今仍靠「把提示词写得更有说服力」来应对的风险。本文讲清如何把这份清单落成真正能强制执行的控制项。

从意识到控制

一、把十大风险当成一份控制契约来读

浪费 OWASP 清单最快的方式，是把它当科普读物。正确的是把它当契约来读。代码示例 1 把 2026 版风险变成一份机器可读的映射，每一条都绑定一个具体控制项与严重级别，并把 Excessive Agency 标为 critical。把这份文件提交到代码旁边，一份静态文档就变成了流水线可以推理、可以 diff、可以强制执行的东西。2026 版还扩展了对 NIST、MITRE ATLAS 与 CWE 的映射，因此一份策略可同时满足多个框架。

# controls/llm-top10.yaml — map every OWASP risk to a concrete control
version: "2026"
owner: platform-security
risks:
  LLM01_prompt_injection:      { control: input_sanitizer + output_encoder, severity: high }
  LLM02_sensitive_info:        { control: pii_redactor + response_filter, severity: high }
  LLM03_supply_chain:          { control: model_allowlist + sbom, severity: medium }
  LLM04_data_poisoning:        { control: dataset_lineage, severity: medium }
  LLM05_improper_output:       { control: sandboxed_renderer, severity: high }
  LLM06_excessive_agency:      { control: least_privilege + approval_gate, severity: critical }
  LLM07_system_prompt_leak:    { control: no_secrets_in_prompt, severity: high }
  LLM08_vector_weaknesses:     { control: tenant_scoped_retrieval, severity: high }
  LLM09_misinformation:        { control: citation_required, severity: medium }
  LLM10_unbounded_consumption: { control: rate_limit + token_budget, severity: high }
# Excessive Agency rose from 6th to 3rd place in the 2026 edition.
# Treat it as critical: it is the risk most specific to agents.

二、护栏必须双向生效

提示词注入（LLM01）排在第一位是有原因的：它几乎是通往其他所有失败的可达路径。团队常犯的错误是只守输入。代码示例 2 让同一中间件同时作用于入站提示与出站的模型/工具输出，既盯注入模式，也盯泄露的密钥。提示词注入以数据形式进入，密钥以数据形式离开。把两个方向都过滤掉，你就能用最低成本补上最常见的那个洞。

// guardrails.ts — one middleware for prompt injection and unsafe output
export function guardrails(text: string, direction: "in" | "out") {
  const rules =
    direction === "in"
      ? [/ignore (all )?previous instructions/i, /you are now\b/i, /system prompt/i]
      : [/sk-[A-Za-z0-9]{16,}/, /AKIA[0-9A-Z]{16}/, /-----BEGIN [A-Z ]*PRIVATE KEY-----/];
  for (const r of rules) {
    if (r.test(text)) {
      throw new Error(`Guardrail tripped (${direction}): ${r}`);
    }
  }
  return text;
}
// LLM01 is input-shaped; LLM02 is output-shaped.
// Run both directions on every request and every tool result.

三、过度自主权本质是个白名单问题

Excessive Agency 升到第三位，是因为 2026 年 Agent 长出了手。一个说错话的聊天机器人只是尴尬；一个拥有通配符权限、还能发起退款的 Agent 则代价高昂。代码示例 3 是与提示词无关的那个解法：显式的工具白名单、按工具限定的作用域、默认拒绝，以及超过阈值必须人工审批的升级规则。没列出的工具，Agent 根本调用不了。这是任何聪明提示词都给不了的保证。

# tools.yaml — an explicit allowlist beats a model's good intentions
agent: support-triage
tools:
  - name: crm.read_customer
    scopes: ["customer:read"]
    max_rows: 1
  - name: kb.search
    scopes: ["kb:read"]
  - name: ticket.create
    scopes: ["ticket:write"]
    requires_human_approval: true
deny_by_default: true
escalation:
  - action: refund.create
    rule: "amount > 50 must be approved by a human"
# Least privilege is the concrete implementation of LLM06 Excessive Agency.
# If a tool is not listed, the agent simply cannot call it.

四、Agent Control Standard 让 Agent 可审计

全新的 Agent Control Standard 最好理解为一个坐在 Agent 与它所触及的一切之间的治理层。代码示例 4 勾勒了它的形状：拦截工具调用、数据外发与模型调用；返回允许、拒绝或转人工的决策；为每个 Agent 绑定工作负载身份；并保留不可篡改的审计记录。这个标准的意义不是为限制而限制，而是：你无法治理你看不见、也停不下来的东西，而 2026 年的大多数事故，都是在 Agent 早已行动之后才被发现的。

// acs-gateway.json — where the Agent Control Standard intercepts
{
  "intercept": ["tool_call", "data_egress", "model_call"],
  "decisions": {
    "allow":   { "log": "full" },
    "deny":    { "log": "full", "alert": "#ai-security" },
    "review":  { "route": "human-in-the-loop", "timeout_s": 300 }
  },
  "identity": "per-agent-workload-id",
  "audit": { "retention_days": 400, "immutable": true }
}
// The Agent Control Standard is about making agents observable and
// interruptible: you cannot govern what you cannot see or stop.

五、在 CI 里执行策略，而不是在 PDF 里

只活在 wiki 里的安全指南会腐烂。代码示例 5 展示了让清单真正生效的 CI 执行方式：任何 Agent 一旦声明了未限定或通配符的工具，就让构建失败；并在策略文件合并前，用控制项映射校验每一个文件。这正是云团队多年前采用的 governance-as-code 模式，如今用到了 Agent 上。当 OWASP 清单更新时，你的门禁也跟着更新，因为门禁读的就是清单所映射的那份文件。

# .github/workflows/agent-policy.yml — fail the build on unscoped agents
name: agent-policy
on: [pull_request]
jobs:
  policy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - name: Every agent must declare scoped tools
        run: |
          npx owasp-agent-lint tools.yaml controls/llm-top10.yaml --fail-on critical
      - name: Block wildcard scopes
        run: '! grep -rE "scopes:\s*\[\s*\"\*\"" . --include=*.yaml'
# Mirrors the list to NIST, MITRE ATLAS and CWE so one policy
# satisfies several frameworks at once.

六、本周可以先做的三件事

如果只做三件事，就做这三件。第一，把每个 Agent 风险映射到具名控制项，并把 Excessive Agency 标为 critical。第二，在每一次模型与工具调用前都放上双向护栏。第三，把显式的、默认拒绝的工具白名单纳入版本管理，并在 CI 里对通配符直接失败。这覆盖了 OWASP 重点标出的名次变化、最常见的攻击路径，以及新 Agent Control Standard 想要描述的治理层。2026 版清单并不比去年更长，只是对「自主性会带来哪些失败」说得具体得多。