Protocolo AP2: Pagos y Comercio Autónomo para Agentes de IA

1. La Crisis de Autorización en el Comercio Agéntico

La infraestructura financiera global que sustenta Internet (redes Visa/Mastercard, transferencias SEPA, protocolos EMV 3D-Secure y pasarelas de pago) fue diseñada bajo una premisa inquebrantable: un ser humano está frente a una pantalla. El usuario visualiza un carrito de compra, introduce manualmente un número de tarjeta con su código CVV, y confirma su identidad resolviendo un desafío biométrico (TouchID/FaceID) o introduciendo un código SMS de un solo uso (OTP).

En el paradigma de los agentes de IA autónomos, esta arquitectura humana colapsa por completo:

• Invocación Desatendida (Human-Not-Present): Un agente de operaciones que detecta un pico de demanda en servidores a las 3:00 AM y necesita contratar instancias temporales en la nube o comprar tokens de inferencia no tiene dedos para poner su huella digital ni teléfono para recibir SMS.
• El Antipatrón del Secreto Compartido: Proporcionar a un modelo de lenguaje una tarjeta de crédito corporativa o una clave secreta estática de Stripe en su system prompt o variables de entorno es una aberración de seguridad: basta un ataque de Prompt Injection indirecto o una alucinación del modelo para drenar los fondos de la empresa.
• Incertidumbre Legal y Repudio del Comerciante: Los comercios y procesadores de pago necesitan garantías matemáticas y jurídicas de que el usuario final realmente delegó esa compra específica a ese agente, con límites de gasto claros y sin posibilidad de repudio fraudulento.

Para resolver este dilema surge el Agent Payments Protocol (AP2): un estándar abierto y marco criptográfico impulsado originalmente por Google en alianza con gigantes de la industria financiera y tecnológica (Mastercard, PayPal, American Express, Coinbase y Worldline) y formalmente transferido a la FIDO Alliance para su gobernanza neutral dentro de sus grupos de trabajo de Agentic Authentication y Payments.

2. La Topología de Confianza: Los 5 Roles Cardinales de AP2

AP2 establece un modelo de seguridad por capas donde las responsabilidades financieras y operativas están estrictamente segregadas entre cinco actores independientes:

Ver en alta resolución (SVG vectorial)

Especificación Topológica en Texto (Esquema RFC / ASCII para Agentes & Docs)

┌────────────────────────────────────────────────────────────────────────┐
│           1. TRUSTED SURFACE DEL USUARIO (FIDO2 / Passkeys)            │
│      Enclave Seguro Hardware • Presupuesto, MCC y Caducidad (TTL)      │
└───────────────────────────────────┬────────────────────────────────────┘
                                    │ Mandato 1: Intent Mandate (W3C VC)
                                    ▼
┌────────────────────────────────────────────────────────────────────────┐
│                 2. SHOPPING AGENT (Agente Comprador IA)                │
│    Descubre catálogo y negocia orden sin conocer jamás el PAN/CVV      │
└───────────────┬────────────────────────────────────────┬───────────────┘
                │ Mandato 2: Cart Mandate                │ Presenta Intent + Cart
                │ (Negociación vía A2A)                  │ Recibe Payment Mandate
                ▼                                        ▼
┌──────────────────────────────┐        ┌────────────────────────────────┐
│  3. MERCHANT AGENT (Vendedor)│        │ 4. CREDENTIAL PROVIDER (Banco) │
│  Firma Cart Mandate inmutable│        │ Valida Cart <= Intent y emite  │
└───────────────┬──────────────┘        │ Mandato 3: Payment Mandate     │
                │                       │ (DPAN atado al SHA256 cartHash)│
                │ Remite Orden +        └────────────────┬───────────────┘
                │ Cadena de Mandatos                     │ Liquidación Token
                ▼                                        ▼
┌────────────────────────────────────────────────────────────────────────┐
│         5. MERCHANT PAYMENT PROCESSOR (Pasarela Adquirente)            │
│   Verifica firmas no repudiables y liquida en Visa / SEPA / ERC-4337   │
└────────────────────────────────────────────────────────────────────────┘

3. La Cadena Criptográfica de Mandatos (The Mandate Chain)

El núcleo técnico diferencial de AP2 es que nunca viajan datos sensibles de tarjetas (PAN/CVV) a través del agente. En su lugar, el protocolo introduce una cadena secuencial de tres Mandatos Criptográficos expresados como Verifiable Credentials (W3C VCs / JSON-LD):

// 1. Intent Mandate: El usuario autoriza gastar hasta 100€ en computación cloud
{
  "@context": ["https://www.w3.org/ns/credentials/v2", "https://ap2-protocol.org/contexts/v1"],
  "type": ["VerifiableCredential", "IntentMandate"],
  "issuer": "did:key:z6MkuUserTrustedPhoneEnclave",
  "issuanceDate": "2026-10-23T12:00:00Z",
  "credentialSubject": {
    "mandateId": "mandate_intent_99182",
    "payer": "did:ion:user_felix_villanueva",
    "authorizedAgent": "did:key:z6MktQuijotechDevOpsAgent",
    "spendingLimits": {
      "maxAmount": { "currency": "EUR", "value": 100.00 },
      "allowedCategories": ["CLOUD_SERVICES", "SAAS_APIS"],
      "allowedMerchants": ["*.aws.amazon.com", "hetzner.com", "cloudflare.com"]
    },
    "validUntil": "2026-10-23T18:00:00Z",
    "purpose": "Aprovisionamiento temporal de nodos RISC-V para pruebas de estrés"
  },
  "proof": {
    "type": "JsonWebSignature2020",
    "verificationMethod": "did:key:z6MkuUserTrustedPhoneEnclave#fido-key",
    "jws": "eyJhbGciOiJFUzI1NiIsImNyaXQiOls...K98B"
  }
}

// 2. Payment Mandate: Credential Provider emite el token atado al hash del carrito
{
  "@context": ["https://www.w3.org/ns/credentials/v2", "https://ap2-protocol.org/contexts/v1"],
  "type": ["VerifiableCredential", "PaymentMandate"],
  "issuer": "did:web:bank.quijotech.com",
  "credentialSubject": {
    "paymentTokenId": "tok_virtual_dpan_88231",
    "cartHash": "sha256:4a8b792c3d1f0e9...88a",  // Inviolable: atado a ese carrito exacto
    "authorizedAmount": { "currency": "EUR", "value": 45.50 },
    "merchantId": "hetzner.com",
    "oneTimeToken": "dpan_4111_XXXX_XXXX_9921",
    "settlementRail": "CARD_NETWORK_TOKEN"
  },
  "proof": {
    "type": "JsonWebSignature2020",
    "verificationMethod": "did:web:bank.quijotech.com#cert",
    "jws": "eyJhbGciOiJSUzI1NiIs...99xF"
  }
}

Si un atacante interceptase el token oneTimeToken en tránsito e intentase utilizarlo para comprar en otra tienda o alterar el importe a 200 €, la pasarela adquirente rechazaría inmediatamente el cobro porque el cartHash y el merchantId no coincidirían con los registros del banco emisor.

4. Modos de Ejecución: Human-Present vs. Human-Not-Present

AP2 está diseñado para gobernar dos realidades operativas radicalmente distintas:

A. Modo Supervisado (Human-Present)

En este escenario, el Shopping Agent investiga diferentes opciones, negocia con proveedores y prepara el carrito. Cuando la orden está lista, el agente utiliza el Protocolo AG-UI emitiendo un evento RUN_FINISHED con outcome.type = "interrupt". La pantalla del usuario despliega el resumen del pedido y el humano autoriza la transacción mediante autenticación biométrica WebAuthn/Passkey en su Trusted Surface, generando el mandato en milisegundos.

B. Modo Totalmente Autónomo (Human-Not-Present)

En operaciones M2M (Machine-to-Machine) o AIOps de infraestructura, el usuario firma previamente un Intent Mandate Abierto con un presupuesto temporal (ej. 50 € diarios para balanceo de tráfico o compra de datos IoT). El agente ejecuta de forma autónoma sin despertar al operador humano. Si el coste de una transacción superase el saldo restante del mandato abierto, el agente no falla a ciegas: pausa su ejecución y escala la decisión al canal humano a través de AG-UI.

5. Implementación Práctica: Validación Criptográfica en Python

El siguiente código demuestra cómo un Credential Provider implementa en Python la validación del IntentMandate del usuario frente al CartMandate presentado por el agente antes de liberar los fondos:

# ap2_credential_provider.py
import hashlib
import json
import time
from typing import Dict, Any

class AP2CredentialProvider:
    def __init__(self, bank_id: str):
        self.bank_id = bank_id

    def calculate_cart_hash(self, cart_data: Dict[str, Any]) -> str:
        """Calcula el hash canónico del carrito para evitar manipulación de precios o ítems."""
        canonical_json = json.dumps(cart_data, sort_keys=True)
        return hashlib.sha256(canonical_json.encode('utf-8')).hexdigest()

    def evaluate_and_issue_payment_mandate(
        self,
        intent_mandate: Dict[str, Any],
        cart_mandate: Dict[str, Any]
    ) -> Dict[str, Any]:
        """
        Valida que el carrito satisfaga estrictamente el mandato de intención
        pre-firmado por el usuario humano.
        """
        limits = intent_mandate["credentialSubject"]["spendingLimits"]
        cart_subject = cart_mandate["credentialSubject"]
        
        # 1. Verificación de vigencia temporal (TTL)
        now_iso = time.strftime('%Y-%m-%dT%H:%M:%SZ', time.gmtime())
        if now_iso > intent_mandate["credentialSubject"]["validUntil"]:
            raise ValueError("[AP2_ERR_EXPIRED] El Intent Mandate del usuario ha expirado.")

        # 2. Verificación de comercio permitido
        merchant_id = cart_subject["payee"]["merchant_id"]
        allowed = any(
            pattern.replace("*.", "") in merchant_id 
            for pattern in limits["allowedMerchants"]
        )
        if not allowed:
            raise ValueError(f"[AP2_ERR_UNAUTHORIZED_MERCHANT] Comercio no autorizado: {merchant_id}")

        # 3. Verificación de divisa e importe máximo
        cart_total = cart_subject["cart_total"]
        if cart_total["currency"] != limits["maxAmount"]["currency"]:
            raise ValueError("[AP2_ERR_CURRENCY_MISMATCH] Discrepancia de divisas.")

        if cart_total["value"] > limits["maxAmount"]["value"]:
            raise ValueError(
                f"[AP2_ERR_OVER_BUDGET] Carrito ({cart_total['value']}€) excede límite ({limits['maxAmount']['value']}€)."
            )

        # 4. Generación inmutable del Payment Mandate
        cart_hash = self.calculate_cart_hash(cart_subject)
        payment_mandate = {
            "type": ["VerifiableCredential", "PaymentMandate"],
            "issuer": f"did:web:{self.bank_id}",
            "issuanceDate": now_iso,
            "credentialSubject": {
                "paymentTokenId": f"tok_{hashlib.md5(now_iso.encode()).hexdigest()[:8]}",
                "referencesCartHash": cart_hash,
                "merchantId": merchant_id,
                "authorizedAmount": cart_total,
                "oneTimeNetworkToken": "tok_virtual_dpan_single_use_4421"
            },
            "status": "APPROVED"
        }
        return payment_mandate

# Prueba de ejecución
if __name__ == "__main__":
    cp = AP2CredentialProvider(bank_id="bank.quijotech.com")

    # Mandato firmado por el usuario: máximo 50.00 EUR en cloud
    sample_intent = {
        "credentialSubject": {
            "spendingLimits": {
                "maxAmount": {"currency": "EUR", "value": 50.00},
                "allowedMerchants": ["*.hetzner.com", "ovh.com"]
            },
            "validUntil": "2026-12-31T23:59:59Z"
        }
    }

    # Carrito presentado por el agente: 34.20 EUR en Hetzner
    sample_cart = {
        "credentialSubject": {
            "payee": {"merchant_id": "robot.hetzner.com"},
            "cart_total": {"currency": "EUR", "value": 34.20},
            "line_items": [{"item": "Cloud CX22", "price": 34.20}]
        }
    }

    payment_mandate = cp.evaluate_and_issue_payment_mandate(sample_intent, sample_cart)
    print("Pago Autorizado con Éxito bajo Protocolo AP2:")
    print(json.dumps(payment_mandate, indent=2))

6. El Cuarteto de Protocolos Agénticos: MCP, A2A, AG-UI y AP2

Con la consolidación de AP2, la arquitectura de ingeniería agéntica alcanza su madurez definitiva, completando un sistema modular donde cada protocolo resuelve un vector de comunicación especializado:

7. Neutralidad Financiera: Rieles Bancarios y Criptográficos

Una ventaja fundamental de AP2 es su agnosticismo respecto al riel de liquidación subyacente:

• Rieles Tradicionales (Cards & Banking): El Payment Mandate se traduce en un Network Token (Visa/Mastercard) de un solo uso o en una transferencia instantánea SEPA Request-to-Pay / FedNow, permitiendo la integración con el ecosistema bancario regulado sin fricción.
• Rieles Cripto y Web3 (Smart Contract Wallets): En entornos descentralizados, el Payment Mandate se materializa como una transacción sobre Account Abstraction (ERC-4337) o una firma de transferencia en stablecoins (USDC en redes L2 de bajo coste como Base o Arbitrum), garantizando liquidación atómica en milisegundos.