而家成日講 AI Agent 幫手做嘢，但有一樣嘢好多人忽略：當一堆 Agent 互相呼叫、又去揦數據庫、揦 API，點樣確認「嘢係邊個做嘅」？傳統做法係成組個件 share API key，或者將 OAuth token 喺 Agent 鏈上逐個 pass 落去，呢啲對企業級「零信任」嚟講，根本唔夠。

呢個缺口，正正落喺 MCP（Model Context Protocol，代理同外部工具、數據源通訊嘅協議）上面。MCP 本身由設計就唔包含認證標準，係 transport-agnostic，即管幾種傳輸方式都無強制身份驗證。後果好直接：任何部件都扮到 Agent、replay（重放）被截嘅憑證、或者未經授權就呼叫工具。

2026 年 10 月 20 日，AWS Machine Learning Blog 同 Keyfactor 放出一套參考架構，用 X.509 PKI（公開金鑰基礎設施，即「發數位身分證」嗰套加密機制）同 AWS 服務組合，為多 Agent 系統做加密身份。

四大安全機制

呢套架構用四樣互補嘅機制兜住：

  1. Signed request envelopes：每個 Agent 呼叫都要有加密「持有證明」（proof-of-possession），證明個請求真係由個 Agent 發出。
  2. User-signed delegation assertions：用户簽名嘅「授權委派聲明」，令 Agent 可以代表用户行事，而唔使用户共享憑證。
  3. RFC 8693 audience-scoped tokens：限縮每個 token 嘅「受眾範圍」，就算某個 token 洩漏，暴露面都有限。
  4. Real-time OCSP revocation checking：即時查驗證書有冇被吊銷，任何憑證變動即刻推播到所有 Agent，唔使等批次更新。

點組合

整套解決方案用 Amazon Bedrock 做 LLM（大型語言模型）推論，經 AWS Strands Agents SDK；被保護嘅資源喺示例入面係數據庫，但作者指同一認證模式適用任何 MCP-compatible 工具伺服器。EJBCA Enterprise 係 Keyfactor 嘅 CA（Certificate Authority，證書權威）平台，提供 X.509 證書簽發、OCSP 驗證、CRL（Certificate Revocation List，吊銷清單）發佈同證書生命週期管理，可以部署喺本機、容器或 Amazon EC2。

Keyfactor 稱 EJBCA 平台喺全球有超過 1,500 個企業客户，涵蓋金融、醫療、製造同政府。完整代碼喺隨文嘅 GitHub repository。

阿調搞兩下

呢個係 AWS 同 Keyfactor 嘅廠商參考架構，唔係本站實測，冇獨立安全研究驗證過呢四套機制喺實際攻擊下嘅效果。對正在用 MCP 接工具嘅開發者嚟講，呢個係一個可參考嘅起點——但要留意，「有」參考架構同「實際部署後抵唔抵用」係兩回事。值得問嘅問題：呢四樣機制邊樣先係真正必需？部署成本幾高？同現有 IAM（身份訪問管理）點整合？呢啲都係文章冇答嘅嘢。

阿調｜深度調教