update · TowCue 編輯團隊
F5 Workforce AI Security 瞄準下一個企業 AI 問題：控制 Agent 真正能做什麼
F5 於 2026 年 9 月 9 日公布 Workforce AI Security。TowCue 解析其 Agentless AI discovery、MCP 與 tool-call 控制、資料政策、審計紀錄，以及企業 AI 治理為何正從聊天工具存取轉向 Agent 執行層。
快速解答
F5 在 2026 年 9 月 9 日公布 Workforce AI Security，把企業 AI 安全從「員工用了哪些 AI」進一步延伸到更重要的一層：AI Agent 代表員工執行動作時，企業能不能在執行前套用政策。
F5 官方頁面列出的能力包括：從網路流量中發現公有與私有 AI 使用、辨識使用意圖、檢查 prompt 與敏感資料、建立可審計紀錄，以及對 MCP server 與支援的 Agent tool call 在真正執行前進行分類與政策判斷。
這也是這次更新最值得 TowCue 關注的地方。企業 AI 治理正在從「哪些 chatbot 可以打開」走向「Agent 到底有權限做什麼」。當 coding agent、browser agent、workflow agent 開始取得工具、憑證與企業系統權限，真正需要治理的是 execution layer，而不只是模型與 prompt。
TowCue 的判斷是：這與最近多個 Agent 產品的設計方向一致。真正可靠的安全邊界會越來越多地放在模型外部——身份、網路、tool permissions、approval 與 audit logs，而不是期待模型永遠記得安全規則。
F5 這次公布了什麼
F5 將 Workforce AI Security 定位為一個 agentless 的企業 AI 可視性與控制層。9 月 9 日的公告特別強調，它不只管理員工如何使用 AI，也管理 AI Agent 代表使用者採取的行動。
官方產品頁列出六類核心能力：
- 自動發現企業流量中出現的 AI 服務
- 建立 AI service、model 與 agent tool 的集中 inventory
- 觀察 prompt、資料流與使用情境
- 依照政策將使用者導向核准模型或封鎖高風險服務
- 建立 AI interaction 與政策決策的 audit-ready logs
- 檢查與分類跨 MCP server 與支援 Agent tool 的呼叫，在 action 執行前套用政策
前五項比較像傳統 AI governance 的延伸，而第六項代表的是另一個層級的問題。
發現員工用了未核准 chatbot，是 visibility 問題；阻止 Agent 呼叫一個危險工具，則是 authorization 與 execution 問題。
為什麼 MCP 與 tool call 改變了治理問題
過去企業治理生成式 AI，主要問的是：
- 員工正在使用哪些 AI 網站？
- 是否有人把機密資料貼進公開模型？
- 哪些模型被允許？
- Prompt 裡如果出現 PII，能否阻擋或遮罩？
這些問題現在仍然重要，但 tool-using Agent 多出了一條新的風險路徑。
Agent 可能讀取檔案、查詢內部系統、修改 ticket、產生 code change、寄送訊息或呼叫 API。當 MCP 越來越常被用來把工具與上下文暴露給 AI client 時，控制點就不再只有「進入模型的 prompt」，還包括 從 Agent 離開、準備執行的 tool request。
F5 表示，它的平台可以持續發現並追蹤 Agent tool calls 與 MCP connections，並對支援的動作在執行前套用 policy。
這種架構其實更接近 API security，而不是傳統 chatbot filtering：
- 確認使用者與 Agent 身份
- 知道 Agent 正在請求哪一個 tool
- 分析涉及的商業意圖與資料
- 套用 policy
- 允許、重新導向、遮罩或封鎖
- 保留完整紀錄供後續調查
核心原則很簡單：不能因為啟動 Agent 的員工本身權限很大，就讓 Agent 自動繼承無限制權限。
Agentless visibility 很有價值，但需要看清楚邊界
F5 表示，Workforce AI Security 可以透過被動分析 mirrored network traffic 來發現 AI 使用，不需要另外安裝 endpoint agent 或 browser extension。這種 out-of-band 分析，依 F5 的說法不會增加 production traffic latency。
對大型企業而言，這可以大幅降低部署阻力，也有機會發現安全團隊原本不知道存在的 shadow AI。
但 TowCue 會特別檢查三個邊界。
1. 到底哪些流量真的看得到？
Encrypted、local、private 或不經過網路的活動，可能需要不同的 integration point。企業不能只看到「agentless」就假設所有 Agent 行為都會自動被捕捉。
2. 哪些 tool ecosystem 支援 pre-execution control？
F5 官方文字是對 MCP server 與 supported agent tools 套用政策。這個「supported」很重要。企業應該針對自己真正使用的 coding agent、MCP transport 與內部工具逐一測試。
3. 是被動觀察，還是真的阻擋？
事後在 dashboard 看見危險行為，對 forensic 很重要；但它不等於 action 在發生前被阻擋。Security review 應該明確區分 discovery、logging 與 enforcement。
Prompt security 正在變成 execution security
F5 原本的 AI Security Platform 已經涵蓋 prompt injection、資料外洩、model risk 與 runtime guardrails。Workforce AI Security 把另一個問題拉進來：員工所使用的 AI Agent 實際採取了什麼行動。
因為 tool-using Agent 最嚴重的失敗，不一定是回答錯一段文字，而可能是執行了一個看似合理、但範圍錯誤的 action。
例如：
- coding agent 把修改 push 到錯誤 repository
- operations agent 把 staging 設定套到 production
- support agent 透過外部工具暴露客戶資料
- finance agent 執行超過預設限制的交易
- browser agent 被惡意頁面誘導後呼叫了連接工具
這些風險很難只靠 system prompt 解決。
更可靠的模式是把 reasoning 與 authority 分開：
模型負責提出動作，外部政策層決定它到底能不能執行。
最大價值可能出現在多 AI 供應商環境
大多數企業最後都不會只使用一個 AI vendor。
員工可能同時使用 public chatbot、enterprise copilot、coding agent、自動化平台與內部 Agent。模型本身也更新得非常快，同一個 Agent 還可能在多個模型之間 routing。
F5 將 AI Security Platform 定位為 model-agnostic，希望在公有與私有模型之間維持一致政策。如果它能涵蓋企業實際使用的工具，這解決的是一個很真實的問題：security team 不想每換一個 AI model 就重做整套控制。
這也是 network-level 與 identity-linked visibility 有戰略價值的原因。上層模型與 Agent interface 可以快速更換，但底層治理層可以保持相對穩定。
對 coding agent 意味著什麼
Coding 是目前 Agent 權限擴張最快的場景之一。
現代 coding agents 可以：
- 讀取整個 repository
- 執行 terminal commands
- 安裝 packages
- 存取 MCP servers
- 建立 pull request
- 呼叫部署或 issue-tracking 工具
- 使用 local 或 enterprise environment 提供的 credentials
大家最容易問的是：哪個 coding agent 最聰明、最快、最自主？
但企業真正需要同步問另一個問題：
這個 Agent 到底能碰到什麼？我們能不能證明它一直待在授權範圍內？
真正成熟的企業設計，應該把 tool permission、network access 與 credential scope 明確寫在系統控制層，而不是只把政策塞進模型的 prompt。
誰最值得關注
Security 與 platform team
Workforce AI Security 直接瞄準正在盤點 shadow AI、管理模型存取、以及希望不用額外部署 endpoint client 就能增加 Agent 可視性的團隊。
正在導入 coding agent 的企業
如果工程師已經讓 Agent 存取 terminal、repository 或 MCP，那麼 tool-call governance 已經屬於 developer security，而不再只是一份 AI policy 文件。
Automation 與 operations team
當 AI workflow 能直接修改系統，而不只是做摘要時，pre-execution policy layer 的價值會快速上升。
同時使用多個 AI vendor 的 CIO
當 AI stack 變化速度快過 security architecture 時，一個相對 model-agnostic 的 control plane 會變得很有吸引力。
TowCue 建議的企業 Agent 控制模型
可以把 Agent action 粗分成四級：
Level 1 — Read-only、容易復原
搜尋、摘要、讀 log、查 documentation。通常可以高度自動化，但要完整記錄。
Level 2 — 低 blast radius 的內部寫入
建立 draft、更新非關鍵 ticket、修改 sandbox resource。可以在 scoped identity 與 policy 下允許自動執行。
Level 3 — 對外或會改變 production 的動作
寄客戶訊息、merge code、改 production infrastructure、修改重要資料。需要 deterministic policy check，必要時加人工批准。
Level 4 — 金融、破壞性或 credential-sensitive 動作
付款、刪除、secret、帳號變更與高影響 production 操作，應該在模型外有硬性限制與強人工授權。
真正的錯誤不是「Agent 太自主」，而是把所有 action 都當成同一種風險。好的 Agent governance 會依照 blast radius 決定控制強度。
TowCue 看法
F5 Workforce AI Security 值得關注，因為它清楚反映了企業 AI 正在進入下一階段。
第一個治理問題是 shadow AI：員工偷偷使用未核准 chatbot，並把資料送出去。
下一個治理問題會是 shadow agency：Agent 在沒有被充分盤點與限制的情況下，悄悄獲得 tool、credential 與系統權限，然後開始替人執行工作。
企業當然仍然需要 model policy 與 data loss prevention，但只要 AI 開始真的「做事」，這些就不夠了。
更耐用的架構其實與傳統 security 原則非常接近：
identity + least privilege + network controls + policy enforcement + audit logs + high-impact approval。
AI Agent 並沒有讓這些原則過時，反而讓它們變得更重要。
真正可信的 Agent stack，未必是模型最自主的那一套，而可能是：明天即使把模型換掉，Agent 能做什麼、不能做什麼的邊界仍然不變。
Research sources
- F5 — Workforce AI Security（2026 年 9 月 9 日查閱）
- F5 — AI Security Platform（2026 年 9 月 9 日查閱）
- F5 — Workforce AI Security announcement via Business Wire（2026 年 9 月 9 日）