MandatePay
MandatePay
Die Autorisierungs-Firewall für agentische Zahlungen
Identität · Absicht · Richtlinie · Menschliche Genehmigung · Kryptografischer Nachweis
Autonome Agenten können Zahlungen vorschlagen. Sie sollten keine unbegrenzte finanzielle Autorität erhalten. MandatePay überprüft jede maschineninitiierte Zahlung vor der Ausführung gegen ein signiertes menschliches Mandat.
Warum es das gibt
Agentischer Handel bringt ein neues Kontrollproblem mit sich: Wie kann ein Zahlungsanbieter nachweisen, dass ein KI-Agent innerhalb der von einem Menschen oder einer Organisation delegierten Autorität gehandelt hat? Der traditionelle Checkout setzt voraus, dass eine Person anwesend ist. API-Schlüssel etablieren Anwendungszugriff, aber keinen Zweck, keine Limits, keine Geografie, keinen Händlerumfang und nicht die exakte Grenze der delegierten Absicht.
MandatePay ist eine Forschungsebene der Kontrollebene, die zwischen Agenten und Zahlungsschienen sitzt. Es hält keine Gelder und bewegt keine Gelder.
Related MCP server: Safe4
Was es anders macht
Signierte Mandate: Autorität ist maschinenverifizierbar und manipulationssicher.
Policy-as-Code: deterministische Limits für Wert, Gesamtausgaben, Währung, Land, Händler, Zweck, Ablauf und Geschwindigkeit.
Menschliche Herausforderung: Risikoreichere Absichten pausieren für eine Genehmigung, die an die exakte Zahlung gebunden ist.
Bindung der Agentenidentität: Ein Mandat kann nicht von einem anderen Agenten wiederverwendet werden.
Replay-Sicherheit: Idempotenzschlüssel geben die ursprüngliche Entscheidung zurück.
Verifizierbare Ereignisse: Jede Entscheidung wird in ein hash-verkettetes Journal eingetragen.
MCP-Tool: Agenten können über eine eingeschränkte Tool-Schnittstelle Autorisierung anfordern.
Fail closed: Ungültige Signaturen, fehlerhaftes Geld, abgelaufene Autorität und Scope-Eskalation werden abgelehnt.
Autorisierungs-Lebenszyklus
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 chainSchnellstart
git clone https://github.com/muhammadashir0/mandatepay.git
cd mandatepay
python -m unittest discover -s tests -v
python app.pyÖffne http://localhost:8080.
Probiere vier Szenarien in der Konsole aus:
€299 / software / DE→ autorisieren€400 / software / DE→ menschliche Herausforderung€900 / software / DE→ ablehnen: Zahlungslimit€100 / travel / GB→ ablehnen: Zweck und Land
Verwende einen neuen Idempotenzschlüssel, wenn du das Szenario wechselst.
MCP-Server
python -m mandatepay.mcp_serverDer abhängigkeitsfreie JSON-RPC-Server stellt ein bewusst schmales Tool bereit: request_payment_authorization. Das Tool gibt eine Entscheidung zurück, keine Geldbewegung.
Bedrohungsmodell
MandatePay ist ausgelegt auf:
gestohlene oder überprivilegierte Agenten-Anmeldedaten;
Prompt-Injection, die unbeabsichtigte Käufe verursacht;
Mandatsmanipulation und Scope-Eskalation;
doppelte Ausführung und Replay;
Geschwindigkeitsmissbrauch und kumulative Überausgaben;
mehrdeutige menschliche Genehmigung;
unvollständige forensische Beweise.
Siehe docs/THREAT_MODEL.md für Vertrauensgrenzen, Nicht-Ziele und Produktionskontrollen.
Repository-Architektur
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 APIEvaluierung, nicht nur eine Demo
Die Tests verifizieren Autorisierung, Genehmigungs-Herausforderungen, Identitätsabweichung, Scope-Eskalation, Geschwindigkeitslimits und Manipulation signierter Mandate. Die nächste Benchmark-Ebene wird falsche Autorisierungen, falsche Ablehnungen, Replay-Resistenz, Policy-Abdeckung, Entscheidungslatenz und Genehmigungslast über adversariale Szenarien hinweg messen.
Roadmap
Ed25519/JWS-Produktionssignierung und Schlüsselrotation
OAuth-beglaubigte Agentenidentität und Workload-Identität
Genehmigungszeremonie gebunden an Intent-Hash
Einmalige Autorisierungstokens für Zahlungsanbieter
Dauerhaftes SQL-Ledger mit Nebenläufigkeitsgarantien
OpenTelemetry-Entscheidungs-Traces und signierter Audit-Export
Adversarialer Evaluierungskorpus für Agenten-Zahlungsangriffe
Stripe/Adyen-Sandbox-Adapter hinter einer Ausführungsschnittstelle
Mehrwährungs-Dezimal- und FX-Policy
Grenze der verantwortungsvollen Nutzung
Dieses Repository ist ein Sicherheits- und FinTech-Forschungs-MVP mit synthetischen Identitäten und ohne echte Gelder. HMAC wird nur verwendet, um die Demonstration abhängigkeitsfrei zu halten. Die Produktionsbereitstellung erfordert überprüfte asymmetrische Kryptografie, gehärtete Identität, dauerhafte transaktionale Speicherung, Authentifizierung und Autorisierung, regulatorische Analyse, Datenschutzkontrollen, unabhängige Sicherheitstests und die Zertifizierung durch den Zahlungsanbieter.
Strategischer Kontext
Agentische Zahlungssysteme benötigen mandatsbasierte Autorisierung, Trennung zwischen Entscheidung und Ausführung, Agentenidentität, programmierbare Kontrollen, Prüfpfade und abgestufte menschliche Aufsicht. MandatePay verwandelt diese Designanforderungen in einen überprüfbaren Open-Source-Prototyp.
Lizenz
Apache License 2.0.
Available Tools
1 toolrequest_payment_authorizationA
Evaluate a proposed agent payment against a signed spending mandate. Does not move funds.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| purpose | Yes | ||
| currency | Yes | ||
| merchant_id | Yes | ||
| merchant_country | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. The explicit statement 'Does not move funds' is a critical side-effect disclosure that prevents accidental fund transfers. However, it does not describe the output nature (e.g., approval/denial) or any other side effects, leaving some behavioral gaps. The core non-effect is well covered, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, leading with the core purpose and then a critical safety note. There is no wasted wording, and the most important information (the scrutiny and non-movement) is front-loaded. This is an exemplary level of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too brief for a tool with five required parameters and no output schema. It omits the return value (e.g., whether the authorization is granted or denied), any prerequisites like having the mandate document, and does not clarify the 'purpose' field's semantics. An agent lacks critical information to interpret the tool's result and handle errors effectively, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate by explaining the parameters. It does not describe any of the five fields (amount, currency, merchant_id, merchant_country, purpose). The context of a 'proposed agent payment' hints at their role but provides no additional meaning beyond the schema's field names, which is insufficient for a tool with no inline descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Evaluate') and a clear resource ('proposed agent payment against a signed spending mandate'), and explicitly states it does not move funds, which distinguishes it from payment execution tools. Even without siblings, the purpose is precise and unambiguous, leaving no doubt about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the use case: evaluating a payment proposal against a mandate before funds are moved. It does not explicitly state when not to use it or mention alternatives, but the context is strong enough that an agent understands when to invoke it. Since no siblings are present, the lack of exclusions is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
request_payment_authorization
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion or overlap between tools. The tool's purpose is clearly defined and singular.
A single tool follows a consistent verb_noun pattern ('request_payment_authorization'), which is clear and descriptive. No inconsistencies exist by definition.
The server has only one tool, which feels thin for a system named 'MandatePay'—implying broader mandate management. While the tool itself is well-scoped, the overall surface is borderline minimal.
The tool covers only payment authorization, but the domain suggests the need for related operations like mandate creation, listing, updating, or checking status. Without these, agents face significant dead ends when managing mandates.
Maintenance
Related MCP Connectors
Allow, ask, or veto — a policy decision point your agent consults before signing any payment
Pre-spend firewall for AI agents. Approves, blocks, flags transactions against policy rules.
Agent payments, API key vaulting, and governed mandates. Agents spend within user-defined limits.
Check an agent action against its operator's mandate before acting: permit, deny or escalate.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceDeterministic, auditable payment policy enforcement for AI agents. It provides pre-action authorization with scopes, budgets, allowlists, and signed mandates via an MCP server.MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to verify proposed payments against their assigned task, budgets, permitted categories, and counterparties, returning an ALLOW or DENY decision with a tamper-evident audit trail.MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to use payment APIs safely by gating every tool call through deterministic mandates, value checks, and an exactly-once ledger, so they cannot pay twice or exceed authorisation.260 npmMIT
- AlicenseNot gradedqualityFmaintenanceEnables MCP clients to ask permission before an agent acts, returning allow, deny, or ask_human with receipts, and to monitor agent spend, limits, and recent decisions.0Functional Source , Version 1.1, ALv2 Future