Cloudflare OS 上線：三個機制織成的 Agent 存取安全網
blog.cloudflare.com · 2026-08-05
Cloudflare 於 2026-08-05 發布 Cloudflare OS，一個讓組織內非工程背景員工也能建立 agent 應用、自動化工作流程、並存取內部系統的平台。同一天，Cloudflare 也一併公開了背後三份技術規格：Agent Access Model、WriteGuard 私有 beta，以及身分感知的 AI Gateway。四篇文章合起來描述的是同一件事——當agent 開始像人類一樣操作內部系統時，原本為人類設計的 Zero Trust 控制要如何重新設計。
原本的問題
Cloudflare 在 Agent Access Model 一文中直言，為人類設計的存取控制對 agent 是「悄悄失敗」的：agent 以機器速度運作、任務生命週期短暫，且可能在人類介入前就把資料外洩出去。同一組 IAM 規則套在 agent 身上，往往變成授權過寬、事件可視度太低、信任時間又拉得太長。WriteGuard 一文則舉了具體場景：一個指示過寬的 agent 曾以極快速度連續關閉數千張工單，下游系統根本無法區分這是 agent 動作還是人類動作。
採用的方法
Cloudflare OS 的核心原則是不信任整段任務執行過程，只信任每一個被單獨驗證過的動作。Agent Identity Broker 用 OAuth 2.0 Token Exchange (RFC 8693) 加上 DPoP (RFC 9449) 簽發任務綁定、發送端綁定（sender-constrained）的短效憑證，效期以分鐘計而非數小時；即使憑證被竊，沒有對應的 proof key 也無法重放。每個動作都由 Task-Scoped Access Engine 依「agent 身分、請求動作、當前資源、任務剩餘容量」重新評估，任務範圍在派發當下就寫死，不接受執行期協商。系統內建 Trust Ratchet：一旦讀到受保護資料，容量只會被收緊、不會再放寬，且要等所有 enforcement 端點都確認狀態變更才放行回應。
寫入層面則由 WriteGuard 負責。Cloudflare 內部的 MCP Portal 目前串接 27 個 MCP server，WriteGuard 是插在 agent 與這些 server 之間的共用 policy 與稽核層，依風險把工具分四級：
- Read Only：記錄後直接放行，例如查詢 issue、檢視 pipeline
- Minimal Impact：記錄後放行，例如加 reaction、標記通知已讀
- Contained Write：放行但加註 agent 身分標籤，例如留言、建立 merge request
- Critical：預設直接擋下，例如正式環境部署、批次刪除
設定方式是在工具定義上掛 riskLevel：
const sendEmailTool = {
tool: EmailMCP.sendEmailTool,
writeGuard: {
riskLevel: RiskLevel.CONTAINED_WRITE,
enabled: true,
labeling: { field: "body", supportedFormats: [LabelFormat.PLAIN_TEXT, LabelFormat.HTML] },
},
};第三個機制是身分感知的 AI Gateway：企業把自訂網域接上 Cloudflare Access，用 Okta、Entra 等 SAML IdP 驗證後，每個進到 AI Gateway 的請求都會帶上 cf.user_id，取代原本共用 API key 的匿名存取。管理者可以為每個使用者設定獨立花費上限，User Insights 功能會拿每個 session 成本對照該帳號過去 30 天的 95th percentile 基準，超過 2 倍且同時超過全帳號 99th percentile 才觸發異常警示。
實際效果
Cloudflare OS 本身（Agent Workspace、Dynamic Workers、Durable Object Facets、Cap'n Web RPC 組成的 app 平台）與身分感知 AI Gateway 已經公開可用，WriteGuard 目前僅開放私有 beta報名。Cloudflare 也坦承 Agent Access Model 還留著一個沒解決的問題：當同一個 agent 服務多個權限不同的使用者時（例如 Bob 問到只有 Alice 能看的資料），現有系統在模擬企業工作流程測試中量到的隱私外洩率介於 15.8% 到 50.9% 之間，官方原話是「我們還不敢說多人存取控制今天已經能被端到端建成」。
原始來源：Cloudflare OS、The Agent Access Model、MCP Portal WriteGuard Private Beta、Identity-aware AI Gateway
從使用者序列到規模定律：Meta 廣告排序的多階段架構重整
engineering.fb.com · 2026-08-05
Meta 工程團隊在 2026-08-05 發布文章，說明如何用兩階段架構處理長達數千筆事件的使用者行為序列，並在廣告排序系統上觀察到與大型語言模型類似的 scaling law。這是 Meta 廣告基礎模型 GEM 系列研究的最新一份技術細節。
原本的問題
Meta 的廣告排序系統必須在毫秒等級內，從每秒數百萬則候選廣告中篩出要顯示給使用者的廣告。傳統作法把手工特徵工程與序列模型硬湊在一起，元件之間的知識轉移是有損的（lossy knowledge transfer），也很難單獨放大序列模型而不牽動其他部分，很快就撞到規模天花板。
採用的方法
Meta 把架構拆成兩段：Offline User Model 非同步處理長度上千筆事件的使用者行為序列（點擊、瀏覽、購買），用深度 transformer 產生跟特定廣告無關、可快取的使用者表示；Online Ranking Model 再把這份快取表示與即時廣告候選訊號結合做最終排序，滿足線上延遲限制。團隊發現「序列多樣性勝過序列同質性」——混合多種行為類型的序列，比全是高訊號行為的序列產生更好的表示。核心技術是 dense tokenization 與 target-aware 多頭注意力機制，寫成論文 LLaTTE（LLM-Style Latent Transformers for Temporal Events），作為 Meta 廣告基礎模型 GEM（Generative Ads Recommendation Model）的核心元件。
實際效果
團隊觀察到 FLOPs 與 normalized entropy 之間呈現對數線性關係，形態上類似 LLM 的 scaling law，並歸納出四個可調的規模槓桿：模型形狀平衡、多階段可調性、序列組成、語意特徵表示。上線後 Instagram 轉換率提升 6%，Facebook 提升 3%，廣告點擊率提升 3.5%。
Azure DevOps Remote MCP Server 正式 GA：免自架的雲端 MCP 端點
devblogs.microsoft.com · 2026-08-05
Microsoft 於 2026-08-05 宣布 Azure DevOps Remote MCP Server 正式進入 GA 階段，讓 AI 助理不必再自架 local MCP Server，就能直接存取 Azure DevOps 的 work item、PR、repo 與 pipeline。此服務由 Azure DevOps 平台直接代管執行。
原本的問題
要讓 AI 助理存取 Azure DevOps 的 work item、PR、repo 與 pipeline，過去只能自己安裝並維運一份local MCP Server，維護與更新成本落在每個團隊自己身上。
採用的方法
連線走 streamable HTTP transport，認證交給 Microsoft Entra，端點格式固定為 https://mcp.dev.azure.com/{organization}：
{
"servers": {
"ado-remote-mcp": {
"url": "https://mcp.dev.azure.com/{organization}",
"type": "http"
}
},
"inputs": []
}此服務僅支援由 Microsoft Entra 租戶支撐的組織，獨立 MSA 帳號不在支援範圍內。功能上與開源的 local 版本（microsoft/azure-devops-mcp）維持對等，兩者都能存取 work item、PR、repo、pipeline。
實際效果
目前已驗證可用的客戶端包含 VS Code + GitHub Copilot、Microsoft Foundry、新版 Microsoft Copilot Studio、Visual Studio 與 GitHub Copilot CLI；更廣泛的第三方客戶端支援，仍要等 Microsoft Entra 開放 OAuth client 註冊能力後才會跟進。