Anthropic 收購 Stainless：自動 SDK 生成商成為 Claude 平台的核心基礎設施
Anthropic · 2026-05-18
Anthropic 宣布收購 Stainless，一家自 2022 年起為 Anthropic 生成所有官方 SDK 的工具平台。Stainless 的核心能力是從 API 規格自動生成 TypeScript、Python、Go、Java 等語言的原生 SDK、CLI 工具與 MCP server connector。收購完成後，Stainless 團隊將加入 Anthropic，共同推進 Claude Platform 的開發者工具與代理連線能力。
Stainless 做什麼
Stainless 的核心產品是一個 SDK 與 MCP server 的自動生成平台：給定一份 OpenAPI 或自訂 API 規格，Stainless 可以生成符合各語言慣例的 SDK，包含分頁處理、錯誤重試、類型安全包裝等細節。目前數百家公司依賴 Stainless 生成自己的 SDK 與 CLI，Anthropic 的官方 Python SDK、TypeScript SDK 均由 Stainless 生成。
收購的戰略動機出自 Anthropic Platform Engineering 負責人 Katelyn Lesse 的說明：「代理的價值取決於它能連接什麼。」隨著 MCP（Model Context Protocol）成為代理工具連線的主要標準，能自動生成 MCP server 的工具在整個生態系中的地位急速上升。
技術整合方向
Stainless 的 MCP server 生成能力與 Anthropic 的 MCP 標準高度互補。目前開發者若要讓自己的服務支援 Claude 代理，需要手動實作 MCP server；Stainless 的自動生成工具理論上可以讓這個過程從「數週工程工作」縮短到「給定 API spec 自動生成」。收購公告未透露具體整合時間表，但 CEO Alex Rattray 表示「合並兩個團隊是顯而易見的決定」。
影響範圍
對 API 提供商而言，這次收購可能改變「支援 AI 代理接入」的標準工作流程。若 Anthropic 將 Stainless 的能力整合進 Claude Platform，API 服務接入 Claude 生態的摩擦將大幅降低。現有 Stainless 客戶的服務目前不受影響，但中長期的平台演進值得關注。
原始來源：Anthropic
.de TLD DNSSEC 金鑰輪換失誤：數百萬網域瞬間失效的技術解析
Cloudflare Blog · 2026-05-06
2026 年 5 月 5 日 19:30 UTC，德國域名管理機構 DENIC 在例行金鑰輪換（key rollover）過程中發布了無效的 DNSSEC 簽章，導致所有驗證解析器必須依 DNSSEC 規範回傳 SERVFAIL。.de 是全球查詢量最大的國家頂級域名之一，數百萬個 .de 網域在修復前對驗證解析器完全不可達。Cloudflare 的 1.1.1.1 在 22:17 UTC 部署緩解措施，終止了對其用戶的影響。
漏洞機制
DNSSEC 金鑰輪換需要精確協調新舊 DNSKEY 記錄與 RRSIG 簽章的發布順序。DENIC 自身公告指出，輪換過程中生成並分發了「無法驗證的簽章」（non-validatable signatures）——簽章無法用已發布的 DNSKEY 驗證。DNSSEC 規範要求解析器在遇到驗證失敗的簽章時，必須回傳 SERVFAIL 而非 NXDOMAIN 或直接解析，這意味著所有啟用 DNSSEC 驗證的解析器都會拒絕服務這些查詢。
Serve Stale 的作用
Cloudflare 的 1.1.1.1 依照 RFC 8767 實作 Serve Stale：在上游失效時繼續提供過期的快取記錄。事件發生後，NOERROR 回應率在快取 TTL 到期前保持相對穩定，展示了 Serve Stale 在 TLD 層級故障時緩衝影響的實際效果。
緩解措施
- Negative Trust Anchor（NTA）：Cloudflare 將 .de 標記為不安全（insecure），讓查詢繞過 DNSSEC 驗證，如同 .de 從未啟用 DNSSEC
- EDE 錯誤碼修正：事後發現 1.1.1.1 原本回傳的是 EDE code 22（No Reachable Authority）而非 code 6（DNSSEC Bogus），掩蓋了真實原因；Cloudflare 承諾改善 DNSSEC 特定錯誤的傳播
影響範圍
此事件再次說明 TLD 層級的 DNSSEC 故障具有級聯效應——所有子域名同時受影響，無法像單一網站故障那樣局部隔離。全球多個解析器運營商在一小時內各自獨立部署 NTA，這種非正式協調速度值得關注。對 DNS 基礎設施設計者而言，金鑰輪換流程的自動化與驗證環境的建立是預防此類事件的關鍵。
原始來源：Cloudflare Blog
Docker AI Governance：集中管控 AI 代理的網路存取、憑證與 MCP 工具使用
Docker Blog · 2026-05-12
Docker 發布 AI Governance 功能，為在 Docker 基礎設施上運行的 AI 代理提供集中式管控平台，涵蓋代理的執行環境、網路存取範圍、憑證（credentials）管理，以及 MCP 工具的使用授權。這是 Docker 因應「AI 代理在生產環境中執行任意程式碼」這個安全挑戰所提出的系統性答案。
核心改動
AI Governance 的核心是「代理沙箱 + 政策控管」的組合：每個 AI 代理在隔離的 Docker 容器中執行，管理員可以透過集中式介面定義該代理能存取哪些網路端點、能使用哪些 MCP server、以及能取得哪些 secrets。這讓企業可以在授予代理「足夠的自主性」的同時，保留對「爆炸半徑（blast radius）」的控制。
具體管控維度包括：
- Network Policy：允許或拒絕代理的 outbound 連線（可細化到 host/port 層級）
- Credential Scoping：代理只能取得被明確授予的 secrets，不能存取容器環境中其他憑證
- MCP Tool Authorization：細粒度控制代理可以呼叫哪些 MCP server 的哪些 tool
- Audit Logging：代理的所有工具呼叫與網路請求可被記錄供審計
影響範圍
在 AI coding agent 大規模進入開發者工作流的當下，Docker AI Governance 提供了一個在不完全信任代理的前提下安全使用代理的框架。對企業 DevOps 團隊而言，這是讓 AI 代理通過安全審查的重要工具——代理的行為邊界可以被明確定義和稽核，而不是完全依賴代理本身的「自律」。
原始來源：Docker Blog