エージェント決済の濫用と、Trust 層の不在
AI エージェント決済のコールごとに、誰が・どの範囲で・いくらまで委任したかを ZK 証明として添付します。受け手は API キーへの信頼ではなく、暗号的に検証された委任に基づいて、決済確定の前に正当性を検証できます。
エージェント決済を運用する組織の方へ
API キーとプロンプトのガードレールだけを頼りにエージェントの決済が通ってしまうリスクを、確定前の独立検証で防ぎます。
-
AI エージェントを自社業務に組み込み始めた組織のセキュリティ責任者
-
x402 / MCP / A2A 環境で決済を運用する開発者・運用責任者
-
エージェント駆動の行為に対する監査・統制責任を持つコンプライアンス担当
原本を渡すか、事実だけを渡すか。
現場の手は増えない。相手の確認が変わる。
① 現場は、保存するだけ。
- いつもの操作
- 記録を入力して、保存
- 保存と同時に
- 証明が付く（裏で API 連携）
- 記録の本文
- 送信されない
② 相手は、リンクを開くだけ。
- 証明された事実
- 各支払いが認可された委任の範囲内である
- エージェントの鍵・委任の中間ステップ
- 表示されない
- ログイン・キー
- 不要
- 本文は出さない — 記録の本文（個人情報・機微データ）は送信も開示もしません。
- 相手が独立に検証 — 受け取った側はリンクを開くだけ。アカウントもキーも不要です。
- 書き換えは検知 — 1文字の書き換えも、検証の時点で一致しなくなります。
Lemma は、エージェントが決済を発行する瞬間に Trust402 アテステーションを添付します。アテステーションが封じるのは、行為を委任した principal、委任の役割と範囲、コール単位の spend limit、相手側が検証する必要がある jurisdiction 属性（例：「このエージェントは JP 登録の事業者の代理である」）です。
このアテステーションは ZK 証明であり、bearer credential ではありません。エージェントは principal の鍵を持ち歩きません。受信側 — 決済コントラクト・x402 middleware・取引相手のリスクエンジン — が、principal のオンチェーン委任ポリシーに対して証明を検証してから決済を確定します。失効も同じレイヤーで伝播します。principal レベルで 1 トランザクション送れば、それに依存する全ての下流アテステーションが無効化されます。
結果として、「誰が・どの範囲で・どの jurisdiction を満たして委任したか」は、事後の再構成ではなく、決済確定の前提条件になります。
なぜ、いままでのやり方では足りないのか。
「中身を出さず渡す」「独立検証」「書き換えの検知」の 3 つが同時に要る業務こそが Lemma の領域です。
| 手段 | 中身を出さず渡す | 独立検証 | 書き換えを検知 | そのままだと |
|---|---|---|---|---|
| アクセス制御・権限管理 | △ | ✗ | ✗ | 社内の誰かが直せた、という疑いが残る |
| マスキング / 黒塗りで提出 | △ | ✗ | ✗ | 黒塗りの手間が増え、元の記録の真正性は示せない |
| 暗号化して保管・送付 | ✓ | ✗ | ✗ | 相手が確かめるには、結局開示が要る |
| Lemma（ZK 証明）唯一 3 つ揃う | ✓ | ✓ | ✓ | 相手がリンクを開くだけで確かめられる |
実装イメージと、導入の流れ。
開示範囲・保存期間の設計から PoC、本番運用まで伴走します。
まずは、30分のヒアリングから。
settlement リスクが集中している委任パスを1つ、最初の30分で聞かせてください。エージェントの実装詳細や本番ペイロードの開示は必要ありません。
お探しの業界・課題に合わせた事例が見つかります
課題や業種から業務ユースケースを探す（全36件） →