AI Engineer onepage/ Agent Runtime
Tushar Jain, Docker · 約 20:26
這支影片在講：Agent 的權限不能跟著推理一路膨脹
一個追查延遲的 agent 從 logs 走到另一個服務、GitHub 與 Slack；每一步都合理，合起來卻讓單一程序握有過大的 blast radius。Docker 的主張是：把安全控制做成獨立於模型與 harness 的 runtime。
Published: 2026-08-20Video ID: zaGyGgLW3SM
01 / 問題
行為會在執行時長出來
傳統程式能預先宣告權限；agent 會一路判斷「下一步需要什麼」，所以靜態權限設計很快失效。
02 / 反轉
合理的下一步會累積風險
查延遲需要跨服務 logs、commit history 與對話脈絡；權限若不拆分，單一任務就會收集到所有敏感面。
03 / 解法
以 runtime 收回控制權
用 containment、任務級 capabilities 與意圖檢查，讓環境而非 agent 自己決定何時可存取什麼。
Watch for this
影片最值得抓的四個訊號
Boundary
外置
控制器必須在 agent 所在的 boundary 之外，不能由被控制的程序自行決定。
Scope
每任務
不要讓單一 sandbox 長期累積憑證；每個 task 只注入需要的 capability。
Decision
看意圖
從原始請求判斷存取是否合理；incident investigation 突然要 email 應被拒絕或升級。
Demo
2 sandbox
將一份工作拆進兩個範圍不同的 sandbox，避免一次取得資料與寫入權。
Core story
讓 agent 自主、但不失控的三層設計
01
Containment：控制不能放在 agent 手裡
模型、harness 或 sandbox 都可能被 prompt injection 影響。安全決策須由外部 runtime 執行，才能在 agent 改變策略時仍保有一條不可自行跨越的界線。
02
Task-scoped capabilities：不用永久大權限
把權限綁在當前任務，而非綁在一個會不斷累積工具與 secrets 的長壽 sandbox。需要讀 logs 的步驟拿讀取能力；需要寫入時再另行隔離、授權。
03
Intent-based access：檢查「為何需要」
授權不只問「這工具能不能用」，還要對照最初任務。調查 latency 卻想讀 email，代表需求漂移；runtime 應拒絕、要求人類確認，或開一條新流程。
Why it matters
Docker 的 runtime 提案，落在工程上是什麼
Runtime 要與 model / harness 解耦安全層不應押注某個模型足夠可靠，或某個 agent framework 永遠正確；它應是所有上層都必須經過的執行期政策層。
憑證以 just-in-time 方式注入示範中的 sandbox 可得到注入的 credential 與 stub。把取得 secret 的時機縮到真正需要的子任務，並讓其隨任務結束失效。
拆 job，也拆權限與資料路徑將同一個工作分給兩個 scoped sandbox，不是為了平行化而已；它把「讀敏感資料」和「執行副作用」拆成可驗證的邊界。
雲端不是新的信任前提相同的 sandbox 可以移到雲端，但安全主張仍是可攜的 containment 與 capability policy，而不是信任某個部署位置。
Use this checklist
如果你正在上線 agent，先檢查這五點
每個 task 都有最小 capability set 嗎？明確列出讀、寫、網路、secret 與 tool 權限；預設不繼承上一個任務的授權。
安全控制真的在 agent boundary 之外嗎？若 agent 或其 harness 能自行修改 policy、開啟網路或取得 credential，containment 只是約定，不是防線。
高風險存取會回看原始意圖嗎？把 action 與 initial user request 對照；需求突然跨到 email、repo write 或外部系統時，要求升級授權。
讀取與副作用能拆進不同 sandbox 嗎？尤其是資料調查、程式變更、部署與訊息傳送，不要讓同一個自主迴路同時持有全部能力。
你有可稽核的授權決策紀錄嗎？記錄哪個任務在何種意圖下請求何種能力、被允許或拒絕；否則事後無法分析自主性如何越界。
Source video