Glasswing 把 AI 變成安全閘門

以前把 AI 當功能塞進流程，現在把它放進安全閘門裡做初步審查。

我最近一直在看各種「trusted AI」的說法，老實講，很多都很像把模型硬塞進工作流，然後貼一張治理標籤就算交代了。我用過幾次之後只覺得卡：模型很會講，流程很順，最後卻沒人說得清楚它到底影響了哪個決定。這種東西拿來做 demo 可以，拿來碰金融軟體，我心裡會先亮紅燈。

這次真正讓我停下來看的，是 FIS 和 Anthropic 的 Project Glasswing。FIS 把 Anthropic 的 Mythos 5 放進它的安全計畫，講法不是「AI 幫你做一切」，而是「AI 多一層控制點」。這個 framing 比那種空泛的 enterprise AI 廢話實在多了。

把 AI 當閘門，別把它當功能

Through Project Glasswing, FIS is putting Mythos 5, Anthropic’s most advanced frontier model, to work as an additional layer within its security program.

翻譯一下就是：模型不是產品本體，它是審查路徑的一部分。這句話很重要，因為我看過太多團隊把 AI 當成快捷鍵，結果把風險也一起加速送進 production。先過度信任，出事後再怪模型不夠聰明，這套我真的看膩了。

我之前在內部工具審查裡就碰過這種事。模型拿來做風險分類、程式摘要、異常標記，確實有用；但如果你讓它單獨站在變更和上線之間，那就是在等 postmortem。FIS 的說法比較對路：additional layer。Layer 才是重點，oracle 只是幻覺。

實操上，我會把 AI 放在人工審查前面，不是取代人工。讓它先做 triage、score、摘要、標記可疑點，再把最終判斷交給人。只要流程沒辦法清楚記錄「模型怎麼影響最後決定」，這流程就還不夠硬，根本不適合碰受監管的工作。

• 讓模型先找異常，不要讓它直接放行。
• 凡是牽涉客戶資料、權限、金流的操作，都保留人工簽核。
• 把模型輸出和最終 reviewer 決策一起記錄，方便之後回頭查 drift。

所謂 trusted AI，先把信任邊界畫出來

FIS 和 Anthropic 都在講 trusted AI，但我比較在意的是邊界。到底誰信任？信任什麼任務？在什麼限制下？如果這三件事沒講清楚，trusted 只是裝飾詞，聽起來很正經，實際上什麼都沒定義。

Project Glasswing 有意思的地方，是它把重心放在 foundational software 的建構者和維護者身上。這代表 trust boundary 不只是 end-user app，而是更底層的基礎設施層。金融服務裡最髒、也最不能亂碰的東西，通常就是權限、稽核軌跡、政策執行、release control，還有那些平常沒人想起來、出事時卻最致命的系統。

我看過團隊想把 AI 直接塞進這些層，結果翻車，原因通常不是模型不夠強，是他們根本沒先寫清楚模型能碰什麼。模型能看哪些資料？只能建議還是可以標記？能不能碰 production logs？能不能看 secrets？這些問題如果你不能一口氣答完，代表你還沒畫好邊界。

實操上，我會先寫一頁 model policy，再把模型接進敏感流程。別寫得花俏，越普通越好。把允許的輸入、允許的輸出、升級規則、保留規則，還有每個步驟的責任人寫死，才有辦法談信任。

• 先縮小模型作用範圍，再談擴張。
• 把 assist 和 authorize 分開，別混在一起。
• 讓工程、資安、法遵都看得到這份政策，不要只給主管看。

Glasswing 真正在解的是基礎設施的痛

我覺得最值得劃線的，不是品牌名，而是這句：Project Glasswing 連結的是那些建造或維護 foundational software 的組織。這句話很直白，意思是它不是衝著寫簡報的人去的，是衝著在 plumbing 裡面幹活的人去的。

這也正中我以前踩過的坑。很多團隊的 security review 永遠落在工程痛點後面，等資安進場時，架構早就被各種 shortcut 綁死了。你如果真的想讓 AI 幫忙，就得把它放到 architecture、policy、implementation 交會的地方，而不是丟到最外層做裝飾。

把模型放近一點之後，它能幫的事情其實很土：看 dependency review、抓 config drift、掃 access-control change、整理 alert summary。這些都不性感，但安全工作本來就不是靠性感活著。大部分時間都很重複，直到突然不重複為止。

實操上，我會先拿模型去碰最無聊的區域。先做依賴審查、設定檔漂移、權限變更、警報摘要。這些地方最能省時間，也最不需要把決策權直接交出去。

安全團隊要的是更快的 triage，不是信心表演

企業 AI 很愛把模型說得像更會做事的員工，我對這種講法很煩。員工有責任、有上下文、也有判斷；模型只有模式匹配和失敗模式。把這兩者混為一談，最後就會變成 confidence theater，看起來很安心，實際上只是把風險包裝得更漂亮。

FIS 在 Project Glasswing 裡的說法比較務實：把 Mythos 5 當成安全計畫裡的 additional layer。這聽起來就像 triage、filtering、review assistance。很好，這才是現在模型真的能幹的事。它縮短的是「發現怪事」到「有能力的人開始看」之間的時間。

我自己會把這當成 AI 在安全場景的核心 KPI：不是某個抽象的 accuracy，而是 time-to-human-attention。模型如果能讓每次 incident review 少等 30 分鐘，那就是實打實的價值；如果只是把錯誤決策寫得更漂亮，那只是壁紙。

實操上，別先量模型本身，先量流程。看 suspicious event 多久能被路由出去、模型標記有多少被接受、又有多少被人推翻。如果模型只是多了一層步驟，卻沒有縮短 review time，那它根本沒幫上忙。

• 量流程時間，不要只量模型分數。
• 追蹤 flag 被接受與被覆寫的比例。
• 如果模型增加步驟卻沒減少等待時間，就該停。

金融業一直把 AI 拉進控制系統，原因很現實

金融服務不能隨便來。每一個偷懶的 shortcut，最後都可能變成 compliance issue、fraud issue，或是 customer trust issue。這也是為什麼我特別注意 FIS 這種公司怎麼談 AI security，而不是拿 AI 來做行銷或客服。門檻本來就不一樣。

Anthropic 也值得看，因為它給人的感覺比較像 controlled deployment，而不是放任式實驗。這不代表系統就安全，當然沒有；但至少起手式不是「我們先把模型接到所有東西上再說」。這種克制，很多團隊其實缺很大。

我看過太多團隊買了一個模型，接進流程，然後才發現沒人知道怎麼 audit output。這在一般產品可能還能拖，在金融業就不是小事，這幾乎就是問題本身。

實操上，只要你在受監管環境工作，就把每個 AI integration 當成新的 control surface。先問誰擁有、誰稽核、誰能關閉、模型 hallucinate 時怎麼辦。答案如果還很模糊，就先不要往下接。

我會抄的，是操作模型，不是包裝詞

Project Glasswing 這名字聽起來很漂亮，這我承認。但真正有用的是背後那個 operating model：AI 當安全層、綁在 foundational software 上、角色窄、責任清楚。這才是可以偷走的部分，而且不用跟著整套 vendor 敘事一起買單。

如果是我自己重做，我會直接跳過那些大話。把模型放進 review lane，限制它的 authority，輸出要能 audit，最後還是人負責。這不性感，但這就是避免 AI 變成另一個沒人敢接手的黑盒子的方式。

原始內容沒有丟一堆性能數字，這點我反而覺得好。沒有 context 的數字，最容易拿來養出糟糕的 enterprise 故事。這裡真正值得學的是部署形狀：是一層額外控制，不是替代品；是一個 security program，不是一場 demo。

可抄的模板

# AI Security Layer Operating Model

## Purpose
Use an AI model as an additional review layer inside a security program.
The model assists with triage, summarization, and anomaly spotting.
It does not approve releases, grant access, or replace human review.

## Allowed inputs
- Security alerts
- Config diffs
- Dependency metadata
- Access logs with approved redaction
- Policy text and control mappings

## Disallowed inputs
- Secrets, private keys, or raw credentials
- Unredacted customer data
- Production data outside the approved review scope
- Any data not covered by the current retention policy

## Allowed outputs
- Risk summaries
- Triage labels
- Anomaly flags
- Suggested next-review actions
- Human-readable explanations for reviewers

## Human control points
1. Model generates a review packet.
2. Human reviewer inspects the packet.
3. Reviewer accepts, rejects, or escalates.
4. Final action is recorded with reviewer identity.
5. Model output is stored for audit comparison.

## Policy rules
- The model may recommend, but never authorize.
- Any high-risk change requires human sign-off.
- Any uncertain output is treated as a flag, not a decision.
- Model access is reviewed on a fixed schedule.
- Output quality is checked against incident outcomes.

## Audit fields
- Request ID
- Input category
- Model version
- Reviewer ID
- Model recommendation
- Final human decision
- Override reason
- Timestamp

## Rollout checklist
- [ ] Define scope
- [ ] Approve data boundaries
- [ ] Assign human owner
- [ ] Add logging
- [ ] Add override path
- [ ] Test with low-risk cases first
- [ ] Review false positives and false negatives
- [ ] Document disable procedure

## Example usage
"Review these changes for policy drift, suspicious access patterns, and dependency risk.
Return a short summary, flags, and the exact reason each item was flagged.
Do not approve or reject the change."

這份模板你可以直接拿去改成自己的版本。把控制欄位、稽核欄位、允許輸入換成你們的環境語言就好。若你在金融、保險、支付這種地方工作，我會先把模型鎖在 review lane，等你真的證明它可稽核，再談擴權。

來源是 Business Wire 的公告，以及 FIS、Anthropic 的公開資訊。上面對 operating model 的拆解和模板化，是我根據原文自己整理出來的可抄版本。