MandatePay

エージェント型決済のための認可ファイアウォール

アイデンティティ · インテント · ポリシー · 人間による承認 · 暗号学的証明

自律エージェントは支払いを提案できる。しかし、無制限の金銭的権限を与えるべきではない。MandatePay は、機械が開始したすべての支払いを、実行前に署名済みの人間のマンデート（委任状）と照合して検証する。

なぜこれが必要か

エージェント型コマースは新たな制御問題を生み出す。決済プロバイダーは、AI エージェントが人間または組織から委任された権限の範囲内で行動したことを、どうやって証明できるのか？ 従来のチェックアウトは、人間がその場にいることを前提としている。API キーはアプリケーションへのアクセスを確立するが、目的、限度額、地域、加盟店の範囲、委任されたインテントの正確な境界は確立しない。

MandatePay は、エージェントと決済レールの間に位置する研究グレードのコントロールプレーンである。資金の保持や移動は行わない。

Related MCP server: dingdawg-agent-wallet

何が違うのか

• 署名済みマンデート: 権限は機械検証可能で、改ざんが明らかになる。

• ポリシー・アズ・コード: 金額、累計支出、通貨、国、加盟店、目的、有効期限、速度に関する決定的な制限。

• 人間によるチャレンジ: 高リスクのインテントは、正確な支払いに紐づいた承認のために一時停止される。

• エージェント ID のバインド: マンデートは別のエージェントによって再利用できない。

• リプレイ安全性: 冪等性キーにより、元の判定が返される。

• 検証可能なイベント: すべての判定はハッシュチェーン式ジャーナルに記録される。

• MCP ツール: エージェントは制約付きツールインターフェースを通じて認可を要求できる。

• フェイルクローズ: 無効な署名、不正な金額、期限切れの権限、スコープ逸脱は拒否される。

認可ライフサイクル

sequenceDiagram
    participant H as Human / Organization
    participant A as AI Agent
    participant M as MandatePay
    participant P as Payment Provider
    H->>M: Sign bounded mandate
    A->>M: Submit payment intent
    M->>M: Verify identity + signature + policy + state
    alt within authority
        M-->>A: Single-use authorization
        A->>P: Execute with authorization proof
    else approval threshold
        M-->>H: Challenge exact intent
    else policy violation
        M-->>A: Deny with reason codes
    end
    M->>M: Append decision to audit chain

クイックスタート

git clone https://github.com/muhammadashir0/mandatepay.git
cd mandatepay
python -m unittest discover -s tests -v
python app.py

http://localhost:8080 を開く。

コンソールで4つのシナリオを試す:

1. €299 / software / DE → 認可

2. €400 / software / DE → 人間によるチャレンジ

3. €900 / software / DE → 拒否: 支払い限度額

4. €100 / travel / GB → 拒否: 目的と国

シナリオを変更するときは、新しい冪等性キーを使用する。

MCP サーバー

python -m mandatepay.mcp_server

依存関係ゼロの JSON-RPC サーバーは、意図的に狭い1つのツール request_payment_authorization を公開する。このツールは判定を返すものであり、資金移動ではない。

脅威モデル

MandatePay は以下を想定して設計されている:

• 盗難または過剰権限を持つエージェント認証情報;

• 意図しない購入を引き起こすプロンプトインジェクション;

• マンデートの改ざんとスコープの拡大;

• 重複実行とリプレイ;

• 速度の悪用と累積超過支出;

• 曖昧な人間の承認;

• 不完全なフォレンジック証拠。

信頼境界、非目標、本番環境の制御については docs/THREAT_MODEL.md を参照。

リポジトリ構成

mandatepay/
├── mandatepay/
│   ├── core.py          # signed mandate + deterministic policy engine
│   ├── store.py         # state, idempotency, tamper-evident journal
│   └── mcp_server.py    # constrained MCP-compatible tool server
├── web/index.html       # premium operator console
├── tests/               # policy and adversarial scenarios
├── docs/                # protocol, threat model, product direction
└── app.py               # sandbox HTTP API

デモではなく評価

テストは、認可、承認チャレンジ、ID 不一致、スコープ逸脱、速度制限、署名済みマンデートの改ざんを検証する。次のベンチマーク層では、敵対的シナリオにわたって、誤認可、誤拒否、リプレイ耐性、ポリシーカバレッジ、判定レイテンシ、承認負担を測定する。

ロードマップ

• Ed25519/JWS 本番署名と鍵ローテーション

• OAuth で証明されたエージェント ID とワークロード ID

• インテントハッシュに紐づいた承認セレモニー

• 決済プロバイダー向けの単回使用認可トークン

• 並行性保証を備えた永続 SQL 台帳

• OpenTelemetry 判定トレースと署名付き監査エクスポート

• エージェント決済攻撃のための敵対的評価コーパス

• 実行インターフェース背後にある Stripe/Adyen サンドボックスアダプター

• 多通貨小数および FX ポリシー

責任ある利用の境界

このリポジトリは、合成 ID と実際の資金を使用しないセキュリティおよび FinTech 研究 MVP である。HMAC は、デモを依存関係なしに保つためだけに使用されている。本番展開には、レビュー済みの非対称暗号、強化された ID、永続的なトランザクションストレージ、認証と認可、規制分析、プライバシー制御、独立したセキュリティテスト、決済プロバイダーの認定が必要である。

戦略的コンテキスト

エージェント型決済システムには、マンデートベースの認可、決定と実行の分離、エージェント ID、プログラム可能な制御、監査証跡、段階的な人間の監督が必要である。MandatePay は、これらの設計要件を検査可能なオープンソースのプロトタイプに変換する。

ライセンス

Apache License 2.0。