Signed Agent Cards：基於 JWS 防範智慧體名片偽造與投毒

為什麼未簽名名片存在安全隱患

在 A2A 協定官方規範 中，智慧體的能力探索被設計為輕量、靜態且無需憑證的模式：客戶端智慧體只需對目標網域的 /.well-known/agent.json 發起標準 HTTP GET 請求。

儘管這項特性大幅促進了多智慧體生態的快速擴張，但在企業級安全攻防中，它也暴露了被稱作 Agent Card Poisoning（智慧體名片投毒） 的嚴峻風險：

1. 介面端點重新導向：攻擊者若攻破 DNS 解析或邊緣反向代理，即可竄改 supportedInterfaces[].url 欄位，神不知鬼不覺地將包含敏感上下文的 Prompt 資料轉發至監聽或偽造的鏡像伺服器。
2. 能力與 Prompt 惡意注入：透過竄改 skills 技能陣列或 description 描述，攻擊者可以誤導主控智慧體，將涉及金融交易或高權限的業務委派給未經審查的惡意模型。
3. 身分偽冒詐欺：缺乏加密簽章背書時，任何人都可以自行部署名片並在 provider.organization 中宣稱自己是知名金融機構或頂尖軟體供應商。

為了保障多智慧體網路免受此類威脅，由 a2aproject/A2A 官方程式碼庫維護的 v1.0 規範基於 RFC 7515: JSON Web Signature (JWS) 正式落地了 signatures 簽章陣列機制。

signatures 陣列的結構剖析

在 A2A v1.0 Agent Card 中，最外層屬性 signatures 包含一個簽章物件陣列。這種設計支援由多個主體聯合簽署——例如，開發智慧體的軟體廠商簽署，以及為該智慧體執行合規審查的第三方安全認證機構簽署。

陣列中的每個物件均符合標準 JWS Flattened 序列化或 Compact 緊湊格式：

{
  "name": "Treasury Reconciliation Agent",
  "version": "1.2.0",
  "supportedInterfaces": [
    {
      "url": "https://agents.acme-finance.com/a2a/v1",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "signatures": [
    {
      "protected": "eyJhbGciOiJFUzI1NiIsImtpZCI6IjIwMjYtMDktY29yZSIsInR5cCI6IkpXUyJ9",
      "signature": "MEQCIFz8fV9Q2b6HqVqYx3...7k1vU8X3g"
    }
  ]
}

每個簽章物件內的欄位作用如下：

• protected：以 Base64URL 編碼的 JSON 字串，包含 JWS 標頭參數：
  • alg：所使用的密碼學演算法（如 ES256 或 RS256）。
  • kid：金鑰識別碼，解析至託管在提供商受信任金鑰庫中的公開驗證金鑰。
  • crit：（選填）關鍵標頭擴充陣列，驗證端智慧體必須強制識別。
• signature：針對規範化負載與受保護標頭計算得出的 Base64URL 編碼數位簽章。

使用 ES256 為 agent.json 產生簽章

要為 Agent Card 簽名，文件負載必須進行確定性的規範化處理（在簽名之前移除任何既有的 signatures 欄位），以保證在不同程式語言與執行環境中產生一致的雜湊值。

以下是使用標準 Web Crypto API 的 Node.js 參考實作：

import crypto from 'node:crypto';
import fs from 'node:fs';

// 1. 讀取名片並移除既有簽章以取得規範化負載
const rawCard = JSON.parse(fs.readFileSync('agent.json', 'utf8'));
const { signatures, ...unsignedPayload } = rawCard;
const payloadString = JSON.stringify(unsignedPayload);

// 2. 準備 JWS 受保護標頭
const header = {
  alg: 'ES256',
  kid: 'https://acme-finance.com/.well-known/jwks.json#key-2026',
  typ: 'JWS'
};

const base64Url = (str) => Buffer.from(str).toString('base64url');

const protectedHeaderB64 = base64Url(JSON.stringify(header));
const payloadB64 = base64Url(payloadString);
const signingInput = `${protectedHeaderB64}.${payloadB64}`;

// 3. 使用私有 EC 金鑰 (P-256) 進行簽署
const privateKeyPem = fs.readFileSync('private-key.pem', 'utf8');
const signer = crypto.createSign('SHA256');
signer.update(signingInput);
signer.end();

const signatureB64 = signer.sign(privateKeyPem, 'base64url');

// 4. 將簽章區塊附加回 Agent Card
const signedCard = {
  ...rawCard,
  signatures: [
    {
      protected: protectedHeaderB64,
      signature: signatureB64
    }
  ]
};

fs.writeFileSync('agent.signed.json', JSON.stringify(signedCard, null, 2));
console.log('✓ Agent Card 已成功使用 ES256 完成簽署');

客戶端智慧體如何驗證簽章

當客戶端智慧體從未經審查的對等方擷取 Agent Card 時，驗證必須在檢查能力或呼叫介面之前執行：

1. 擷取：從文件中解析 signatures。如果缺失，根據安全政策標記為未驗證或予以拒絕。
2. 標頭解碼：使用 base64url 解碼 protected 並檢查 alg 與 kid。拒絕不符合安全基準的演算法（例如捨棄 none 演算法或過短的不安全金鑰長度）。
3. 金鑰檢索：擷取 kid 所參照的對應公開金鑰。驗證金鑰 URL 的網域是否嚴格符合名片中宣告的 provider.url。
4. 雜湊驗證：重建未簽名的負載，計算規範化摘要，並對照公開金鑰驗證密碼學數位簽章。

金鑰輪換與安全實踐清單

在生產環境中管理 Signed Agent Cards 時，請遵循以下操作規範：

• 將金鑰生命週期與部署解耦：使用參照至 JWKS URL（/.well-known/jwks.json）的金鑰 ID（kid），而非寫死靜態金鑰，實現零停機時間的平滑金鑰輪換。
• 全端點強制 HTTPS：supportedInterfaces 下列出的每個介面與金鑰端點均必須強制使用具備有效 TLS 憑證的 HTTPS。
• 嚴格綁定網域與提供商：確保託管 Agent Card 的網域與 provider.url 及 JWKS 端點來源保持一致。
• 部署前預檢驗證：在發布至公開根目錄前，務必將完整的名片透過 驗證器 進行全面檢測。