可觀測性不等於治理:為 Agentic AI 打造 Runtime Trust Plane

TL;DR

• 一句話拆穿業界的混用:observability 和 governance 在業界被交替使用,但 observability 只回答「發生了什麼」,治理要回答「我們能不能對它做點什麼」。兩者互補、不可互相取代。
• 要治理的對象是 control path,不是 agent:控制路徑是動態的,所以要在其中埋 hook,即時評估哪裡可能出錯、預測會出什麼錯、定義出錯時的 outcome,再據此建立風險控制。
• 實作核心是 declared vs observed:他們先為環境中每個 agent 建立「declared authority」契約資料庫(該做什麼、碰哪些系統、呼叫哪些工具),上線後比對實際觀測值,把差異分成 allowed / approved / drift / control failure 四類——control failure 才是最重要的指標,drift 本身未必是壞事,重點是知道 delta。

重點整理

起點:一次 audit 把整個專案叫停(約 02:31–02:36)

Thales 的工作是建構安全架構與框架,涵蓋自家內部系統與終端使用者將使用的系統。促發他思考的事件,是他所說的「上週或前一週,一個 agent 決定做它自己想做的事」。由此延伸出三個問題:我們的 agent 在做什麼?我們怎麼治理它們?在營運環境中我們該擔心哪些挑戰?

他先給了兩個產業數字:

• Gartner 的預測是,企業大量部署 agent 與 ML+LLM 系統,而其中超過 40% 會在 2027 年前失敗(Gartner 原文的說法是「被取消」,原因包含成本失控、商業價值不明、風險控制不足)。
• 另一份調查(他明確說「這不是產業 benchmark,是一份 survey」):只有 14.4% 的組織真的從安全角度在看這件事。

然後是那個讓全場工程師會心一笑的故事:工程師被要求 build it、ship it、get it out the door,然後 audit 進來踩煞車。他自己就遇過——audit 檢查了 agent 的權限與 entitlement,結論是「看起來它們想做什麼就能做什麼」。專案被迫停下、重新設計,跟 identity 團隊合作建立身分,並確保這些身分帶有 signed intent:一份定義「這個 agent 應該根據它該交付的成果做哪些事」的契約。

AI 之前 vs AI 之後:線性環境的終結(約 02:36–02:38)

AI 之前的環境是線性的:使用者 → SaaS → 商業系統。我們知道系統被要求做什麼、使用者在做什麼,因此能在這些節點外圍套上治理控制與安全指標。

今天則是使用者、agent 或兩者一起工作:一個使用者發出請求,那個請求可以呼叫 agent、呼叫模型,再加上 orchestration——結果是整個生態系在即時、同時地自己活了起來。

因此他們在 Thales 從三個層面著手:execution、runtime governance、evidence layer。理由是:沿用線性流程、線性治理模型、軟體時代的基本測試與內嵌 QA,今天不夠——因為工作流是並行發生的,功能綁在這些工作流上,而有時候我們根本不確定誰對這些工作流中的功能負責、誰要當責。

於是需要建立一個交易(transaction)紀錄的資料庫:這些交易執行時造成什麼影響、如何根據影響建立風險指標,再由此構成 evidence layer。

Sub-agent 的權限繼承問題(約 02:38–02:39)

底層依 human request 與 delegated authority 切分。他和團隊最在意的問題是:當我們把權限與 entitlement 指派給一個 sub-agent 時,那個 sub-agent 是不是照它該有的方式在行動? 如果它是代表另一個 agent 行動,而且繼承了主 agent 的權限、entitlement 與授權——這件事該發生嗎?

他的回答與現場共識一致:不該。但他隨即點出落差:「在座這群人是有限的,產業比我們大得多。我看到的挑戰是,大家為了 build and ship 在跳過步驟——一旦跳過,我們就把自己暴露在風險裡。」

核心論點:observability ≠ governance(約 02:39–02:42)

因為有 evidence layer,他們看的不是 agent,而是 control path。控制路徑是動態的,所以必須在其中埋 hook,才能即時評估哪裡可能出錯、預測會出什麼錯、定義出錯時的 outcome,並針對它建立風險控制。

接著是整場的核心:

• Observability 很好——我們看得到正在發生什麼。但我們能對它做什麼嗎?這才是問題。
• 談治理時,我們知道有事情正在發生(因為模型正在執行),但真正要做的是評估控制路徑,並基於某個 outcome 在控制路徑上施加治理。
• 而那個 outcome 的存在是為了強制執行決策,那些決策綁定在 identity、policy、authorization 三者上。有了資料就能建 decision matrix,再在執行路徑上依控制路徑的風險施加控制。
• 結論:observability 加 governance,兩者不可互相取代,必須並行運作。

Declared vs observed 與 runtime trust plane(約 02:42–02:46)

實作上,他們為環境中所有 agent 建了一份契約與資料庫,定義每個 agent在做什麼、與什麼互動、呼叫哪些工具、牽動哪些系統——這就是 declared authority。

系統跑起來之後,結果不出所料:出現了 variance,實際行為與 declared state 不符。於是他們對 variance 做分析,建在他們的 runtime trust plane 上,比較 declared vs observed,搭配 identity、delegation、policy、risk 的指標以及前述 evidence layer。

他在這裡丟出第二個反直覺論點:drift 未必是壞事,重點是我們要知道 delta。 他們把 explained variance 分成四類:

1. shown / allowed(已宣告、允許)
2. approved(經核可)
3. drift(漂移)
4. control failure(控制失效)

他問全場哪個最重要,答案是 control failure。

工程環境上,他們用四個 constraint 收斂,包含 ephemeral agents、觀測到的 drift,以及延遲——他在此點名前面 Oracle 醫療講者的說法,延遲直接影響成本。由這些資料建出一條 containment path,核心是一個明確定義的 kill switch,可執行的動作有:quarantine(隔離)、roll back(回滾)、取得次級授權(secondary authorization)、或直接停止。

最後是執行前的裁決機制:對「agent 發出的 function」與「decision proposal」,他們在 runtime trust plane 上評估一個 envelope——涵蓋 authority、policy、risk、evidence 四個維度——通過才允許 execution commit。而且會標上風險分類:低風險自動執行,高風險需要人類核可。

他總結:他們建的是一份即時運作、橫跨所有邊界的 record of trust,從 identity 一路涵蓋到 action。時間用盡前他提到環境中還有一個「guardian agents」的概念,只留了一句「之後再聊」。

金句

"Observability is good. We can see what's happening, right? But can we do something about it? That's the question."(約 02:40)

整場演講的題目就是這句話的展開。

"We are a finite group. Over in larger industry, the challenge I'm seeing is people are skipping steps because we need to build and ship. And if we build and ship, we open ourselves up to risk."(約 02:39)

在座懂的人不代表產業會做——這是治理落差的真正來源。

"Drift is not necessarily bad. We need to know the delta."(約 02:43)

治理的目標不是消滅偏差,而是讓偏差可分類、可裁決。