⚖️ Vercel規約更新に学ぶ、AIエージェントへの権限委任と責任分界の設計

検証日: 2026-06-05 / 対象: Vercel 利用規約（ToS Last Updated 2026-06-01, changelog 2026-06 公開・公開日は未再検証）
読者: 実装エンジニア / SRE / プラットフォーム運用

概要

2026年6月1日付で Vercel は利用規約（Terms of Service）の Section 6「AI Functionality and Third Party Tools」 を施行し、6月4日に changelog として公開しました（changelog ページはファクトチェック時にアクセス不可だったため公開日そのものは未再検証。条文の正本は ToS 本体 Section 6, Last Updated June 1, 2026 で確認済み）。条文の核心は「AIや外部エージェントがアカウント上で起こしたことは、設定したユーザーの責任であり、コストもユーザーが負う」を規約の言葉で明文化した点にあります。

条文は次の3点を規律します。

1. AI Functionality の自律行動: ユーザーの設定が、AIがユーザーに代わって取れる自律行動の範囲を決めます。ユーザーは「設定に従ってAIが代わりに取った行動に法的に拘束されること」に同意します。
2. Third-Party Tools への権限委任: secrets / credentials / リポジトリアクセスを外部 AI ツール・エージェントに渡した場合、それらが代わりに取った行動に法的に拘束され、発生したコストの責任を負います。
3. 課金の早期化: 異常・高額・不審な利用を検知した場合、通常の請求サイクルより前に Vercel が発生済み料金を請求できます。

これらは「設定 = 委任範囲 = 責任範囲」という三位一体の構造で貫かれています。ユーザーが設定で開いた自律度の範囲が、そのままエージェントへの委任範囲となり、その結果に対する法的責任範囲となります。

この更新は業界初でも先進的でもありません。「APIキーを渡した第三者の行為・コストはユーザー責任」という条項は GitHub / AWS / Cloudflare / Anthropic など主要プラットフォームがすでに保持する業界標準です。Vercel 自身も AI Product Terms を2026年3月17日に更新済みであり（6月 ToS Section 6 と完全に同等の代理行為責任条項が3月時点で存在したかは要追加確認）、6月の変更は「既存条項の再パッケージ・AI名指し化」と読むのが正確です。

今回の変更の実質的な意味は、従来は人間や外部アプリを想定していた責任転嫁条項が、AIエージェントを定義つきで条文に組み込んだ転換点にあります。実装エンジニア / SRE / プラットフォーム運用にとっては、「設定ミス = 法的責任の発生 + 予期しない早期課金」という直接的なリスクとして読む必要があります。

特徴

特徴1: 「on your behalf（あなたに代わって）」を法的拘束の起点にした

Section 6 の核心は次の2つの条文にあります（出典: ToS）。

Where the AI Functionality is capable of taking autonomous actions ... your settings determine the level of autonomous actions the AI Functionality may take on your behalf.

You authorize and agree to be legally bound by the actions taken on your behalf by the AI Functionality in accordance with your settings.

「設定 = 委任範囲 = 責任範囲」の三位一体がここに凝縮されています。AIが暴走しても、その自律度を決めたのはユーザーの設定であり、設定範囲内の行動には法的に拘束されます。Third-Party Tools に対しても同型で、APIキーを渡した時点で「それが代わりに取った行動に拘束され、コストを負う」とみなされます。

特徴2: Vercel 免責とユーザーへの責任集約

Section 6 は Vercel を明確に免責します。

Vercel is not responsible for any loss, damage, liability or other consequence arising from actions taken on your behalf by any Third Party Tools or AI Functionality.

これは規約全体の条項と連動して、責任がユーザー側へ構造的に集約する設計になっています。

「AI機能の便益は Vercel が提供し、自律行動の結果リスクはユーザーが負う」という非対称な構造は、批判として成立する点に留意が必要です。

特徴3: 異常使用時の早期課金 — runaway agent への直接対応

Section 17.1 の条文（出典: ToS）。

If Vercel detects elevated, irregular, high or anomalous use of the Services, as determined in Vercel's sole discretion, Vercel may automatically charge your payment method for the then accrued fees in connection with the use of the Services.

changelog はこれを「Fees are no longer exclusively tied to a subscription plan」と平易に宣言しています。エージェントが大量リソースを消費した場合、Vercel は通常の請求サイクルを待たずに請求できます。しきい値の具体値は非公開で、未払いが累積すると新規デプロイと一部の課金対象機能が停止します（出典: understanding-my-invoice）。docs は「Partial invoices apply to Pro plan accounts. Hobby and Enterprise accounts are not affected.」と明記しており、partial invoice の対象は Pro プランのみ（Hobby / Enterprise は対象外）です。

特徴4: 監査はできる。ただし「誰の代理か」は記録されない

Activity Log / Audit Log でアカウント上の操作履歴は確認できます。ただし責任分界の観点で決定的な限界があります。

Audit Log の actor 列は actor_vercel_id / actor_name / actor_email と request_id / user_agent であり、CSV フィールド上は「誰の代理として（on-behalf-of）」を分離する明示フィールドが存在しません。したがってエージェントがトークンで操作した場合、人間の操作か、その人のトークンを持ったエージェントの操作かは user_agent や origin から推測するしかありません。

規約がエージェント委任の責任をユーザーに置くのに対して、監査の実装はそこに追いついていません。

他プラットフォームとの比較

「APIキーを渡した第三者の行為・コストはユーザー責任」は業界標準ですが、AIエージェントを正面から名指しした責任分界はまだ少ない状況です。

位置づけとして、AWS が「責任共有」という概念を、Anthropic が「誰の認証で・誰の財布でエージェントが動くか」を、Vercel が「設定 = 委任 = 責任の三位一体」を、それぞれ規約・課金構造で明確化しつつある段階です。Vercel の特徴は、技術プラットフォームの ToS 本体が AI / エージェントを定義つきで条文に組み込んだ点にあります。

構造

C4 model の粒度（システムコンテキスト / コンテナ / コンポーネント）を借りて、「Vercel 責任分界モデルの論理構造」を3段階で図解します。

システムコンテキスト図

アクターと外部システムが「Vercel の責任分界モデル」本体に対してどう関係するかを示します。

コンテナ図

責任分界モデルを構成する5つの論理レイヤを示します。

設定・権限レイヤ

委任レイヤ

行動レイヤ

責任・課金レイヤ

監査レイヤ

コンポーネント図

権限委任を技術設定だけで完結させず、5つの責任層を一貫させる必要があることを示します。各層に Vercel の実コンポーネントをマッピングします。

データ

概念モデル

規約と権限委任が扱うエンティティを、所有関係（subgraph）と利用関係（矢印）で表現します。

情報モデル

主要エンティティの属性と多重度を定義します。推測属性は末尾に注記しています。

属性の根拠・推測注記

構築方法

エージェントに Vercel の権限を渡す前の初期セットアップを説明します。補完コードは「実装案」として明示し、補完元を参考リンクに含めています。

エージェント用アイデンティティを人から剥がす

エージェントには、人間メンバーのアカウントに紐づいたトークンを渡さないことが原則です。Vercel が推奨する「人離れ」の手段は 2 種類あります。

OIDC トークン（VERCEL_OIDC_TOKEN）を使う

Vercel にデプロイされたワークフロー内では、環境変数 VERCEL_OIDC_TOKEN が自動的に挿入されます。鍵管理・ローテーション・失効が不要で、デプロイ実行コンテキストに紐づく短命トークンです。

# Vercel デプロイ内のスクリプト例
# VERCEL_OIDC_TOKEN は Vercel ランタイムが自動注入する(手動設定不要)
curl -H "Authorization: Bearer ${VERCEL_OIDC_TOKEN}" \
  https://api.vercel.com/v9/projects

• AI Gateway でも同じトークンを認証に使えます（AI_GATEWAY_API_KEY の代替）。
• チームメンバーが退場しても失効しません（人依存の API key とは異なります）。
• Vercel 外部から呼び出すエージェント（CI/CD など）には後述の team-scoped PAT を使います。

team-scoped + expiresAt 付き Access Token を発行する

Vercel の REST API でトークンを発行します。teamId を指定することでスコープを特定チームに限定し、expiresAt で有効期限を設定できます。

# POST /v3/user/tokens — team-scoped PAT を発行する例（実装案）
# 参考: https://vercel.com/docs/rest-api/authentication/create-an-auth-token
curl -X POST "https://api.vercel.com/v3/user/tokens?teamId=${TARGET_TEAM_ID}" \
  -H "Authorization: Bearer ${VERCEL_PERSONAL_TOKEN}" \
  -H "Content-Type: application/json" \
  -d "{\"name\": \"agent-ci-deploy-$(date +%Y%m%d)\", \"expiresAt\": $(python3 -c 'import time; print(int((time.time() + 86400 * 90) * 1000))')}"

レスポンスに含まれる主要フィールドは以下のとおりです。

レスポンスは { bearerToken: string, token: { ... } } の構造で、bearerToken だけがトップレベル、その他は token オブジェクト内にネストされます。

bearerToken は作成レスポンスの一度きりしか取得できません。必ず安全な Secret Manager に保存してください。

最小権限の付与

Team / Project ロールの選択

エージェントの team-level ロールは、職責の最小単位に合わせて選びます。

• Viewer という単一ロールは存在せず、Pro Viewer（Pro）と Enterprise Viewer（Enterprise）の2ロールに分かれます。
• project level roles の提供範囲、および Developer / Security / Contributor のプラン別可否は docs にゲート表記が明示されていないため要確認です（Billing ロールのみ「Pro は1名・Enterprise は複数」と明記）。
• team owner / member のロールはエージェントには付与しないことを推奨します（最高権限のため）。

Contributor + Access Group で最小プロジェクトスコープを絞る

Access Group を使うと、プロジェクト横断で project-level ロールをグループ管理できます。

Team Settings > Access Groups > 新規グループ作成
  → 対象プロジェクトを選択
  → エージェントの Contributor メンバーを追加
  → Project Developer または Project Viewer を割り当て

• Access Group は project role のみを管理します（team role の上書きはできません）。
• 複数グループに所属する場合は最大権限が採用されます。
• Access Group のプラン要件は本文に明記がありませんが、依存する Directory Sync や project RBAC は Enterprise 系の機能です（要確認）。

Permission Groups で粒度を追加する

team role に上乗せする形で、以下の permission group を付与できます。

Deployment Protection の Bypass Secret を発行する

AI エージェント・CI/CD・MCP サーバーはブラウザチャレンジを通過できないため、保護されたデプロイにアクセスするには Bypass Secret が必要です。

# Vercel ダッシュボード操作（CLI での直接発行は要確認）
# Project Settings > Deployment Protection > Protection Bypass for Automation
# → "Add Secret" で新しい secret を生成
# → 環境変数名: VERCEL_AUTOMATION_BYPASS_SECRET

Bypass Secret をリクエストヘッダーに付与する方法は以下のとおりです。

curl -H "x-vercel-protection-bypass: ${VERCEL_AUTOMATION_BYPASS_SECRET}" \
  https://your-preview-deployment.vercel.app/api/health

• プロジェクトごとに複数の secret を発行でき、個別に失効させることができます。
• システム（CI/エージェント）ごとに 1 secret を使い分けることを推奨します。
• Bypass Secret は全プランで利用できます。
• Deployment Protection Exceptions（特定 preview ドメインを公開する方式）は Enterprise または Pro + Advanced Deployment Protection アドオンが必要です。

前提条件・対象プランの整理

利用方法

委任トークンの作成・スコープ確認・失効

必須パラメータ一覧

作成・確認・失効

# 作成: team-scoped PAT を発行する（90日有効の例）
curl -X POST "https://api.vercel.com/v3/user/tokens?teamId=${TARGET_TEAM_ID}" \
  -H "Authorization: Bearer ${VERCEL_PERSONAL_TOKEN}" \
  -H "Content-Type: application/json" \
  -d "{\"name\": \"agent-$(date +%Y%m%d)\", \"expiresAt\": $(python3 -c 'import time; print(int((time.time() + 86400 * 90) * 1000))')}"

# スコープ確認: トークン一覧の scopes と activeAt を確認する
curl https://api.vercel.com/v3/user/tokens \
  -H "Authorization: Bearer ${VERCEL_PERSONAL_TOKEN}"

# 失効(個別): 特定トークンを失効させる
curl -X DELETE "https://api.vercel.com/v3/user/tokens/${TOKEN_ID}" \
  -H "Authorization: Bearer ${VERCEL_PERSONAL_TOKEN}"

• leakedAt / leakedUrl が設定されているトークンは漏洩検知済みのため、直ちに失効させてください。
• チームメンバーが退場した場合、そのメンバーが作成した AI Gateway API Key は Vercel が自動失効させます。ただし PAT は自動失効しないため、退場時の手動失効または有効期限設定が必要です（要確認）。

Activity Log の確認

Activity Log は全プランで利用でき、team 作成以降の全イベントを時系列で記録します。CLI からは vercel activity で確認できます。

docs の Events 一覧に Active として掲載されているエージェント・トークン系のイベント種別には、user-token-created / user-token-deleted / user-tokens-deleted、oauth-app-token-created / vercel-app-tokens-revoked、ai-gateway-api-key-created / -deleted / -quota-updated、ai-gateway-byok-credential-*、ai-code-review / ai-alert-investigation、ai-omniagent（Vercel Agent 設定）、agentic-provisioning-account-blocked / -linked / -relinked / -unlinked / -credentials-rotated / -plan-changed / -team-created（7種）などがあります。一覧は今後更新されうるため、最新は docs を参照してください。

• Activity Log は外部サービスへの送出を行いません。
• 保持期間の数値は公式ドキュメントに明記がありません（「team 作成以降の全件」と記載）。

Audit Log の CSV Export / SIEM Streaming（Enterprise のみ）

Audit Log は Enterprise プラン限定で、閲覧は Owner ロールのみです。

Team Settings > Security & Privacy > Audit Log
  → タイムフレームを選択
  → "Export CSV" をクリック
  → レポートリンクが Owner のメールアドレスに送付される（リンク有効期限: 24 時間）

• 直近 90 日分のレポート生成は billing impact なしとされます。90 日超の長期保持については公式ドキュメントに明示がありません（要確認）。
• CSV の各レコードは timestamp / action / actor_vercel_id / actor_name / actor_email / location / user_agent / request_id / previous / next の10フィールドで構成されます。

SIEM Streaming（Custom SIEM Log Streaming）は Enterprise の別途購入で、AWS S3 / Splunk / Datadog / Google Cloud Storage / 任意の HTTP エンドポイント（custom header 認証、NDJSON または JSON 配列）へ常時送出できます。

act クレームでの代理記録（アプリ層での実装案）

Vercel の Audit Log / Activity Log の actor モデルは単一の actor フィールド（actor_vercel_id / actor_name / actor_email）で構成されています。エージェントがユーザーのトークンを使って操作した場合、そのトークン所有者が actor として記録されます。「人間の代理としてどのエージェントが実行したか」を分離する明示フィールドは Vercel のログには存在しません（公式ドキュメントに記述なし）。

この制約を補うために、RFC 8693（OAuth 2.0 Token Exchange）の act クレームをアプリ層で実装する方法を以下に示します。

# 実装案: エージェント操作の act クレームをアプリ層で記録する（補完コード）
# 参考: RFC 8693 https://datatracker.ietf.org/doc/html/rfc8693
import json, time, hmac, hashlib, base64

def create_act_record(subject_user_id, agent_id, action, vercel_request_id, secret_key):
    """RFC 8693 の act クレームに相当するレコードを生成する実装案。
    Vercel の audit log には on-behalf-of フィールドがないため、
    アプリ層でこのレコードを別途保存して代理操作の証跡とする。"""
    record = {
        "iat": int(time.time()),
        "sub": subject_user_id,          # 委任元(人間ユーザー)
        "act": {"sub": agent_id},        # 実行エージェントのアイデンティティ
        "action": action,
        "vercel_request_id": vercel_request_id,  # Vercel のログと突き合わせるキー
    }
    payload = json.dumps(record, sort_keys=True).encode()
    sig = hmac.new(secret_key, payload, hashlib.sha256).digest()
    record["sig"] = base64.urlsafe_b64encode(sig).decode()
    return record

• vercel_request_id を Vercel 側の Audit Log（Enterprise）の request_id と突き合わせることで、actor_* のトークン所有者と実際の実行エージェントを紐づけられます。
• act クレームは RFC 8693 Section 4.1 で定義されています。委任（delegation）はなりすまし（impersonation）と異なり、「A が B の代理として行動していることを明示した状態」を指します。
• この実装はアプリ層での補完であり、Vercel プラットフォーム側でネイティブに act クレームを記録する機能は確認されていません。

運用

エージェント委任の継続監視

• トークンの棚卸し・失効: PAT は expiresAt を必ず設定します（作成時に1日〜1年を選択可能、[二次情報: KB要約]）。定期的に REST API でトークン一覧を取得し、activeAt が古いまたは leakedAt が付いたトークンを即時 revoke します。緊急時は user-tokens-deleted（現行以外の全トークン一括削除）も使えます。
• member 離脱時の自動失効: Vercel は team member が離脱すると、その member が作成した AI Gateway API key を自動失効させます（[一次: ai-gateway/authentication-and-byok]）。人間 member に紐づかない継続的な自動化には OIDC token を使います。
• Audit Log の SIEM 連携での actor 追跡: Enterprise では Custom SIEM Log Streaming で Audit Log を常時外部送出できます。act / on-behalf-of が存在しないため、SIEM 側で user_agent の bot / automation パターン（例: Vercel-AI-SDK/*）でエージェント由来イベントをフィルタし、別ダッシュボードで監視する運用を検討します。

四半期ごとのトークン棚卸し手順

1. GET /v3/user/tokens でトークン一覧を取得する。
2. expiresAt 未設定のトークンを抽出し、用途確認の上 expiresAt を設定するか revoke する。
3. activeAt が90日以上古いトークンを revoke する(未使用トークンは潜在攻撃面)。
4. leakedAt が付いたトークンは即時 revoke し、インシデント記録を残す。

異常課金への対応

• ToS Section 17.1 により、「異常・高額・不審な利用」を Vercel が検知した場合、通常の請求サイクルより前に partial invoice として発生済み料金が自動決済されます（partial invoice の対象は Pro プランのみ。Hobby / Enterprise は対象外）。検知閾値は非公開で、Vercel の単独裁量で判断されます。
• ダッシュボードの Spend Management でアラート（soft limit）と停止（hard limit）を設定します。ただしデフォルトではハード停止は有効でなく、明示設定が必要です（[一次: pricing/manage-and-optimize-usage]）。
• Spend Management を設定していても突破される事例が報告されています[二次情報]。帯域急騰のようなスパイクには追いつかないケースがあります。
• 未払いが累積すると「新規デプロイと一部の課金対象機能が停止」します。SRE として、停止トリガーのしきい値と復旧手順（支払い完了後の機能再有効化）を事前に確認しておきます。

Spend Management 設定の推奨構成

Soft limit (ALERT):   月次予算の 70-80% でアラート発火 + webhook 通知
Hard limit (REJECT):  月次予算の 100% で新規デプロイ・課金対象機能を停止
日次ガードレール:      月次上限の 10-15% (例: $3,000/月 → 最大 $300-450/日) [二次情報]

ベストプラクティス

5層モデルに沿った委任設計

• ① アイデンティティ層: エージェントに人間の PAT を流用しません（1エージェント = 1 identity）。NIST SP 800-207 の「すべての M2M 呼び出しを明示的に認可」に従い、Vercel 上の自動化には OIDC token を優先します。長命 API key は expiresAt を最短にし、SPIFFE/SPIRE 的な短命クレデンシャル思想に近づけます。
• ② 認可層: NIST SP 800-53 AC-6 の最小権限を守り、Owner は絶対に渡しません。Access Groups は権限を「増やせるが減らせない」構造のため、複数グループ所属時は最大権限が採用される点に注意します。OWASP AI Agent Security Cheat Sheet の allowed_paths 制限（*.env / *secret* をブロック）をツール設定に反映します。
• ③ 承認・監督層: 操作をリスク階層（LOW / MEDIUM / HIGH / CRITICAL）に分類し、HIGH / CRITICAL には人間承認を必須にします。OWASP の SENSITIVE_TOOLS に Vercel 文脈の「本番デプロイ push」「本番環境変数変更」「Bypass secret 発行・削除」「quota 更新」を追加します。CSA AG-GV.1 の自律度ティアで分類し、不可逆操作は「意思決定と実行の分離」を実施します。
• ④ 監査・観測層: NIST SP 800-53 AU-10（非否認）は「個人の代理として動くプロセス」を対象とします。Vercel の Audit Log は on-behalf-of を持たないため、アプリ層で RFC 8693 act クレーム相当のメタデータ（agent_id / task_id / authorized_by / authorization_ts）を構造化ログに残します。
• ⑤ 契約・規程層: CSA AG-GV.2（監督境界フレームワーク）に沿い、委任ごとに ①authorized action scope ②escalation conditions ③sub-agent への delegation authority ④accountability lineage を文書化します。RACI では AI は Responsible/Accountable になれず、Accountable は必ず人間が持ちます。

規約・社内規程・委託契約の整合

• GDPR Art.28 DPA: AIエージェントプラットフォームが EU 在住者データを扱う場合、サービス提供者は processor に該当します。DPA に許可・禁止事項を明記し、processor 変更の通知義務と監査権を契約に盛り込みます。
• sub-processor の監査権: primary processor への監査権が、その先の sub-processor に及ばないケースが多くあります。エージェントが third-party plugin を呼ぶ場合、processor 契約と DPIA で trace-level logging と deletion API を要求します[二次情報]。
• SaaS AUP の遵守: Vercel AUP は自動システムのレート超過を禁じます。エージェントのレート設計を AUP / API ToS と突き合わせ、gateway layer でレート制限を設けます。
• EU AI Act（2026年8月全面適用）: 高リスク AI システムは「介入・上書き・停止できる effective human oversight」を備えます。ISO/IEC 42001 の AIMS を human oversight の実装基盤として使えます（ISO 42001 認証 ≠ EU AI Act 準拠）[二次情報]。

コスト暴走ガードレール

• per-session budget: 1セッションあたりのトークン上限をアプリ層で設定し、再帰ループの無制限蓄積を防ぎます。
• gateway rate limit: per-minute / per-hour のレート制限を spending limit とは独立して Gateway 層に置きます。
• ALERT/REJECT の二段: soft limit は ALERT（通知のみ）、hard limit は REJECT（HTTP 429 でブロック）として分離します。ALERT だけでは「気づいたが止まらない」状態を生むため、REJECT まで設定します。
• インフラ層 enforcement: アプリ層チェックはフォールバックに過ぎず、プロキシ/Gateway 層での enforcement が信頼性の根幹です。request 単位で spend を追跡し、予算超過前にエージェントを遮断します[二次情報]。

反証統合（誤解 → 反証 → 推奨）

トラブルシューティング

まとめ

Vercel の2026年6月の規約更新は、「AIや外部エージェントがあなたに代わって取った行動とそのコストは、設定したあなたの責任」を「設定 = 委任 = 責任」の三位一体として条文に書き込んだものです。業界初ではなく、責任転嫁条項が agentic を名指しし始めた転換点として読み、エージェントに権限を渡す前に「短命アイデンティティ・最小権限・実行前の承認点・代理を残す監査・コストの二段ガード・規約と社内規程の整合」という5層を自分のチームで設計しておくことが、設定ミス由来の法的責任と予期せぬ早期課金から身を守る現実的な備えになります。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

Vercel 一次ソース

• Terms of Service — Section 6 / 15 / 17.1 / 19 / 20.1 (Last Updated June 1, 2026)
• Updates to Legal Terms changelog (June 2026)
• AI Product Terms (March 17, 2026)
• Acceptable Use Policy (April 21, 2026)
• Activity Log docs
• Audit Log docs
• RBAC — Access Roles
• RBAC — Access Groups
• REST API — Create an Auth Token
• Sign in with Vercel — Tokens
• AI Gateway — Authentication and BYOK
• Deployment Protection — Automated Agent Access
• Pricing — Manage and Optimize Usage (Spend Management)
• Pricing — Understanding my Invoice (partial invoice)

運用設計フレームワーク（一次）

• IETF RFC 8693 — OAuth 2.0 Token Exchange (act クレーム)
• NIST SP 800-53 Rev.5 — AC-6 最小権限 / AU-10 非否認 / AU-9 改ざん耐性
• NIST SP 800-207 — Zero Trust Architecture
• OWASP AI Agent Security Cheat Sheet
• OWASP Agentic AI Top 10（2025年12月リリース、v1.0 は後続）
• CSA Agentic AI — NIST AI RMF Profile v1 (AG-GV.1 / AG-GV.2 / AG-MS.1 / AG-MG.1)
• CNCF SPIFFE / SPIRE
• AWS Shared Responsibility Model & GDPR

反証・実害事例（二次情報）

• National Law Review — Contract Law in the Age of Agentic AI
• Agentic Commerce Guide — Navigating Legal Liability for AI Agent Actions
• TechStartups — $47,000 multi-agent runaway 事例
• Tom's Hardware — Claude runaway 事例
• CloudZero — AI Cost Guardrails
• IAPP — Engineering GDPR Compliance in the Age of Agentic AI
• DEV Community — Vercel's Agentic Shift（非対称リスク批判）