2026-10-31 02:00:05 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

如果 Agent 犯错是大概率事件，企业安全应该如何设计？

原创

jishuzhain
jishuzhain

OnionSec

2026年10月30日 23:22
广东

去阅读

——从数学建模、统计学与决策理论，重新理解企业安全的非最优解

最近看到腾讯发布的《WorkBuddy 企业版安全白皮书》，又让我产生了一些联想。

Agent 正在从一个能够回答问题的工具，逐渐变成可以调用工具、访问数据、执行任务，甚至代表用户完成业务操作的系统。

这意味着，安全问题也发生了变化。

过去，我们更多关注系统有没有漏洞、用户有没有权限、终端有没有恶意程序。

现在还需要考虑：如果 Agent 理解错了指令、调用错了工具、执行了不该执行的操作，或者被外部输入诱导，它会造成什么后果？

例如：

Agent 因为 Prompt Injection 执行了攻击者设计的指令；

Agent 调用了权限过大的工具，访问了不应该访问的数据；

某个 Skill 存在恶意代码或供应链风险；

Agent 在没有充分确认的情况下，执行了删除、转账、修改配置等操作；

多个 Agent 或自动化流程之间相互调用，最终形成意料之外的执行链。

这里有一个值得认真思考的问题：

如果 Agent 犯错并不是一个可以彻底消除的小概率事件，企业安全应该把钱花在哪里？

我尝试把这个问题拆开，用一点数学建模、统计学和决策理论来推演。

不是为了证明数学可以解决所有安全问题，而是想看看，当资源、人的注意力和技术能力都有上限时，我们究竟应该如何做选择。

一、单次错误概率很低，为什么长期运行仍然危险？

先解释一下标题里的“大概率事件”。

这里并不是说 Agent 每次执行任务都很容易犯错。

恰恰相反，单次动作的错误概率可能非常低。

假设一个 Agent 执行某项操作时，发生错误的概率只有 0.1%。

看起来并不高。

但如果它每天执行 1000 次操作，并且暂时假设每次操作的错误概率相互独立，那么一天之内至少发生一次错误的概率是：

P(至少一次错误) = 1 − (1 − p)ⁿ

其中：

p：单次操作发生错误的概率；

n：累计执行次数。

代入 p = 0.001、n = 1000：

P = 1 − (1 − 0.001)¹⁰⁰⁰

结果约为 63.2%。

也就是说，单次错误概率只有千分之一，在 1000 次操作的累计窗口里，至少发生一次错误的概率已经超过六成。

当然，这个计算依赖独立性假设。现实中的错误可能具有相关性，例如同一条错误指令会影响多个任务，实际风险可能更复杂。

但它已经说明一个问题：

单次动作的小概率错误，不代表长期运行的系统仍然拥有很低的累计错误概率。

而且，Agent 的运行规模越大，执行链越长，接触的数据和工具越多，错误被放大的机会也可能越多。

因此，企业安全不能只问：

“这个 Agent 单次执行有多准确？”

还应该问：

“当它持续运行数万次、数百万次时，错误会以什么方式累积？一次错误最多能够影响多少资产？”

我们可以先用一个简化风险模型来描述：

R = P(E) × P(H|E) × L

其中：

P(E)：风险事件发生的概率；

P(H|E)：事件发生后造成实际损害的概率；

L：一旦造成损害，可能产生的损失。

这个公式不是完整的企业风险计量标准，而是帮助我们拆解问题的一个框架。

它提醒我们，安全措施不一定非要让事件永远不发生。

降低事件发生概率、阻断损害形成、限制影响范围，甚至缩短恢复时间，都可能降低最终风险。

这也引出了一个更值得研究的问题：

当企业预算有限时，应该优先降低哪一种风险？

二、假设企业只有 100 万元安全预算，应该怎么分？

我们构造一个简化场景。

某企业准备部署大量 Agent，管理层给安全团队 100 万元专项预算。

目前识别出五类主要风险：


风险类别	初始年度预期损失	防御效率参数 k
越权操作	80 万元	0.45
Prompt Injection	100 万元	0.35
数据泄露	200 万元	0.25
Skill 供应链	70 万元	0.40
错误操作	50 万元	0.50
合计	500 万元	—

这里的数值全部是为了演示而构造的模拟数据，不代表任何真实企业的风险统计。

其中，k 是一个防御效率参数。

它不是某种真实产品的检测率，也不是漏洞修复成功率，而是用于模拟预算投入效果的参数。

k 越大，意味着在相同的预算投入下，初期风险降低得越快。

我们暂时作出三个简化假设：

五类风险的损失归因互不重叠，避免重复计算同一笔损失。

每类风险的预算只影响对应类别的风险。

随着投入增加，风险降低的效果逐渐递减。

第三个假设尤其重要。

现实中的安全建设往往存在边际收益递减。

例如，企业最初投入资金建设权限隔离，可能很快就能消除一批明显的越权风险。

但当基础权限体系已经完善，再增加预算，可能只能处理一些复杂、低频的边界场景。

所以，我们用一个指数函数模拟防御投入的效果：

Eᵢ(xᵢ) = 1 − exp(−kᵢxᵢ/10)

其中：

xᵢ：分配给第 i 类风险的预算，单位为万元；

kᵢ：防御效率参数；

Eᵢ：投入预算后，风险降低的比例。

那么，剩余风险可以表示为：

Rᵢ(xᵢ) = Lᵢ × exp(−kᵢxᵢ/10)

Lᵢ 是该类别的初始年度预期损失。

我们希望找到一组预算分配方案，让五类风险的剩余损失总和尽可能低：

优化目标：

Minimize ΣRᵢ(xᵢ)

同时满足：

Σxᵢ ≤ 100

xᵢ ≥ 0

翻译成人话就是：

在总预算不超过 100 万元的前提下，寻找一组投入方案，让企业剩余的年度预期损失尽可能小。

这里还有一个需要补充的现实约束：

企业整体决策并不只有风险最小化。

如果把业务价值、风险和安全成本放在一起，可以写成：

Maximize U = V − λR − C

其中：

V：Agent 带来的业务价值；

R：企业承担的风险；

λ：企业对风险的厌恶程度；

C：安全建设和运营成本。

本文接下来的计算，暂时固定业务价值和总预算，只研究如何降低 R。

这意味着，我们并没有解决企业全部的投资决策问题，只是在其中选取了一个可以计算的局部问题。

三、数学告诉我们：预算不应该简单平均分配

如果把预算平均分成五份，每类风险投入 20 万元，看起来很公平。

但公平不一定意味着有效。

因为不同风险类别的初始损失不同，防御效率也不同。

同样投入 1 万元，可能在某个领域能够显著降低风险，在另一个领域却只能产生很小的改善。

因此，我们需要关注一个概念：

边际收益。

在这个模型里，每增加一万元预算，能够降低多少预期损失？

对应的边际收益为：

Mᵢ = (Lᵢ × kᵢ / 10) × exp(−kᵢxᵢ/10)

在最优点，如果所有类别均获得正投入，KKT 条件要求：

M₁ = M₂ = M₃ = M₄ = M₅ = μ

这里的 μ 可以理解为最优方案下，最后一万元预算所带来的共同边际收益。

为什么要让它们相等？

假设数据泄露防御每增加一万元，能够降低 5 万元预期损失；而错误操作防御每增加一万元，只能降低 1 万元预期损失。

那么，我们就应该考虑把一部分预算从错误操作防御转移到数据泄露防御。

只要这种转移能够带来更大的风险降低，就说明原来的预算分配还不是最优的。

反过来，当所有仍有投入的类别，其最后一单位预算带来的边际收益相等时，就无法通过简单的预算转移进一步改善目标函数。

如果某个风险类别的初始边际收益本来就很低，最优方案也可能不给它分配预算。这时还需要满足相应的 KKT 边界条件，而不是机械地要求所有类别边际收益相等。

先看一眼：为什么数据泄露获得最多预算？

五类风险在完全没有投入时的初始边际收益分别为：


风险类别	初始边际收益
越权操作	3.60
Prompt Injection	3.50
数据泄露	5.00
Skill 供应链	2.80
错误操作	2.50

这里的单位是：每增加 1 万元预算，初期预计可以降低多少万元的年度预期损失。

数据泄露的初始边际收益最高，因此在预算优化中获得了更多投入。

这不是因为数据泄露在所有企业里都一定最重要，而是因为在当前参数下，它的初始损失规模和防御效率组合起来，产生了最高的初始边际收益。

计算结果：最优分配究竟是什么样？

使用上述参数进行数值求解：


风险类别	最优预算	风险降低比例
越权操作	16.57 万元	52.6%
Prompt Injection	20.50 万元	51.2%
数据泄露	42.96 万元	65.8%
Skill 供应链	12.36 万元	39.0%
错误操作	7.62 万元	31.7%
合计	100 万元	—

这里的风险降低比例，就是前面函数 Eᵢ(xᵢ) 的计算结果。

可以看到，100 万元预算并没有平均分配。

数据泄露获得了最多的投入，错误操作获得的预算最少。

但这并不意味着错误操作不重要，而是说，在当前模型的参数下，继续向其他类别投入预算，能够带来更高的边际风险降低收益。

但这里有一个更重要的问题：优化到底比经验分配好多少？

如果只拿平均分配作为对照，容易得出一个过于乐观的结论。

因为平均分配本身就不一定是一个合理的预算方案。

所以，我们再引入一个更自然的基线：

按照初始损失规模比例分配预算。

例如，数据泄露占总初始损失的 40%，那么就给它分配 40 万元。

三种方案的比较如下：


预算方案	剩余年度预期损失	风险降低金额
平均分配	253.34 万元	246.66 万元
按损失比例分配	232.49 万元	267.51 万元
边际收益优化	231.95 万元	268.05 万元

这个结果其实比之前更有意思。

如果只与平均分配相比，优化方案多降低了 21.39 万元。

但如果与按损失比例分配相比，优化方案只多降低了约 0.54 万元。

也就是说，在当前这组参数下，边际收益优化相对于一个合理的经验方案，优势并不明显。

为什么？

因为五类风险的防御效率参数 k 差异还不够大。

当不同类别的投入效率比较接近时，按损失规模比例分配，本身就已经是一个不错的近似方案。

但如果不同类别的防御效率差异进一步扩大，简单按损失比例分配就可能出现明显偏差。

这恰恰是数学优化的价值：

它不是为了证明复杂算法一定比经验判断高明，而是帮助我们判断，什么时候经验方法已经足够好，什么时候值得付出额外成本进行精细优化。

有时候，最有价值的计算结果，恰恰是告诉我们：复杂优化并没有比简单方法好多少。

四、模型里还有两个更有意思的结论：剩余风险与预算的影子价格

继续推导这个模型，会发现两个值得关注的结果。

最优点的剩余风险有一个简洁表达式

在最优点：

Mᵢ = μ

而：

Mᵢ = (Lᵢ × kᵢ / 10) × exp(−kᵢxᵢ/10)

整理一下：

Lᵢ × exp(−kᵢxᵢ/10) = 10μ/kᵢ

左边恰好就是该类别的剩余风险。

因此：

Rᵢ = 10μ/kᵢ

这个结果很有意思。

在最优点，每类风险的剩余损失，与它的防御效率参数 kᵢ 成反比。

如果某类风险的防御效率较低，那么在最优预算分配下，它允许保留的剩余风险反而更高。

例如，本模型中：


风险类别	最优剩余损失
越权操作	37.96 万元
Prompt Injection	48.80 万元
数据泄露	68.32 万元
Skill 供应链	42.70 万元
错误操作	34.16 万元

这里需要特别注意：公式中没有直接出现单类初始损失 Lᵢ，但 μ 本身取决于所有类别的初始损失、效率参数和预算。因此，不能把它理解为剩余风险完全不受初始损失影响。

它真正表达的是：

在给定预算的最优配置下，风险分配会受到防御效率的强烈影响，而不是简单地让所有风险剩余损失相等。

μ 其实是预算的影子价格

前面出现的 μ 还具有另一个经济学意义。

它是预算约束的影子价格（Shadow Price）。

可以理解为：在当前最优点附近，如果企业再增加 1 万元预算，理论上能够额外降低多少万元的预期损失。

本模型计算得到：

μ ≈ 1.708

也就是说，在当前预算附近，增加 1 万元投入，预计还可以降低约 1.71 万元的年度预期损失。

这会引出一个比“100 万元怎么分”更有意思的问题：

企业的 100 万元预算，究竟够不够？

我们可以把预算从 100 万元继续增加，观察影子价格如何变化。

当 μ 降低到 1 时，意味着：

再增加 1 万元预算，理论上只能换来约 1 万元的预期损失降低。

在当前模型中，对应的总投入约为 172.70 万元。

换句话说，在这个纯数学模型下，预算从 100 万元增加到约 172.70 万元之前，边际风险降低收益仍然高于投入成本。

但这里有一个重要的现实限制：

这只是基于预期损失和预算成本的简化比较，没有考虑现金流、预算审批、风险厌恶、尾部损失、业务价值以及安全措施的其他副作用。

因此，μ 不是管理层应该直接照搬的采购指标。

它真正提供的是一种决策语言：

我们不只需要问预算怎么分，还需要问预算增加之后，边际收益是否仍然值得。

五、统计学的问题：我们真的知道风险有多大吗？

前面的数学模型有一个非常重要的前提：

我们知道每类风险的初始损失 Lᵢ，也知道防御效率参数 kᵢ。

但现实中，我们真的知道吗？

未必。

企业可能部署了很多 Agent，却没有足够的历史数据。

可能有大量告警，但真正发生的安全事件很少。

也可能某类风险看起来发生率很低，只是因为企业缺少有效的检测手段。

这里就进入了统计学的问题。

没有观察到风险，不等于风险不存在。

假设企业过去一个月只发现了 2 起 Agent 数据泄露事件。

我们能不能据此认为数据泄露风险很低？

不一定。

因为这 2 起事件可能只是被发现的部分。

如果检测系统存在漏报，或者日志没有记录关键操作，那么实际事件数量可能远高于观测结果。

我们可以用一个非常简化的贝叶斯模型来演示。

假设：

企业每月真实的数据泄露事件数为 λ；

在观察数据之前，我们对 λ 使用一个 Gamma 先验分布；

先验均值为每月 2 起事件；

当前检测系统的事件发现率为 50%；

一个自然月内，系统实际观察到 2 起事件。

观测事件数不等于真实事件数。

在这个简化模型中：

观测事件数 Y ~ Poisson(qλ)

其中 q 是检测率。

如果 q = 0.5，意味着真实事件中只有一半能够被观测到。

假设先验分布为：

λ ~ Gamma(2, 1)

这里 Gamma 分布采用 shape-rate 参数化，先验均值为 2/1 = 2 起/月。

观察到 2 起事件之后，结合检测率进行贝叶斯更新：

λ | Y=2 ~ Gamma(4, 1.5)

更新后的后验均值为：

E(λ|Y=2) = 4/1.5 ≈ 2.67

也就是说，虽然我们只观察到 2 起事件，但考虑到检测率只有 50%，更新后的真实事件数量估计约为每月 2.67 起。

如果错误地把检测率当成 100%，就会低估真实风险。

当然，这只是一个教学用的简化示例。

它假设事件服从泊松分布、检测率已知且恒定、误报可以忽略。现实中还需要考虑事件之间的相关性、检测率估计误差、漏报机制和数据质量。

但它已经说明：

安全数据的价值，不只是记录发生了多少事件，还需要理解这些事件是如何被发现的。

检测能力本身会影响我们看到的数据

检测覆盖率越高，发现的异常可能越多。

于是，某个风险类别的告警数量增加，不一定代表风险真的变严重了，也可能只是检测能力提高了。

反过来，告警数量减少，也不一定代表安全水平提高了。

它可能只是检测规则失效，或者攻击者绕过了检测。

所以，企业不能只看告警数量，还应该关注：

检测覆盖率；

漏报率与误报率；

数据采集完整性；

事件确认率；

处置闭环率；

检测规则的有效期。

否则，我们很容易把观测偏差当成风险变化。

有时候，告警增加反而意味着企业开始看见过去看不见的问题。

六、人的注意力也是一种稀缺资源

讨论到这里，我又想到一个容易被安全技术忽略的问题：

企业不仅有预算约束，还有人的注意力约束。

假设企业每天产生 1 万条 Agent 安全告警。

安全团队有 5 个人，每个人每天能够认真分析 100 条。

那么，理论上每天最多只能处理 500 条。

如果告警到达速度长期超过团队处理能力，积压就会持续增加。

这实际上是一个排队论问题。

我们可以把告警看成需要处理的任务：

告警产生速度，是任务到达率；

分析人员处理速度，是服务率；

未处理告警，是排队中的任务。

如果平均到达率超过平均处理能力，队列就无法稳定。

即使检测系统能够发现所有异常，也不代表企业有能力处理所有异常。

当告警数量远远超过人的处理能力时，会出现几个问题：

告警疲劳：分析人员逐渐降低对告警的敏感度。

自动化偏见：过度相信自动化系统给出的结论。

机械式处置：为了完成工单指标，优先关闭告警，而不是理解风险。

注意力挤占：低价值告警消耗了本应用于高风险事件的时间。

这里还有一个值得警惕的现象：

如果 Agent 本身负责处理告警，那么 Agent 的错误判断也可能进入自动化处置链。

例如，Agent 将一次真实的数据外传行为判定为正常，并自动关闭告警。

这时候，自动化不仅没有降低运营成本，反而可能放大错误。

因此，自动化的价值不能只用处理速度衡量。

还需要考虑错误概率、错误影响范围，以及错误是否能够被发现和恢复。

企业需要做的可能不是无止境地增加检测规则，而是：

减少重复告警；

合并同源事件；

提高告警上下文质量；

根据风险进行分级；

将低风险、低复杂度事件自动化处置；

将人的注意力集中在高影响、高不确定性事件上。

七、多买几个安全产品，就意味着多几道防线吗？

不一定。

假设企业部署了三套安全产品：

一套终端安全产品；

一套流量检测产品；

一套 Agent 行为审计系统。

看起来已经有三道防线。

但如果它们依赖相同的数据源、相同的身份体系，或者使用相似的检测逻辑，那么它们可能同时失效。

假设有两道防线：

第一道防线失效的概率为 10%，第二道为 20%。

如果两者完全独立，那么它们同时失效的概率为：

P(A ∩ B) = 10% × 20% = 2%

看起来风险已经很低。

但现实中，防线可能存在共同的失效原因。

例如，攻击者成功窃取了一个高权限身份凭证。

终端产品没有发现异常，流量检测没有识别出异常行为，Agent 审计又因为权限本身合法而没有触发告警。

三套产品都在正常工作，却没有阻止攻击。

这涉及系统工程中的一个概念：

共同原因失效（Common Cause Failure）。

在可靠性工程中，可以用 β 因子模型描述共同原因失效。

直观来说，防线失效不再只是各自独立概率的乘积，还需要考虑由共同原因导致的同步失效部分。

因此，实际整体失效概率可能明显高于独立模型的估计。

这也让我想到图论中的攻击图。

企业可以把身份、Agent、工具、数据和外部服务看成图中的节点，把访问、调用、信任和数据流动看成边。

攻击者并不一定需要攻破所有节点。

只要找到一条能够从低权限入口通往高价值资产的路径，就可能形成完整攻击链。

因此，安全架构不应该只关注单个组件的安全能力，还应该关注：

哪些节点拥有过高权限；

哪些路径能够跨越安全边界；

哪些节点一旦失陷会影响多个系统；

哪些关键路径缺少独立的检测和阻断；

哪些操作缺少回滚和恢复能力。

对 Agent 而言，工具调用链、身份继承关系、上下文传递和数据访问路径，可能比单个模型的安全评测分数更值得关注。

八、攻击者也会学习：安全不是静态优化问题

前面的模型还有一个局限：

我们假设攻击者不会改变策略。

但现实中的攻击者显然不会配合我们的数学模型。

企业加强了某类检测，攻击者就可能转向其他路径。

例如：

企业加强 Prompt Injection 检测，攻击者可能转向 Skill 供应链；

企业限制 Agent 的工具调用，攻击者可能寻找身份权限或业务流程中的漏洞；

企业加强静态规则，攻击者可能利用动态执行和上下文变化规避检测。

这就不再是一个静态优化问题，而更接近动态博弈。

防御者的策略会影响攻击者的行为，攻击者的行为又会改变防御者面对的风险分布。

因此，今天计算出来的最优预算分配，未必在半年后仍然有效。

这也是为什么安全能力不能只靠一次性建设。

企业需要持续监测风险变化，定期重新评估投入效果，并根据攻击者的行为调整防御策略。

安全预算不是一次性求解出来的答案，而是一个需要持续更新的决策过程。

九、期望损失最低，不代表企业就安全了

前面的数学模型一直在优化年度预期损失。

但这里还存在一个问题：

期望值可能掩盖极端损失。

假设企业有两种风险：

风险 A：每年发生概率较高，但每次损失只有 10 万元；

风险 B：每年发生概率极低，但一旦发生，可能导致核心数据泄露，损失数亿元。

如果只比较年度预期损失，风险 B 可能显得不那么重要。

但对企业而言，一次极端事件就可能造成无法承受的后果。

这属于典型的尾部风险问题。

在金融风险管理中，有一个常见概念叫 CVaR（条件风险价值）。

它关注的不是平均情况下会损失多少，而是在最糟糕的一部分情形中，平均损失有多大。

企业安全也可以借鉴这种思路。

例如，除了优化年度预期损失，还应该单独约束：

核心数据泄露的最大影响范围；

高权限凭证失陷后的可访问资产；

Agent 批量执行错误操作的最大规模；

关键业务中断的最长时间；

不可逆操作的审批和恢复要求。

换句话说，某些风险不能只通过增加预算来交换。

它们应该成为不可突破的安全底线。

例如，法规明确禁止的行为、核心数据的访问边界、关键权限的授予条件，不应该因为模型认为预期收益更高就被放宽。

先满足不可突破的安全约束，再在剩余空间里优化成本与风险。

这比单纯追求一个更低的期望损失数字更加符合企业实际。

十、真正的难题：理论最优解，可能根本无法执行

即使我们知道理论上的最优方案，企业真的能够执行吗？

例如，模型认为企业应该投入 42.96 万元建设数据泄露防护能力。

但现实中可能存在：

没有合适的产品；

缺乏足够的技术人员；

业务部门不愿意配合；

现有系统无法改造；

采购周期过长；

安全措施会严重影响业务效率。

这时候，数学给出的最优解可能只是纸面上的最优解。

这里可以引入 Herbert Simon 提出的有限理性（Bounded Rationality）。

人的认知能力、时间、信息和组织资源都是有限的。

现实中的决策者往往无法找到所有可能方案，也无法准确计算每种方案的全部后果。

因此，人们经常选择的不是理论上的最优解，而是一个满足关键要求、能够执行、成本可接受的满意解（Satisficing）。

但满意解不等于可以接受任何风险。

这里必须区分两类约束：

第一类：不可突破的底线。

例如：

法规和监管要求；

核心数据访问权限；

关键业务的安全边界；

高危操作的授权要求；

不可逆操作的审批机制。

这些约束不能简单地用成本收益交换。

第二类：可以优化的运营指标。

例如：

告警处理效率；

检测覆盖率；

安全产品采购成本；

误报率；

自动化程度；

平均恢复时间。

这些指标可以在满足安全底线的前提下进行权衡。

一个能够持续运行的 80 分安全方案，可能比一个永远停留在 PPT 上的 100 分方案更有价值。

这也解释了为什么企业安全架构不能只追求技术上的完美。

它还需要考虑人的能力、组织的执行力，以及业务本身的承受能力。

十一、还有一种更有意思的投资：先花钱获得信息

前面我们一直在讨论如何把预算投入防御措施。

但如果企业对风险的判断本身就不准确呢？

这时候，是否应该先投入一部分预算，用来提高对风险的认知？

例如：

企业不知道 Agent 是否存在越权操作。

与其直接采购一套昂贵的防护系统，不如先建设操作审计、权限调用追踪和异常行为监测。

先弄清楚：

哪些 Agent 在调用哪些工具；

哪些身份拥有过大的权限；

哪些操作缺少人工确认；

哪些数据正在被访问和传输；

哪些异常行为经常发生。

这笔投入不一定直接降低风险，却可能改变后续的决策质量。

决策理论中有一个概念叫信息价值（Value of Information，VOI）。

可以简单理解为：

VOI = 有信息时的最优预期收益 − 无信息时的最优预期收益

举一个简化例子。

假设企业面临两种可能的泄露路径：

A：Agent 通过外部工具调用导致数据外传；

B：Agent 通过本地文件访问导致数据外传。

企业判断两种情况各有 50% 的概率。

目前有两套针对性防护措施，每套建设成本都是 20 万元。

如果不掌握更多信息，企业只能选择其中一套。

假设选错了，可能产生 100 万元损失。

那么，企业不进行监测时：

选择 A 或 B 的期望残余损失都是 50 万元；

再加上 20 万元防护成本；

总成本为 70 万元。

现在，企业可以先花 2 万元建设监测能力，准确识别主要风险路径，再购买对应的 20 万元防护措施。

假设监测结果足够准确，那么：

监测成本为 2 万元；

对应防护成本为 20 万元；

理想情况下不再承担选错路径导致的 50 万元期望损失。

总成本变成 22 万元。

这个简化场景中，先获得信息可以节省约 48 万元。

当然，真实监测系统不可能永远准确，还要考虑检测误差、部署成本和信息时效。

但这个例子说明：

有时候，企业最值得投入的第一笔钱，不是用来直接阻断攻击，而是用来弄清楚攻击究竟可能从哪里发生。

信息本身未必降低风险。

但它可能改变我们选择防御措施的方式。

十二、重新理解 Agent 企业安全：让安全能力变得可度量

回到最初的问题。

如果 Agent 犯错是长期运行下难以避免的事件，企业安全究竟应该如何设计？

我认为，至少应该从以下几个维度重新审视。


维度	可以考虑的度量方式	需要回答的问题
风险降低效率	单位预算降低的预期损失	每一笔投入究竟产生多少价值？
权限与影响范围	单次错误最多影响的资产数、记录数或系统数	Agent 犯错最多能造成多大影响？
错误可发现性	检测覆盖率、漏报率、平均发现时间	错误发生后能否及时发现？
恢复能力	平均恢复时间、恢复成功率、数据回滚成功率	出错后能否恢复？
人的运营负担	人均告警量、平均处理时间、积压量	安全系统是否超过人的处理能力？
适应能力	风险重新评估周期、规则失效率、策略更新时延	攻击者改变策略后能否及时调整？