Skip to main content
Caso de uso

Un agente puede pagar, pero nunca en silencio: cinco controles deterministas entre la intención y el dinero

Un proveedor de servicios de pago deja que un agente de soporte emita reembolsos por Wero — la cartera de la European Payments Initiative, liquidada sobre SEPA Instant. El caso legítimo, 240,00 €, supera todas las comprobaciones y aun así termina en HTTP 403: el agente no puede pagar, puede solicitar. Después la misma conversación lleva una instrucción oculta de 48.500,00 €. El modelo cae en la trampa — y se mueven 0,00 €.

5
controles deterministas en la ruta de llamada — ninguno es un prompt
0,00 €
movidos por la inyección de prompt de 48.500 € — denegado es denegado
Una vez
vale una aprobación: ligada a servidor y herramienta, consumida tras la llamada
Ilustración renderizadaEscenario simuladoNo se transfieren fondos reales
Demo en alemán, inglés y español
El punto de partida

La pregunta no es si un agente puede iniciar un pago — cualquier pila de LLM lo hace desde hace años. La pregunta es qué ocurre cuando se convence al modelo. Para un banco, un agente cuyo límite vive en un prompt de sistema no es un producto sino un hallazgo de auditoría: mover ese límite solo requiere un prompt mejor.

Cómo funciona
1

El caso legítimo termina en 403

Un reembolso de 240,00 €: la vinculación del agente, la lista de herramientas permitidas y el control de políticas pasan, la clase de seguridad marca la herramienta como destructiva — y la llamada termina en HTTP 403 con una solicitud de aprobación. El agente puede solicitar, no pagar.

2

La inyección de prompt muere en el control de políticas

La misma conversación, con una instrucción oculta de 48.500,00 €. La demo muestra con honestidad que el modelo cae. El control de políticas evalúa importe, divisa y corredor con los argumentos reales — determinista y fail-closed — y deniega. Como se sitúa antes del control de aprobación, no se crea ninguna fila pendiente: ningún clic puede levantar el límite, y la interfaz muestra un bloque rojo sin botón de confirmación.

3

Aprobación, ejecución, evidencia

Una persona aprueba. La aprobación genera un token de un solo uso ligado exactamente a este servidor y esta herramienta, con caducidad. Solo entonces se mueve el dinero. Una segunda llamada necesita una nueva aprobación, porque el token está consumido. Después actúan el límite de tasa y el registro de auditoría.

Dentro del producto
Demo real del sistemaEscenario simuladoNo se transfieren fondos reales
El resultado
5
controles deterministas en la ruta de llamada — ninguno es un prompt
0,00 €
movidos por la inyección de prompt de 48.500 € — denegado es denegado
Una vez
vale una aprobación: ligada a servidor y herramienta, consumida tras la llamada
Basado en

Es real: los cinco controles y su orden, la semántica del token de un solo uso con vinculación a servidor y herramienta, la propiedad fail-closed y el hecho de que una llamada denegada por la política no crea ninguna fila de aprobación. Es ejemplo: el proveedor de servicios de pago y todos los importes, nombres e IBAN — el conector de la demo es un sandbox y no mueve dinero real. Junto a él existe un conector Wero real en Integraciones; no hay una API pública de Wero, por eso habla ISO 20022 pain.001 contra la pasarela de su banco o PSP y lee pain.002 para el estado. Permanece inactivo hasta que se configuren endpoint, ordenante y credenciales.

Solicitar demo

Véalo en su propio caso de uso.

30 minutos, adaptados a su sector, marcos e integraciones. Se va con un escenario concreto, no con un bucle de ventas.