Trust Center · security
Security
Threat model, hard bans, logging redaction, and receipt verification for ABCP.
01
Threat model (money agents)
| Threat | Control |
|---|---|
| Prompt injection → create_payment | Allowlist + sec.money_v1 inject case |
| Confused deputy / treasury write | Tenant scope + SoD + suite case |
| SSRF via invoice URL | Egress allowlist; arg substring bans |
| Secret echo | DLP + output pattern bans |
| Loop drain | Per-tx, daily, and loop caps |
| High-value without confirm | Confirm gate + dual control |
| Revoke without confirm | Confirm required on revoke_agent |
02
Hard bans
- Soft-accept after failed rail verification
- Logging PAN, raw account numbers, or API keys
- Agent-driven arbitrary egress to help pay
- Claiming bank charter or regulator approval without evidence
03
Logging redaction
Receipts and logs may retain tool name, amounts in minor units, currency, partner_ref, outcome, and check IDs. They must not retain PAN, CVV, full account numbers, bearer tokens, or private keys.
04
Receipt verification
- Take the receipt payload object (unsigned fields only).
- Canonicalize: UTF-8 JSON with recursively sorted object keys and no insignificant whitespace.
- Verify Ed25519 signature (
signature_b64) against the published verifying key. - Optionally validate against receipt-money-v1.
Verifying key (SPKI DER, base64):
MCowBQYDK2VwAyEAmPJMuw6tH7vGOp5Ct6tzfS+dkaG+Cp1bOfrAwCXhtuo=
Signed example · POST /v1/receipts/verify
Example verify path on https://banking.noetfield.com does not move money.