Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
A diferencia de la sesión de navegador de un usuario humano, los agentes de IA autónomos no pueden usar cookies. Es necesario diseñar directamente una arquitectura de tokens sin estado basada en M2M. En lugar de manejar directamente los datos del titular de la tarjeta, se conecta la especificación de pago delegado del protocolo de comercio de agentes para eliminar la carga del sistema. Con el flujo de credenciales de cliente de OAuth 2.1, el token de autorización comercial se limita de 15 a 60 minutos, y el token de delegación de pago a corto plazo se permite por un máximo de 10 minutos. Al utilizar esta estructura, los elementos de evaluación de la auditoría de seguridad PCI DSS v4.0.1 se reducen de SAQ D a SAQ A, lo que acorta el período de aprobación de la auditoría en 2 semanas.
Para evitar solicitudes falsificadas de agentes externos, se debe construir un middleware de firma de mensajes HTTP RFC 9421. Cuando un agente envía una solicitud de pago, se le obliga a firmar el hash del cuerpo y la marca de tiempo con una clave privada Ed25519. El gateway del backend ejecuta tres líneas de defensa en orden. Primero, si la tolerancia de la marca de tiempo de la firma supera los 60 segundos, se rechaza con un 401 Unauthorized. Segundo, el nonce único de la solicitud se almacena en Redis durante 8 minutos para evitar ataques de repetición. Tercero, se aplican una lista blanca de IP públicas y firmas de verificación de bots web para bloquear el acceso de scrapers anormales.
Los grandes modelos de lenguaje sufren alucinaciones al leer páginas HTML no estructuradas o campos de API ambiguos. Se debe exponer un esquema JSON estructurado con un significado claro. Al crear la API de catálogo, se siguen tres reglas. Primero, para evitar errores de cálculo de punto flotante, todos los precios unitarios se expresan como una unidad monetaria mínima en formato de entero en wones y se fuerza la unidad monetaria. Segundo, en lugar de permitir que el agente combine arbitrariamente IDs de productos superiores y opciones, las unidades de pedido finales disponibles para compra se aplanan en SKUs únicos. Tercero, en lugar de simples banderas booleanas, se especifican enumeraciones de estado de inventario y la cantidad máxima de pedido. Esta estructura reduce a 0 por ciento la tasa de malinterpretación de información de productos por parte del agente.
Para evitar que el agente destruya la E/S de la base de datos lanzando sondeos indiscriminados, se colocan solicitudes condicionales HTTP y una capa de caché. Se emite un valor de hash que se actualiza solo cuando cambian los datos del catálogo mediante la cabecera ETag. Cuando el agente vuelve a consultar con la cabecera If-None-Match y no hay contenido modificado, se devuelve un 304 Not Modified sin cuerpo. Adicionalmente, se configuran cabeceras de control de caché en el gateway de API y en los nodos edge de CDN para procesar el caché a corto plazo. Si ocurre una situación de excepción, se envía un cuerpo de error que sigue el formato de detalles de problema de la especificación RFC 9457, incluyendo conjuntamente una bandera de no reintento y el precio unitario actual válido para inducir a que el agente entregue directamente una retroalimentación de lenguaje natural precisa al usuario.
Dado que el razonamiento interno del agente es probabilístico, es un gran error confiar ciegamente y aprobar el monto final de pago enviado por el cliente. El backend ignora el total enviado por el agente, recibe únicamente la lista de SKUs objetivo del pedido y las cantidades, y vuelve a calcular el monto basándose en los datos maestros de la base de datos interna del servidor. Al codificar el middleware de verificación de integridad de transacciones del lado del servidor, se verifica que la cantidad sea un entero positivo mayor o igual a 1 para evitar ataques de manipulación utilizando cantidades negativas, y se aplica un bloqueo de reserva de inventario pesimista para deducirlo temporalmente con una sesión de expiración de 15 minutos. A través del proceso en el que el servidor contrasta directamente los montos, si hay una discrepancia de incluso 1 won, se revierte la transacción y se devuelve un error 409 Conflict para evitar por completo las pérdidas monetarias causadas por alucinaciones.
Para detectar pagos duplicados en caso de que ocurra un tiempo de espera de red (timeout), se introduce un motor de bloqueo de idempotencia distribuida basado en la especificación de borrador de IETF. Al llamar a la API de aprobación de pago, se toma un bloqueo distribuido atómico en Redis utilizando la clave de idempotencia pasada por el agente y se realiza una verificación de huella digital del cuerpo. Si la solicitud anterior se está procesando, se arroja un 409 Conflict; si es un reintento de una solicitud ya finalizada, no se vuelve a pasar por la aprobación del PG y se reenvía inmediatamente el cuerpo de respuesta almacenado. Al adjuntar este middleware de idempotencia, se pueden prevenir fundamentalmente los accidentes de pago duplicados que ocurren durante fallas de red y reducir las consultas de servicio al cliente en más del 80 por ciento.
Si un atacante explota los permisos de un agente comprometido repitiendo continuamente micro-pagos o la creación de carritos de compras, se agotan por completo las comisiones del PG y los recursos de infraestructura. Se deben establecer umbrales estrictos de limitación de tráfico. El backend utiliza un algoritmo de registro de ventana deslizante basado en Sorted Set de Redis para limitar la búsqueda en el catálogo a un máximo de 120 veces por minuto por agente, la creación de carritos de compras a un máximo de 3 sesiones activas y 20 veces por minuto, y la aprobación de delegación de pago a un máximo de 5 veces por minuto por agente. Las solicitudes que superan el umbral otorgan inmediatamente un error 429 Too Many Requests y un tiempo de espera para reintentar, defendiendo contra ataques de agotamiento de recursos.
Para evitar condiciones de carrera por concurrencia (race conditions), los límites de transacciones diarias por agente no se procesan en la base de datos, sino mediante un script de Lua en Redis. Justo antes de llamar a la API de aprobación de pago, se invoca un script de Lua atómico que se ejecuta en una sola transacción para aplicar la reserva de deducción de saldo en tiempo real. Si se supera el límite, se devuelve un 403 Forbidden sin siquiera intentar la comunicación con la pasarela de pagos (PG), y si la aprobación del PG falla, se devuelve el presupuesto mediante una transacción de compensación. Si la tasa de fallas de pago anormales se acumula 3 veces consecutivas en 1 minuto o el volumen de solicitudes supera el límite, se configura una clave de bloqueo global en Redis, se cancelan por la fuerza las sesiones de carrito activas, se activa una alerta de administrador y se revoca el token de inmediato.
