WhatsApp 如何在不破壞端對端加密的前提下打造 Scam Alert 詐騙警示
Engineering at Meta · 2026-08-12
原本的問題
WhatsApp 用戶持續面對假冒身分、社交工程與 AI 生成話術等詐騙訊息，但整個平台採用端對端加密，Meta 伺服器端本身看不到訊息內容，因此無法用傳統的伺服器端內容掃描來偵測詐騙。核心限制是任何偵測機制都不能要求把訊息內容送出裝置，否則就等於在加密上開後門。這篇 Engineering at Meta 文章說明 WhatsApp 團隊如何在這個限制下打造新功能 Scam Alert。
採用的方法
Scam Alert 用一個下載到裝置端的機器學習模型，針對非聯絡人傳來的訊息分析對話結構與語言特徵，比對已回報詐騙訊息學到的模式。整個分類過程都在裝置本機完成，訊息內容不會離開裝置，也不會自動回報給 WhatsApp 或 Meta，使用者必須主動選擇才會送出報告。功能設計遵守三個原則：
- 僅裝置端運算，模型與訊息資料都留在本機
- 不自動回報，警示只顯示給使用者本人
- 使用者可完全控制，能關閉功能，也能把某聊天標記為信任以停止未來警示
為了取得系統整體有效性數據又不侵犯隱私，團隊建了一套機密聯合分析（confidential federated analytics）管線，跑在 TEE（Trusted Execution Environment）的機密虛擬機上，只彙總兩種指標：警示出現次數與使用者後續動作（封鎖、回報或信任）。資料在到達 Meta 伺服器前，會先加上差分隱私（differential privacy）雜訊，並透過裝置與 TEE 之間的端對端加密、用 OHTTP relay 去除 IP 位址、匿名憑證取代裝置識別碼、以及 k-anonymity 門檻，防止任何單一使用者的行為被還原。此架構延伸自團隊先前發表的 PAPAYA 聯合分析論文（USENIX NSDI 2025）。
為防止模型本身被竄改或被塞入監控用途，每次模型發布都會對權重、tokenizer 與相關資產算出 SHA-256 雜湊、寫成 manifest，再由第三方 Cloudflare（而非 Meta）持有的 Ed25519 金鑰簽署，發布到一份公開、僅能附加寫入的透明日誌（transparency ledger）。裝置端會驗證這個簽章、比對日誌內容，並確認 manifest 沒有被重放後才允許模型執行。使用者也能在 帳戶 > 請求資訊中查看「Scam Alert 活動」，包括哪些訊息被標記、模型版本與後續動作；Meta Bug Bounty 計畫也擴大範圍，讓外部研究者能檢視模型權重，確認其僅用於偵測詐騙。
實際效果
Scam Alert 目前僅以有限 Beta 形式上線，WhatsApp 表示會持續與安全研究社群一起做壓力測試，再決定擴大範圍。文章沒有公布任何偵測率或誤判率數字，重點放在架構如何同時滿足端對端加密與可驗證性兩個看似衝突的目標。
原始來源：Engineering at Meta
NuGet 將 API 金鑰效期砍到 30 天，力推 Trusted Publishing 取代長效憑證
.NET Blog (Microsoft) · 2026-08-03
核心改動
NuGet 團隊在文章中舉出先前 NX Console 事件為例：一組被偷走的 API 金鑰，在 36 分鐘內就讓惡意套件散布到約 6,000 次安裝，凸顯長效金鑰一旦洩漏，攻擊者可利用的時間窗口有多長。API 金鑰本質上就是發布套件用的密碼，過去 NuGet.org 允許使用者建立效期長達一年的金鑰，一旦洩漏且未被察覺，攻擊者就能長期冒用身分推送惡意版本。
因此 NuGet.org 從 2026-08-17 起，新建立的 API 金鑰效期上限降為 30 天，原本可選的 365 天效期選項直接移除。所有在這個日期之前建立的既有金鑰，會在 2026-11-01 統一強制失效，不論原本設定的效期還剩多久。
| 項目 | 2026-08-17 前 | 2026-08-17 起 |
|---|---|---|
| 可選金鑰效期上限 | 365 天 | 30 天 |
| 既有金鑰處理方式 | 依原效期使用 | 2026-11-01 全數強制失效 |
| 建議發布方式 | 長效 API 金鑰 | Trusted Publishing（OIDC） |
影響範圍
除了縮短效期，NuGet 同步推廣去年九月上線的 Trusted Publishing 機制：CI/CD workflow 透過 OIDC 向 NuGet.org 認證身分，NuGet.org 驗證該 token 是否符合預先設定的發布政策後，才為這次發布動作單獨核發一支短命、單次用途的 API 金鑰，平台端不需要再儲存任何長效密碼。目前 Trusted Publishing 支援 GitHub Actions 與 GitLab CI/CD 兩種環境，設定方式可參考 Trusted Publishing 官方文件。
對套件維護者而言，實際影響是：如果目前用的是舊制長效金鑰，必須在 2026-11-01 前主動改用效期 30 天內的新金鑰，或整套改接 Trusted Publishing，否則既有金鑰失效後 CI 發布流程會直接中斷。這也代表往後例行的套件發布會被迫加入定期輪替金鑰的維運動作，除非團隊改用 Trusted Publishing 免去這道手續。
Azure DevOps Remote MCP Server 正式 GA：免安裝、走 Entra ID 讓 AI 助手直接操作 ADO
Azure DevOps Blog (Microsoft) · 2026-08-05
核心改動
MCP（Model Context Protocol）是一套讓 AI 助手能以標準化方式呼叫外部工具與系統的協定。Microsoft 在 2026 年 8 月 5 日宣布 Azure DevOps Remote MCP Server 正式 GA，讓 AI 助手能直接、有權限控管地存取 Azure DevOps 專案來規劃、建置與交付軟體。與過去需要本機安裝 Node.js、以 stdio 傳輸執行 npx @azure-devops/mcp 的本機伺服器不同，Remote MCP Server 是由 Azure DevOps 端代管的服務，走 streamable HTTP 傳輸，端點固定在 https://mcp.dev.azure.com/{organization}，不需要在本機跑任何程序。
{
"servers": {
"ado-remote-mcp": {
"url": "https://mcp.dev.azure.com/{organization}",
"type": "http"
}
}
}驗證機制走 Microsoft Entra ID 的 OAuth 流程，要求該 Azure DevOps 組織必須綁定 Entra 租戶，單純以 Microsoft 個人帳號（MSA）建立的組織不支援連上 Remote MCP Server。可用工具範圍能用 HTTP header 動態限縮，例如 X-MCP-Toolsets 指定只開放 repos、wit、pipelines、wiki、work、testplan、advsec 等分類，X-MCP-Readonly: true 可整體鎖成唯讀，X-MCP-Tools 則能精確指定個別工具名稱。
影響範圍
目前確定支援 Remote MCP Server 的用戶端包含 VS Code（搭配 GitHub Copilot）、Visual Studio、Microsoft Foundry、新加入的 Microsoft Copilot Studio，以及 GitHub Copilot CLI 與 GitHub Copilot app。Claude Desktop、Claude Code、Cursor 與 Codex 目前還無法使用 Remote MCP Server，原因是這些用戶端需要在 Microsoft Entra ID 上做動態 OAuth 用戶端註冊或 Client ID Metadata Document，而 Entra ID 尚未支援這個流程；這些用戶端必須改用需要 Node.js 20 以上、以 PAT 或 Entra ID 認證的本機 MCP Server（azure-devops-mcp）。
另外還有一組 Enterprise Live Migration（ELM）工具集，目前屬於私有預覽，預設不開放，需要組織先取得 ELM 私有預覽資格，並用 X-MCP-Toolsets: elm 明確開啟才會出現在工具清單中。整體來看，GA 版本把工具依 core、work、repos、wit、pipelines、wiki、testplan、advsec 等領域分組，每個工具再細分讀取與寫入動作，方便管理者用 header 做最小權限設定。
原始來源：Azure DevOps Blog、Remote MCP Server 官方文件、azure-devops-mcp GitHub