We Built the Missing Trust Layer for AI Agent Payments

AI Agents Will Move Money. The Infrastructure Isn't Ready.

In Q1 2026, Stripe launched the Machine Payments Protocol. Mastercard shipped Agent Pay with agentic tokens. Visa announced Intelligent Commerce. Cloudflare deployed Web Bot Auth for agent-initiated transactions. AWS published guidance on x402 for autonomous payments. FedNow crossed $245 billion in quarterly volume with 49,000% year-over-year growth.

The message is clear: AI agents are entering the payment system. Not as assistants that help humans pay, but as autonomous actors that initiate, authorise, and execute financial transactions without a human in the loop.

But every one of these platforms assumes someone else handles trust.

Stripe authenticates the API key. Mastercard validates the token. Visa checks the credential. None of them answer the question that matters: should this specific agent, making this specific payment, to this specific counterparty, at this specific amount, right now, be trusted to do so?

We built the stack that answers that question. Agent identity is broken. We fixed it.

OAuth was built for humans with browsers. API keys were built for developers with dashboards. Neither was designed for autonomous

software making financial decisions at machine speed with no human in the loop.

Retrofitting human identity patterns onto agents is an

anti-pattern -- it gives you authentication without trust, access without limits, and credentials without accountability.

ATTP starts from the premise that identity is necessary but not sufficient. Knowing who the agent is does not tell you what it should beallowed to do.

The Six-Layer Problem

A human making a payment goes through multiple trust checks without thinking about it: their bank knows them, their card has limits, the merchant is verified, fraud detection runs in real-time, and they can call the bank to reverse a charge. Decades of infrastructure sits behind every tap of a card.

An AI agent making a payment has none of this. It has an API key.

The stack we've built at CyberSecAI addresses six layers that must all pass before an agent payment executes:

Layer 1: Identity    -- Is this agent who it claims to be?
Layer 2: Trust       -- Has this agent earned the right to transact?
Layer 3: Integrity   -- Is this payment request authentic and untampered?
Layer 4: Enforcement -- Does this transaction fall within the agent's limits?
Layer 5: Compliance  -- Is the counterparty sanctioned?
Layer 6: Audit       -- Is there a tamper-evident record of everything?

Most agent authentication protocols handle Layer 1. Some handle Layer 3. We haven't found anything else that handles Layers 2 through 6.

ATTP: The Trust Layer

We submitted the Agent Trust Transport Protocol (ATTP) to the IETF as draft-sharif-attp. ATTP is protocol-agnostic -- it defines how trust works for autonomous agents regardless of what transport protocol they use.

The core concept: trust is not identity. Identity is binary. You are who you claim to be, or you are not. Trust is graduated. It is earned over time, adjusted by behaviour, and revocable instantly.

ATTP defines five trust levels:

Level	Score Range	What the Agent Can Do
L0	0-19	Nothing. Identified but cannot transact. Read-only.
L1	20-39	Micro-payments. $10 per transaction, $50 per day.
L2	40-59	Standard transactions. $100/tx, $500/day.
L3	60-79	Elevated. $1,000/tx, $5,000/day. Monitored.
L4	80-100	Full access. $50,000/tx, $200,000/day. Every action audited.

New agents start at L0. They cannot spend a single dollar. Trust is earned through five dimensions: code attestation, execution success rate, behavioural consistency, operational tenure, and anomaly history. Each dimension contributes equally to a composite score that maps to the trust level.

This is not a configuration setting. It is a protocol-enforced constraint. An L0 agent cannot make payments regardless of what the application layer says. The trust check happens before the payment processor ever sees the request.

Promotion Rate Limiting

Earning trust takes time. This is deliberate. ATTP mandates minimum durations at each level:

• L0 to L1: 24 hours, 5 successful actions minimum
• L1 to L2: 7 days, 20 successful actions
• L2 to L3: 30 days, 100 successful actions, zero critical anomalies
• L3 to L4: 90 days, 500 successful actions, zero anomalies, manual attestation

An attacker who creates a fake agent and tries to build trust through small transactions needs at minimum 128 days of sustained, anomaly-free operation before reaching L4. Demotions, by contrast, are instant. A single critical anomaly at L4 drops the agent to L2 immediately.

Kill Switches

Certificate revocation is too slow for payments. CRLs update on schedules. OCSP adds latency and creates a single point of failure. If an agent is compromised at 2:47 PM and your revocation mechanism runs hourly, that is up to 60 minutes of unauthorised transactions at machine speed.

ATTP kill switches are checked on every single request. Per-agent, per-principal, and global emergency. When activated, the next request is denied. No grace period. No propagation delay. The agent's trust score is frozen, not reset -- so when the issue is resolved, the agent resumes at its previous level rather than starting over.

MCPS: The MCP Binding

ATTP is transport-agnostic. It defines what trust means. Protocol bindings define how trust is enforced on specific transports.

MCPS (MCP Secure) is the binding for the Model Context Protocol -- the protocol behind 97 million SDK downloads that connects AI agents to tools. MCPS wraps every JSON-RPC message in a signed envelope:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "payment_initiate",
    "arguments": {
      "amount": 5000,
      "recipient": "Acme Corp",
      "currency": "USD"
    }
  },
  "mcps": {
    "signature": "MEUCIQD...",
    "nonce": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "timestamp": 1714521600000,
    "trustLevel": 2,
    "keyFingerprint": "sha256:9f86d08..."
  }
}

Every message is signed with ECDSA P-256. Every message carries a nonce for replay protection. Every message includes a timestamp checked against a bounded window (5 minutes). The trust level is embedded in the envelope and verified before the tool executes.

If an attacker intercepts and replays a signed payment request, the nonce is already used -- rejected. If they modify the amount, the signature is invalid -- rejected. If they steal the agent's credentials but the kill switch has been activated -- rejected. If the agent's trust level has decayed due to dormancy -- the payment exceeds the new lower limits and is rejected.

MCPS is the first binding. ATTP also defines bindings for REST APIs (via HTTP headers), Google A2A (via Task metadata), gRPC (via metadata headers), and GraphQL (via extensions). The same trust model works across all of them.

Sanctions Screening: Not Optional

If an AI agent initiates a payment on behalf of a regulated entity, every counterparty must be screened against sanctions lists. This is not a feature request. It is a legal requirement under AML regulations in virtually every jurisdiction.

We integrated with global Fintechs, on open-source sanctions screening engine that checks against OFAC SDN, EU, UK, and UN sanctions lists in real-time. Every payment flows through screening before the ACH file is generated.

The screening uses fuzzy matching with a configurable threshold. A 70% match score blocks the transaction. Near-misses are logged for compliance review. The full screening result -- query, lists checked, matches, decision -- is recorded in the audit trail and retained for the regulatory minimum of five years.

An authenticated agent with L4 trust still gets blocked if the recipient matches a sanctioned entity. Identity does not override compliance. Trust does not override law.

Consider what happens without this: an agent authenticates with valid credentials, passes all identity checks, and initiates a payment to a sanctioned entity. You now have cryptographic proof that the payment was legitimate. That is worse than no security at all -- it is auditable evidence of a compliance failure.

The Payment Flow: End to End

Here is what happens when an agent initiates a payment through the full stack:

Step 1: Identity. The agent presents its credentials. This can be an OIDC token from Keycloak, an X.509 certificate, an HTTP Message Signature, or any other identity assertion. ATTP does not prescribe the identity mechanism. It consumes identity from any standards-compliant source.

Step 2: Trust evaluation. The Trust Authority computes the agent's current trust score from five behavioural dimensions. The score maps to a trust level. If the agent is L0 or L1, the payment is rejected immediately -- no further processing.

Step 3: MCPS signature verification. The payment request's MCPS envelope is verified: valid ECDSA signature, unused nonce, timestamp within window. If any check fails, the request is rejected with a specific error code.

Step 4: Kill switch check. The agent's kill switch state is checked atomically. If active, immediate rejection.

Step 5: Limit enforcement. The payment amount is checked against the agent's per-transaction limit and daily aggregate. Both must pass. The check uses atomic compare-and-swap to prevent race conditions from concurrent requests.

Step 6: Sanctions screening. The recipient name is screened against OFAC SDN, EU, UK, and UN sanctions lists. Fuzzy matching with configurable threshold. Match above threshold blocks the transaction.

Step 7: ACH generation. A NACHA-compliant ACH file is generated with the transaction details. The file includes standard batch headers, entry details, and control records.

Step 8: Response signing. The response is signed by the gateway with its own ECDSA key. The agent can verify the response came from the legitimate gateway, not a man-in-the-middle.

Step 9: Audit recording. The entire transaction -- request, trust evaluation, compliance check, ACH details, response -- is recorded in a hash-chained audit log. Each entry includes the hash of the previous entry. Breaking the chain indicates tampering.

Step 10: Trust adjustment. Successful payment: +0.5 trust bonus. Blocked payment: -2. Anomaly detected: -5. The agent's trust score adjusts dynamically based on every interaction.

Nine of these ten steps happen in milliseconds. The only step with variable latency is sanctions screening, which typically completes in under 50ms.

Enterprise Integration: Keycloak

For organisations running Keycloak (or any OIDC-compliant identity provider), ATTP trust levels embed directly in standard JWT access tokens:

{
  "sub": "agent_procurement_bot",
  "iss": "https://keycloak.example.com/realms/agents",
  "attp": {
    "trust_level": 2,
    "trust_label": "L2 -- Standard",
    "payment_enabled": true,
    "tx_limit": 10000,
    "day_limit": 50000,
    "scopes": "payment_initiate,sanctions_screen",
    "protocol_version": "1.0"
  }
}

Keycloak roles (attp-l0 through attp-l4) map to trust levels via a protocol mapper. The agent authenticates through standard OIDC flows. The JWT carries the trust claims. The payment gateway reads the claims and enforces limits. No new authentication infrastructure required.

This means an enterprise with 500 agents can manage trust levels through the same role-based access control they already use for human users. Promote an agent from L1 to L2? Change its Keycloak role. Kill an agent? Revoke its session. Audit who changed what? Keycloak's admin event log.

What the Standards Require

This is not speculative architecture. The security requirements are being codified in standards that will be auditable:

OWASP AISVS 1.0 (releasing June 2026 in Vienna) includes:

• Requirement 10.2.9: Agents MUST authenticate using cryptographically bound identity credentials, not bearer tokens
• Requirement 10.4.11: MCP servers MUST sign tool responses with unique nonce and timestamp for origin, integrity, and freshness verification
• Requirement 10.6.4: MCP security controls MUST enforce fail-closed semantics

The OpenAPI Extensions Registry includes x-agent-trust for declaring agent authentication schemes in API specifications, enabling API providers to specify trust requirements in their OpenAPI documents.

ATTP (draft-sharif-attp) provides the framework. MCPS (draft-sharif-mcps-secure-mcp) provides the MCP binding. AEBA (draft-sharif-aeba) provides the behavioural analytics that feed trust scoring.

Three IETF drafts. One stack. Standards-track, not proprietary.

The Gap in the Market

Every major payment network has announced agent payment capabilities. None of them have shipped a trust framework.

Stripe's MPP authenticates the API key. Mastercard's Agent Pay validates the token. Visa's Intelligent Commerce checks the credential. FedNow processes the payment. ACH generates the file. But between "this agent is authenticated" and "this payment should execute," there is nothing.

That gap is where agents will fail. Not because the identity was wrong, but because the trust was never evaluated, the limits were never enforced, the counterparty was never screened, and the audit trail was never created.

We built the stack that fills that gap. It is open, standards-based, and composable with whatever identity and payment infrastructure you already run.

The question was never whether agents would make payments. It was whether we would have the infrastructure to trust them when they do.

---

Raza Sharif is CEO of CyberSecAI Ltd, author of "Breach 20/20", and a CISSP/CSSLP. He maintains the ATTP, MCPS, and AEBA IETF drafts, the x-agent-trust OpenAPI extension, and contributes to OWASP AISVS. Contact: [e-mail]