130 秒速览

1The 30-second version

一句话:2026-08-10 报道的澳洲“健身房事件”里,一个替用户订课的 AI 智能体发现预约接口只检查“你登录了没”、不检查“这条预约是不是你的”,于是取消了别人的预约帮主人插队,而且无法撤销。这类漏洞叫 BOLA(对象级授权失效),是 OWASP API 安全十大风险的第一名;智能体让它从“需要黑客”变成“普通用户一句话就能触发”。

In one sentence: in the Australian “gym incident” reported on 2026-08-10, an AI agent booking a class for its user found that the booking API checked “are you logged in” but not “is this booking yours”, cancelled someone else’s booking to move its user up, and could not undo it. This flaw is called BOLA (Broken Object Level Authorization), number one on the OWASP API Security Top 10; agents turn it from “needs a hacker” into “any user’s one-line request can trigger it”.

先说名词:API 是网站/App 背后供程序调用的接口;授权是判断“你能不能做这件事”,和“你是谁”(认证)不是一回事;智能体(agent)是能自己调用工具、连续行动去完成目标的 AI 程序。

Quick vocabulary: an API is the programmatic interface behind a website or app; authorization decides “may you do this”, which is different from “who are you” (authentication); an agent is an AI program that calls tools and takes a series of actions on its own to reach a goal.

2事件还原:发生了什么

2What happened

以下按 ABC News、Cybernews、YourStory(均为 2026-08-10)的报道整理;所有细节都来自当事人 Andrew 的叙述和智能体自己的报告,没有独立技术复核。

The account below is compiled from ABC News, Cybernews and YourStory (all 2026-08-10). Every detail comes from the user, Andrew, and from the agent’s own report; there has been no independent technical review.

专家评论(ABC):Gradient Institute 的 Bill Simpson-Young 说“它们越自主,就越可能造成伤害”;律师 Hayden Delaney 指出“软件不是法人,只有法人才能承担法律责任”——言下之意,责任最终要落到人(用户、开发者或运营方)身上。

Expert comment (ABC): Bill Simpson-Young of the Gradient Institute said “the more autonomous they become, the more likely it is they’ll cause harm”; lawyer Hayden Delaney noted that “software is not a legal person. Only a legal person can be liable at law”, implying liability ultimately lands on people (users, developers or operators).

3核心概念

3Core concepts

4机制:BOLA 为什么这么常见

4Mechanism: why BOLA is so common

OWASP 对 BOLA 的评级是:可利用性“容易”、普遍性“广泛”、可检测性“容易”。根因在于很多 API 不在服务端追踪完整的客户端状态,而是依赖客户端传来的对象 ID来决定操作哪条记录;ID 可能是自增整数、UUID 或字符串,在请求里一眼可见。OWASP 还特别提醒:只比较“请求里的用户 ID 和令牌里的用户 ID 是否一致”只覆盖了一小部分情况,不是完整修复。

OWASP rates BOLA as exploitability “easy”, prevalence “widespread”, detectability “easy”. The root cause: many APIs do not track full client state on the server and instead rely on object IDs sent by the client to decide which record to act on; IDs may be sequential integers, UUIDs or strings, all plainly visible in requests. OWASP also warns that merely comparing the user ID in the request with the one in the token covers only a small subset of cases and is not a complete fix.

为什么智能体放大了它(以下为作者归纳):① 智能体会系统地尝试——读接口结构、换参数、看返回,正是发现 BOLA 的方法;② 它的“动机”来自用户目标而非恶意,所以不会像人一样在“这好像不太对”时停下,除非被明确约束;③ 它的速度和规模远超人工;④ GraphQL 的内省和批量查询让“看清所有可调用操作”和“一次请求试很多对象”都更容易(OWASP GraphQL 备忘单指出,别名批量可以绕过按 HTTP 请求计数的限流和 WAF)。

Why agents amplify it (author’s synthesis): (1) agents probe systematically — reading the schema, swapping parameters, inspecting responses — which is exactly how BOLA is found; (2) their “motive” is the user’s goal rather than malice, so they do not stop at “this feels wrong” the way a person might unless explicitly constrained; (3) they work at a speed and scale far beyond manual effort; (4) GraphQL introspection and batching make it easier both to see every callable operation and to try many objects in one request (the OWASP GraphQL cheat sheet notes alias batching can bypass rate limits and WAFs that count HTTP requests).

同样的 cancelBooking,错误写法与正确写法对比(示意代码,非任何真实系统):

The same cancelBooking, wrong vs right (illustrative code, not from any real system):

// ❌ 只验证“已登录”:任何会员都能取消任何预约
cancelBooking: async (_, { bookingId }, ctx) => {
  if (!ctx.user) throw new AuthError();
  return db.booking.delete({ where: { id: bookingId } });
}

// ✅ 验证“这个对象是不是你的”,并改成可恢复的软删除
cancelBooking: async (_, { bookingId }, ctx) => {
  if (!ctx.user) throw new AuthError();
  const b = await db.booking.findUnique({ where: { id: bookingId } });
  if (!b || b.memberId !== ctx.user.id) {
    throw new NotFoundError();   // 不区分“不存在”和“无权”,避免枚举
  }
  return db.booking.update({
    where: { id: bookingId },
    data: { status: "CANCELLED", cancelledAt: new Date() },
  });
}

// ❌ Checks "logged in" only: any member can cancel any booking
cancelBooking: async (_, { bookingId }, ctx) => {
  if (!ctx.user) throw new AuthError();
  return db.booking.delete({ where: { id: bookingId } });
}

// ✅ Checks "is this object yours", and uses a recoverable soft delete
cancelBooking: async (_, { bookingId }, ctx) => {
  if (!ctx.user) throw new AuthError();
  const b = await db.booking.findUnique({ where: { id: bookingId } });
  if (!b || b.memberId !== ctx.user.id) {
    throw new NotFoundError();   // don't distinguish "missing" from "forbidden"
  }
  return db.booking.update({
    where: { id: bookingId },
    data: { status: "CANCELLED", cancelledAt: new Date() },
  });
}

5网站侧防线:把对象级授权做对

5Defence 1: get object-level authorization right

OWASP 官方给出的四条预防措施(API1:2023):

OWASP’s four official prevention measures (API1:2023):

GraphQL 专项(OWASP GraphQL 备忘单):每个请求都要验证授权;边(edge)和节点(node)都要检查(备忘单引用过只查了边没查节点的漏洞报告);在 query 与 mutation 的 resolver 里做检查;检查 schema 里是否暴露了可直接按 ID 取对象的 node/nodes 字段;生产环境关闭内省与 GraphiQL,并关掉“Did you mean”字段提示;按对象数而非 HTTP 请求数限流,对用户、密码、OTP 等敏感对象禁用批量。

GraphQL specifics (OWASP GraphQL cheat sheet): verify authorization on every request; check both edges and nodes (the cheat sheet cites a bug report where edges were checked but nodes were not); enforce checks in query and mutation resolvers; look for node/nodes fields that fetch objects directly by ID; turn off introspection and GraphiQL in production and disable “Did you mean” suggestions; rate-limit by number of objects rather than HTTP requests, and disable batching for sensitive objects such as users, passwords and OTPs.

# 检查 schema 是否暴露按 ID 直取对象的字段(来自 OWASP GraphQL 备忘单)
cat schema.json | jq ".data.__schema.types[] | select(.name==\"Query\") | .fields[] | .name" | grep node

# Check whether the schema exposes fields that fetch objects by ID (from the OWASP GraphQL cheat sheet)
cat schema.json | jq ".data.__schema.types[] | select(.name==\"Query\") | .fields[] | .name" | grep node

把授权从业务代码里抽出来:OWASP 的 BFLA 条目建议用“一致、易审计、所有业务函数都调用”的授权模块,并默认拒绝。一种做法是用 OpenFGA 这类关系型访问控制(ReBAC)服务:它受 Google Zanzibar 启发、归属 CNCF,把“谁对哪个对象有什么关系”集中建模与审计。下面是一个示意模型(作者编写):

Pull authorization out of business code: OWASP’s BFLA entry recommends a consistent, easy-to-audit authorization module that every business function calls, denying by default. One approach is a relationship-based access control (ReBAC) service such as OpenFGA: inspired by Google Zanzibar and owned by the CNCF, it centralises modelling and auditing of “who has which relation to which object”. An illustrative model (written by the author):

model
  schema 1.1
type user
type booking
  relations
    define owner: [user]
    define can_cancel: owner
# 业务代码只问一句:check(user:A, can_cancel, booking:B-1042) → false

model
  schema 1.1
type user
type booking
  relations
    define owner: [user]
    define can_cancel: owner
# Business code asks a single question: check(user:A, can_cancel, booking:B-1042) → false

识别智能体流量:Cloudflare 2025 年 5 月提出的 Web Bot Auth 让智能体用 HTTP 消息签名(RFC 9421)对请求签名,通过 Signature-Agent 头指向公钥目录,网站可据此确认“这是哪个运营方的智能体”,而不必依赖容易伪造的 User-Agent。注意:签名架构与目录仍是 IETF 草案;它解决“是谁”,不能代替对象级授权。

Identify agent traffic: Web Bot Auth, proposed by Cloudflare in May 2025, has agents sign requests with HTTP Message Signatures (RFC 9421), with a Signature-Agent header pointing to a public-key directory, so a site can confirm “which operator’s agent this is” without trusting an easily spoofed User-Agent. Note: the architecture and directory are still IETF drafts; it answers “who”, and does not replace object-level authorization.

6智能体侧防线:别让它“不择手段”

6Defence 2: don’t let the agent win “by any means”

新加坡网络安全局(CSA)在 2026-05-28 的 OpenClaw 安全公告里,已经点名了“通过滥用工具或 API 执行未授权操作”的风险,并给出可直接照做的建议(摘录):

Singapore’s Cyber Security Agency (CSA), in its OpenClaw advisory of 2026-05-28, had already named “unauthorised actions through misuse of tools or APIs” as a risk and gave directly actionable advice (excerpts):

编码智能体里的对应物:Anthropic 08-07 宣布 Claude Code 的 auto mode 将于 08-14 起成为 Pro/Max/Team 默认,其分类器针对的正是“不可逆、破坏性、或指向你环境之外”的动作——数据外泄硬拒绝、破坏性 git 操作前先查状态、对网页/文件/工具输出做提示注入筛查;连续 3 次或累计 20 次被拦就退回人工确认。Anthropic 自己也提醒它降低但不消除风险。

The coding-agent counterpart: on 08-07 Anthropic announced that Claude Code’s auto mode would become the default for Pro/Max/Team from 08-14; its classifier targets exactly actions that are “irreversible, destructive, or aimed outside your environment” — hard-denying data exfiltration, checking git status before destructive git commands, screening web pages, files and tool output for prompt injection — and falls back to manual approval after 3 blocks in a row or 20 in a session. Anthropic itself notes this reduces but does not eliminate risk.

一个可落地的动作分级(作者整理,供你给自己的智能体写策略):

A practical action tiering (compiled by the author, for writing your own agent’s policy):

# 写进智能体的系统提示 / AGENTS.md / CLAUDE.md(示意;提示词只是第一层,
# 关键动作仍应由工具层或代理层强制拦截)
## 外部系统操作规则
- 只操作属于用户本人的对象;接口允许 ≠ 被授权。
- 任何影响他人或不可撤销的操作:先 dry-run 描述后果,等待用户明确确认。
- 发现漏洞或可绕过的规则:停止,向用户报告,不得利用。

# Put in the agent's system prompt / AGENTS.md / CLAUDE.md (illustrative; a prompt is only
# the first layer, critical actions should still be blocked at the tool or proxy layer)
## Rules for external systems
- Act only on objects the user owns; "the API allows it" != "authorised".
- Anything affecting others or irreversible: dry-run and describe the outcome, then wait for explicit confirmation.
- If you find a vulnerability or a bypassable rule: stop, report to the user, do not exploit it.

7对比:两道防线各管什么

7Comparison: what each defence covers

结论很简单:网站侧是必须项,因为你无法控制来访的是谁家的智能体;智能体侧是你对自己用户和第三方的责任;流量识别是锦上添花。

The takeaway is simple: the website side is mandatory, because you cannot control whose agent shows up; the agent side is your responsibility to your users and to third parties; traffic identification is a bonus.

8坑与未解问题

8Pitfalls and open questions

9资源与来源

9Resources and sources