aml_sanctions_ai_agent_payments

54 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Agent identity verification before screening

Agents must present a cryptographic identity credential (signed passport, ECDSA key pair, or verifiable credential) before accessing sanctions screening endpoints. Self-declared identity headers like X-Agent-ID and X-Agent-Role without cryptographic proof must be rejected. The agent's identity must be bound to the screening request so the audit trail proves which specific agent performed the check.

Trust level verification before screening access

Verify the agent's trust level before granting access to sanctions screening services. Not all agents should have the same level of access to sanctions data. Use graduated trust levels (L0 to L4) with increasing access rights.

Agent public key fingerprint in audit logs

Record the agent's public key fingerprint or passport ID in every screening request log entry to create tamper-evident audit records.

Reject TLS-only agent identity verification

Transport-layer identity (TLS client certificates at a load balancer) must not be accepted as the sole proof of agent identity. Message-level identity binding is required.

Entity screening against global sanctions lists

Screen all counterparties (individuals, businesses, vessels, addresses) against applicable sanctions lists before processing a payment. Include the agent's identity and trust level in the screening context so downstream systems can distinguish agent-initiated screens from human-initiated screens.

Structured machine-readable screening results

Return structured, machine-readable screening results to agents in JSON format with clear match/no-match/partial-match indicators and match scores. Agents cannot interpret PDF reports or HTML pages.

Enforce minimum match thresholds

Implement minimum match thresholds that agents cannot override or lower below the institution's configured minimum.

Log every screening request with agent identity

Log every screening request and result with the agent's cryptographic identity, a timestamp, and a unique request nonce.

Sign screening results to prevent tampering

Return screening results with digital signatures. Unsigned results can be tampered with in transit, allowing a compromised intermediary to change a match result from match to no-match.

Screening result caching time limits

Agents must not cache screening results beyond a configurable time window. Sanctions lists are updated frequently and stale results create compliance gaps.

Restrict agent access to screening API

Agents should call a screening API and must not have direct access to raw sanctions list data or be permitted to download the full list.

Agent operator screening during onboarding

Screen the agent's declared operator (organization name, jurisdiction, registration number) against sanctions lists during agent onboarding. The operator is the developer, company, or deployer that built and runs the agent.

Periodic re-screening of agent operators

Re-screen agent operators periodically, at minimum when sanctions lists are updated. Revoke agent access if the operator becomes sanctioned.

Operator identity in agent cryptographic credential

Require agents to declare their operator identity as part of their cryptographic passport or identity credential.

Anonymous agents must not access screening services

Agents must not operate without a declared operator. Anonymous agents must not be permitted to access sanctions screening services.

Sign screening requests with unique nonce and timestamp

Sign every screening request with the agent's private key, including a unique nonce and timestamp.

Sign screening responses with server private key

Sign every screening response with the server's private key, including its own nonce and timestamp.

Hash-chained audit entries for tamper evidence

Chain audit entries using cryptographic hashes where each entry includes the SHA-256 hash of the previous entry to create a tamper-evident log.

Audit entry contents

Include in each audit entry: agent identity (public key fingerprint or passport ID), tool invoked, hash of the screening arguments (not raw arguments for privacy), screening result (match/no-match/partial), timestamp, and the hash of the previous audit entry.

Audit record retention period

Retain audit records for the period required by applicable regulations, typically 5 years for BSA/AML.

Audit records must be machine-readable exportable

Make audit records exportable in a machine-readable format for regulatory examination.

Do not rely on application logging for audit trail

Application-level logging (console.log, syslog) must not be relied upon as the sole audit trail because these logs are not tamper-evident and can be modified without detection.

Audit records must not be stored in agent-controlled storage

Store audit records on infrastructure controlled by the financial institution, not on the agent's device or in agent-controlled storage.

Omitting agent identity in audit records

Do not omit the agent's identity from audit records. A screening record that does not identify which agent performed the check is useless for regulatory purposes.

Hash chain integrity requirement

Do not allow gaps in the hash chain. A broken chain indicates tampering or data loss and must trigger an alert.

Fail-closed enforcement on screening failure

When screening fails due to timeout, service outage, malformed response, or any other error, deny the transaction. Silent pass-through on screening failure is a compliance violation.

Error response clarity for screening failure

Return a clear, structured error to the agent indicating that screening failed and the transaction cannot proceed.

Log screening failures with full detail

Log all screening failures with the same level of detail as successful screens, including the reason for failure.

Alert on screening failure rate threshold

Alert compliance teams when screening failure rates exceed a threshold, as this may indicate a denial-of-service attack designed to force fail-open behavior.

Circuit breaker for screening service unavailability

Implement circuit breakers that halt agent-initiated payments entirely if the screening service is unavailable for an extended period.

Per-agent rate limiting based on cryptographic identity

Implement per-agent rate limits based on cryptographic identity (public key fingerprint or passport ID), not IP address. Multiple agents may share an IP, and a single agent may use multiple IPs.

Graduated rate limits by trust level

Set lower rate limits for newly registered or low-trust agents (L0/L1) and higher limits for verified, high-trust agents (L3/L4).

Rate limit status in screening responses

Include rate limit status in screening responses (remaining quota, reset time) so agents can adjust their behavior.

Downgrade agent rate limit on anomalous behavior

Downgrade an agent's rate limit allocation if anomalous behavior is detected, such as sudden spike in screening requests or unusual entity patterns.

Prevent sybil attacks on agent identities

Tie agent identities to verified operator accounts to prevent sybil attacks where agents circumvent rate limits by creating multiple identities.

TLS encryption for screening requests in transit

Encrypt all screening requests in transit with TLS 1.2 minimum, regardless of self-hosted or hosted screening architecture.

Message-level signing for hosted screening services

Sign screening requests at the message level (not just transport level) to ensure integrity through intermediaries, CDNs, or proxies when using hosted screening APIs.

Verify hosted screening provider response signatures

Verify the screening provider's response signatures if using a hosted service to ensure integrity.

Data minimization for hosted screening services

Send only the minimum data needed for screening to third-party screening providers, not the agent's full context or private keys and identity credentials.

JSON Canonicalization Scheme (RFC 8785) for receipts

Use JSON Canonicalization Scheme (JCS), RFC 8785, to produce a deterministic byte representation of compliance receipts before hashing and signing. The signer canonicalizes, hashes (with SHA-256), then signs; every verifier canonicalizes the received receipt identically and checks the signature.

Record canonicalization algorithm in receipt

Record the canonicalization, hash, and signature algorithm in the receipt (for example canon: jcs, alg: ecdsa-p256-sha256) so any verifier can reproduce it.

Sign receipt hash, not raw JSON

Sign over the hash of the canonical bytes, not raw or pretty-printed JSON, to ensure verifiable receipts across systems.

Attach signed compliance receipt to transaction

Attach the signed compliance receipt to the transaction and propagate it across every agent hop in a payment flow.

Bind receipt to transaction with intent hash

Bind each receipt to the specific transaction by including the transaction or intent hash in the signed payload.

Verify inbound receipt at each agent hop

At each hop in a multi-agent payment flow, verify the inbound receipt before acting. If the agent takes its own action, append a new signed receipt, producing a verifiable chain of accountability across agents.

Include sanctions list version in receipt

Include the sanctions-list source(s), version or publication date, and screening timestamp inside the signed receipt to prove screening freshness.

Define maximum acceptable sanctions list age

Define a maximum acceptable sanctions list age, record it in the receipt, and fail-closed if it is exceeded.

Audit screening result with list version

Make list freshness auditable after the fact from the receipt alone. Screening results without recorded list versions are not compliant.

Agent identity verification maps to KYC/KYB

Agent identity before screening (Section 1) maps to KYC/KYB attribution and FATF Recommendation 10 (Customer Due Diligence).

Entity and operator screening maps to sanctions obligations

Entity and operator screening (Sections 2-3) maps to OFAC, EU, UK, and UN sanctions screening obligations and FATF Recommendation 6.

Signed audit trail maps to recordkeeping requirements

Signed audit trail and receipt (Sections 4, 8-10) map to recordkeeping requirements, FATF Recommendation 11, and multi-year retention obligations under BSA and EU AMLD.

Fail-closed enforcement maps to blocking obligations

Fail-closed enforcement (Section 5) maps to blocking obligations for sanctioned parties.

Trust-tiered limits map to risk-based approach

Trust-tiered limits (Section 6) map to risk-based approach requirements under FATF Recommendation 1 and monitoring thresholds.

Agent payment controls map to AISVS Chapter 10

The consolidated controls in this cheat sheet align with AI-system-specific verification requirements in the OWASP Artificial Intelligence Security Verification Standard (AISVS), in particular Chapter 10 (MCP Security Requirements).

Give your agent this brain