エージェント決済の濫用と、Trust 層の不在
AI エージェント決済のコールごとに、誰が・どの範囲で・いくらまで委任したかを暗号証明として添付する設計。
このページは、こんな方のために。
AI エージェントを社内業務に組み込み始め、エージェントが API 利用・クラウド資源・エージェント間決済の支払いを通すようになってきました。決済そのものは動きます。一方で、その支払いの背後にある「誰が委任したか・どこまでの範囲か」は、API キーとプロンプト側のガードレールで支えられたままです。
-
AI エージェントを自社業務に組み込み始めた組織のセキュリティ責任者
-
x402 / MCP / A2A 環境で決済を運用する開発者・運用責任者
-
エージェント駆動の行為に対する監査・統制責任を持つコンプライアンス担当
原本を渡すか、事実だけを渡すか。
エージェントの鍵・委任の中間ステップ
各支払いが認可された委任の範囲内である
Lemma は、エージェントが決済を発行する瞬間に Trust402 アテステーションを添付します。アテステーションが封じるのは、行為を委任した principal、委任の役割と範囲、コール単位の spend limit、相手側が検証する必要がある jurisdiction 属性（例：「このエージェントは JP 登録の事業者の代理である」）です。
このアテステーションは ZK 証明であり、bearer credential ではありません。エージェントは principal の鍵を持ち歩きません。受信側 — 決済コントラクト・x402 middleware・取引相手のリスクエンジン — が、principal のオンチェーン委任ポリシーに対して証明を検証してから決済を確定します。失効も同じレイヤーで伝播します。principal レベルで 1 トランザクション送れば、それに依存する全ての下流アテステーションが無効化されます。
結果として、「誰が・どの範囲で・どの jurisdiction を満たして委任したか」は、事後の再構成ではなく、決済確定の前提条件になります。
3 つの基準で、選ぶ。
「中身を出さず渡す」「独立検証」「改ざん不能」の3 つが同時に要る業務こそが Lemma の領域です。
| 手段 | 中身を出さず渡す | 独立検証 | 改ざん不能 |
|---|---|---|---|
| アクセス制御のみ | △ | ✗ | ✗ |
| マスキング / 匿名化 | △ | ✗ | ✗ |
| 暗号化のみ | ✓ | ✗ | ✗ |
| Lemma（ZK 証明）唯一 3 つ揃う | ✓ | ✓ | ✓ |
進め方
エージェント決済のガバナンス支援と PoC から入り、運用まで伴走します。
- 30分の棚卸し — エージェントに決済を任せ始めたが、委任の範囲と権限が API キーとプロンプト側ガードレールで支えられたままの業務を特定。
- 証明したい判定(結果)を1〜2個に絞る — 例:「principal の委任範囲内」「spend limit 以内」「jurisdiction 属性を満たす」など、決済確定前に検証したい事実。原本(本番ペイロードや principal の鍵)は出しません。
- 接続と版管理を設計 — 既存の決済レール・エージェント runtime・x402 / MCP / A2A 環境との接続方式と、委任ポリシーの版固定。
- PoC(見積ベース)で1経路を実証 — 1つの委任パスでコール単位のアテステーション検証が動くことを確認。
- 導入支援と運用の伴走へ — 導入から運用まで継続して伴走します。費用感の目安として既存プラン区分（Civic / Critical / Compliance）を参照しますが、構成と価格は会話のなかで設計します。
settlement リスクが集中している委任パスを1つ、最初の30分で聞かせてください。エージェントの実装詳細や本番ペイロードの開示は必要ありません。
より広い活用シーン
このユースケースを含む、活用シーンの全体像。
業界・業務領域ごとの活用シーンと、4 つの軸で整理しています。
Solutions で エージェント権限の活用シーンを見る →DISCOVERY CALL
まずは、30 分の対話から。
Lemma の機能や活用場面について、ご質問にお答えします。技術的な詳細や機微情報（個人情報や機密情報など）の開示は不要です。