AI Engineer onepage/ agentic security
Manoj Nair, Snyk · 約 23:29
這支影片在講：生成器不能兼任安全驗證器
Agent 寫程式的速度正在放大漏洞供給；但模型輸出有波動、工具與 MCP 又擴大資料邊界。Snyk 的主張是：把可重複的確定性驗證放回 agent 的工作迴圈，而非交給另一個 prompt 來「自我審查」。
Published: 2026-07-20Video ID: 1EZdpEhwmNc
01 / 問題
產能與風險一起放大
Agent 更快產出程式，也更快累積待修漏洞；安全團隊若仍靠事後掃描，backlog 只會愈追愈遠。
02 / 反轉
模型不能當自己的裁判
同一類 frontier model 重複找同一漏洞，結果仍會波動；概率式生成器不該是唯一 validator。
03 / 解法
把驗證嵌入 coding loop
用可重複的 policy、掃描與風險訊號，讓 agent 在提交、選依賴、使用 skill 前就遇到可解釋的安全邊界。
Signals
四個不該忽略的數字與轉折
Security backlog
+108%
Snyk 表示其 4,800 家客戶的 security backlog 季增 108%，修補速度沒有追上產能。
Enterprise scale
5,000
演講者所屬團隊保護約 5,000 家企業，其中包括半數 Fortune 500。
Validator benchmark
40% F1
對照確定性 checker，模型最多找出 75% 問題；穩定性不足以單獨擔任 gate。
Remediation
16,000
演講後段以大規模 remediation 示範：重點是讓修補工作可被優先排序並帶回開發迴圈。
Core story
Agentic security 必須做對的三個架構決策
01
分離生成器與驗證器
讓 agent 生成程式或建議；由獨立、確定性的 policy 與 checker 決定是否能往下走。這不是反對模型，而是縮小「模型自己說自己安全」的信任範圍。
02
把 skill、MCP 與資料流當成攻擊面
有害指令可能只要幾行自然語言。MCP 連上企業資料後，agent 也可能在看似完成任務的過程中把 PII 帶往不受信任的位置。
03
從事後掃描改為 loop 內預防
在選 package、採用 agent skill、產生變更與提交前顯示風險，才能讓安全訊號影響決策；只在部署後告警，通常已經太晚。
Trade-offs
影片帶出的實務取捨
可觀測性不是監看清單，而是治理前提不知道 agent 讀了什麼、呼叫了哪些工具、寫往哪裡，就無從施加最小權限與驗證。
不要用單一模型版本定義安全紅隊測試顯示模型間表現差異很大、也會隨版本改變；policy 與驗證必須可重現且獨立。
把安全摩擦放在高風險轉折點不是每一步都阻擋，而是在外傳資料、引入依賴、執行未驗證 skill 等動作前要求可解釋的檢查。
修補要能回到開發者手邊風險發現若無法帶著上下文、優先度與可操作建議回到 coding loop，只會成為另一份 backlog。
Checklist
給 agent 平台與 AppSec 團隊的五項檢查
把生成與驗證拆成不同責任列出哪些 gate 不能只靠 LLM 判斷：secret、PII、權限、依賴來源與高風險副作用。
為 MCP 與 skill 建立 inventory追蹤每個 server、skill 的來源、權限、資料讀寫範圍與更新版本；未知的工具不能視為低風險。
記錄 agent 的資料與工具軌跡至少保留任務、工具呼叫、資料目的地與 policy 決策，才能重建 incident 與調整邊界。
在開發迴圈中回饋安全訊號把 package health、漏洞、權限與修補建議顯示在 agent 正在做決策的位置，而非只送到外部報表。
以對抗測試驗證控制層測試 prompt injection、資料外傳、約束繞過與模型切換；驗證的是整個 system，而不是單一次 demo。
Source video