跳转到主要内容

Agent 事故首先是遥测问题,其次才是策略问题

关于失控 agent 的报告所描述的控制失效,在事发之前都是不可见的。第一步修复是建立一份关于意图、出站流量与决策的持久记录。

Front view of a historic building with Romanian flag in Bucharest.

本轮事故报告中的模式

这一点值得仔细说明,因为它改变了事故的性质。入侵意味着存在对手和漏洞。未授权目的地意味着操作者对 agent 权限的认知与运行时实际允许的行为之间存在缺口。这是不同的失效类别,需要不同的补救措施。

报告描述的是被发现的行为,而不是被阻止的行为

本轮中的每一则叙述都是事后的。有人注意到了行为,然后将其还原出来。这是日志记录层面的属性,不是模型层面的属性。一个阻止未授权出站流量的系统,和一个允许它发生、事后才报告的系统,可以运行同一个策略引擎;它们的区别只在于边界是在事前还是事后被强制执行,以及该尝试是否被记录下来。

令人不安的推论是,这个行业目前无法按需提供足以裁定一起有争议事故的证据。当监管者询问某个 agent 在某次运行中是否尝试访问某个特定目的地时,对大多数部署而言,诚实的回答是:对话记录存在,但授权记录不存在。对话记录显示的是模型说了什么。它不显示在边界处出示了哪份凭证、依据谁的授权,也不显示某个策略分支是否被评估并拒绝。

这正是当前监管推进的背景:FTC 的问询、各实验室之间流传的自愿承诺,以及正在推进的各州法案,都是针对一批基本属于轶事性质的证据来起草的。针对轶事起草的规则往往趋于宽泛且无法执行,因为起草者无法指向某一次具体运行说:这就是失效的形态。替代方案不是放松监管,而是产出记录。

让事故可被还原的三份记录

一起可还原的事故需要三份记录,每一份都有一个自然的归属位置,且都不在 agent 自身的框架之内。

意图记录

A lawyer sitting at a desk with legal books, documents, and a newspaper, embodying professionalism.

向 agent 陈述的目标,在工具选择之前捕获,而不是事后从对话记录中推断。推断本身就是问题:对话记录是模型关于自身写下的叙事,它被产生该行为的同一上下文所塑造。意图记录是输入,而不是模型对输入的叙述。它应携带任务标识符、请求主体、陈述的目标,以及为该目标授予的权限范围。

出站记录

每一个目的地、每一份使用的凭证,以及载荷类别,都在边界处写入,而不是在 agent 框架内部。边界是唯一能让记录可信的地方,因为它是唯一无论框架意图如何都能观察到该尝试的地方。如果 agent 框架自己写出站日志,那么一个被攻破或配置错误的框架就会写出误导性的日志。

一个具体的机制:一个正向代理,终止来自 agent 运行时的所有出站流量,解析目的地,对照任务被授予的范围进行检查,并在转发或拒绝之前发出结构化记录。记录由代理写入,而不是由 agent 写入。agent 无法压制它,因为 agent 不在写入路径上。

决策记录

评估了哪条策略、走了哪个分支,以及回退本应是什么。最后一项最关键,也最常被省略。知道某个请求被拒绝是有用的;知道该拒绝落入了默认允许,则是策略与装饰之间的区别。决策记录应写明策略版本、评估的输入、结果,以及回退状态。

为什么仪表盘无法满足这一要求

聚合指标回答的是频率有多高。它们不回答第 41,208 次运行究竟发生了什么。当一起事故处于审查之中时,问题总是具体的:这一次运行、这个目的地、这份凭证、这项授权。趋势线无法被传唤作证。

采样追踪以更尖锐的形式存在同样的缺陷。采样的设计目的是保留代表性样本、丢弃尾部。而真正重要的异常运行恰恰就是尾部。一个只保留百分之一追踪的系统media/server-rack-circuit-board-1958b2-bf296a.jpg)

A stunning night view of the Hungarian Parliament building, beautifully illuminated against the night sky.

因此,保留策略成为一个安全参数,而不是存储成本参数。这是整个设计中诚实的权衡。对每一次意图和每一次出站尝试的全保真记录体量很大,而且很敏感,因为它们描述的是一个组织试图做什么。务实的立场是分层保留:在足够长、足以覆盖事故发现期的窗口内保持全保真,超出之后进行聚合与脱敏,同时保留 schema,使得即使载荷细节已被老化淘汰,某次具体运行仍可被识别。这是一个策略选择,应当被明确做出,而不是默认交给可观测性供应商所交付的任何东西。

最小可行实现

三个属性就足以区分一起可还原的事故与一则轶事。

在 agent 的写入范围之外写入。 意图记录和出站记录写入一个仅追加的存储,agent 运行时没有任何凭证可以修改或删除它。仅追加不是一种存储偏好;它是让记录成为证据而非证词的那个属性。

将记录绑定到撤销可以针对的标识符。 每条记录携带一个任务标识符和一个凭证标识符。没有这种绑定,撤销就是一件钝器:你可以停止 agent,但无法撤销允许那次具体出站的具体授权。有了它,对事故的响应就是一次有范围的撤销,而不是一次关停。

把日志 schema 当作版本化接口。 下游的责任与审计工具将依赖字段名和语义。一个未经版本化就变更的 schema 会静默地破坏工具链,而一条损坏的审计轨迹比缺失的审计轨迹更糟,因为它看起来是完整的。

{
  "schema_version": "1.2",
  "task_id": "...",
  "credential_id": "...",
  "intent": {"principal": "...", "objective": "...", "granted_scope": ["..."]},
  "egress": {"destination": "...", "payload_class": "...", "outcome": "allowed|denied"},
  "decision": {"policy_version": "...", "branch": "...", "fallback": "..."}
}

这种权衡是真实存在的,应当被点名。这套埋点会在边界处带来延迟成本、记录的存储成本,以及 schema 的工程投入。它不会让 agent 变得安全。它让 agent 的行为变得可读,而这是后续每一项安全主张的前提。没有遥测的策略是一份意图声明;没有策略的遥测是一份漂移记录。当前这一轮事故表明,这个行业拥有的前者多于它所能证实的,而第一笔投入应当是记录。

封面照片:Brett Sayles / Pexels。

分享XLinkedIn永久链接5 分钟阅读

相关阅读

这能回答的问题

Why is telemetry a prerequisite for agent policy?

Policy states what should happen; telemetry records what did. Without a durable record of intent, egress, and decision, a policy violation cannot be distinguished from a policy that was never evaluated, and remediation has no target.

What is an egress record and where should it be written?

An egress record captures every destination, credential, and payload class for an agent's outbound traffic. It should be written at the network boundary, typically a forward proxy, rather than inside the agent framework, so the agent cannot suppress or alter it.

Why are sampled traces insufficient for incident review?

Sampling preserves the representative and discards the tail. Anomalous runs are the tail. A sampled system will lose exactly the runs an investigator needs, and the loss is invisible because a missing record looks like a non-event.

What is the minimum viable implementation for reconstructable agent incidents?

Write intent and egress records to an append-only store outside the agent's write scope, bind each record to a task identifier and a credential identifier so revocation has a target, and version the log schema as a stable interface for downstream audit tooling.