Aprobación humana de los pagos de agentes con Slack

Los topes deciden lo que un agente de IA puede pagar por su cuenta. Aun así, algunos pagos deberían esperar a una persona: la primera llamada a un vendedor nuevo, un dataset que cuesta dólares en lugar de céntimos, cualquier cosa por encima de lo que dejarías gastar a un script sin vigilancia. Esta guía configura la aprobación reforzada (step-up) en Burnbound: los pagos en un umbral en USD o por encima esperan a una persona, recibes un mensaje en Slack y el agente sigue cuando lo apruebas, sin que se le cobre dos veces. Los ejemplos usan pagos a APIs x402; un reembolso de Stripe con el gateway de acciones espera igual, con stripe_refund en lugar de fetch_paid. Un pago con tarjeta no puede esperar: por encima del umbral se rechaza.

Cómo funciona una aprobación

El agente llama a fetch_paid. Todas las reglas permiten el precio del vendedor, pero está en el umbral de aprobación del agente o por encima.
No se firma nada. fetch_paid devuelve status: "pending_approval" con un approvalId, el amountUsd, el thresholdUsd, el host y una idempotencyKey.
Burnbound publica un mensaje en tu canal de Slack y, si lo activaste, envía un email a los owners de la organización.
Una persona abre el pago en la bandeja de aprobaciones del panel (importe, host, payee y red) y lo aprueba o lo deniega.
El agente consulta get_approval_status con el approvalId. Cuando está approved, vuelve a llamar a fetch_paid con la misma url, method, headers, body e idempotencyKey, y el pago se firma y se envía.

La clave de idempotencia une el reintento a la compra aprobada. Un reintento con la misma clave nunca crea un segundo pago; una petición distinta con esa clave falla con idempotency_key_reused.

Paso 1: Activa la aprobación reforzada en el agente

Abre el agente en el panel, ve a su pestaña Política, activa la aprobación reforzada (step-up) y fija el umbral en USD. Guarda. El cambio crea una versión nueva de la política y se aplica al siguiente pago del agente.

Elige el umbral según lo que compra el agente normalmente. Si paga la búsqueda de Exa a 0.007 USDC o CoinGecko a 0.01 USDC por llamada, un umbral de 0.25 USD deja pasar las llamadas habituales y frena cualquier cosa rara. Los precios de otros vendedores están en el catálogo de APIs x402.

El umbral se comprueba después de todas las demás reglas. Un pago que supera el máximo por pago o el tope diario se deniega directamente; nunca se manda a aprobación. Así que el orden es: primero las reglas, después la persona y después la firma.

Paso 2: Crea un webhook entrante de Slack

Burnbound avisa a Slack con un webhook entrante, que publica en un canal. En Slack (guía oficial):

Crea una app de Slack en api.slack.com/apps en tu workspace.
Abre Incoming Webhooks y activa Activate Incoming Webhooks.
Pulsa Add New Webhook to Workspace, elige el canal y autoriza.
Copia la URL del webhook. Empieza por https://hooks.slack.com/services/.

Trata la URL como un secreto: quien la tenga puede publicar en ese canal.

Paso 3: Añade el webhook en Burnbound

En el panel, abre Organización → Avisos de aprobación. Solo un owner de la organización puede cambiarlo.

Pega la URL del webhook y guárdala. Burnbound solo acepta URLs https://hooks.slack.com/services/…, guarda la URL cifrada y no la vuelve a mostrar (solo sus últimos caracteres).
Pulsa Enviar prueba y comprueba que el mensaje de prueba llega al canal.
Si quieres, activa el email a los owners de la organización.

Los avisos de Slack forman parte del plan Team, y cada organización nueva tiene 30 días de Team gratis. La bandeja de aprobaciones y el email a los owners funcionan en todos los planes, así que en Free sigues recibiendo un email y apruebas los pagos en el panel.

Qué contiene el mensaje de Slack

Cada pago pendiente publica un mensaje con:

el importe y el umbral, por ejemplo Aprobación pendiente: 0.50 USD (umbral de 0.25 USD);
el método, el host, el destinatario y el recurso que nombró el vendedor (en un reembolso, el cargo, el cliente y lo que la política sabía de ellos);
las reglas que lo retuvieron;
lo que el agente declaró con la petición (su context, por ejemplo un ticket), bajo Declarado por el agente, sin verificar;
cuándo caduca la aprobación;
los botones Aprobar, Rechazar y Abrir en el panel.

Aprobar y Rechazar solo abren la aprobación en el panel con esa decisión preseleccionada: nada se aprueba ni se rechaza hasta que lo confirmas allí, con tu sesión de owner o admin. Un member o un lector ve los botones desactivados. El host, el recurso y lo que declara el agente no son nuestros, así que todo se muestra como texto plano: ni un vendedor ni un agente pueden dar formato, mencionar ni poner enlaces en tu canal. Solo se muestran los enlaces https, como texto y con el host al que llevan; cualquier otro enlace se oculta. El email lleva el mismo contenido y los mismos botones. Los avisos tienen un límite por organización (20 mensajes de Slack y 10 emails por hora); un pago nunca avisa dos veces.

Paso 4: Deja que el agente espere y reintente

La mayoría de los agentes gestionan pending_approval por su cuenta cuando el resultado de la herramienta lo explica, pero una línea en tus instrucciones lo hace fiable:

If fetch_paid returns pending_approval, tell me the amount and host, then poll
get_approval_status every 30 seconds. When it is approved, call fetch_paid again
with exactly the same url, method, headers, body and idempotencyKey. If it is
denied or expired, do not retry.

get_approval_status devuelve pending, approved, denied o expired, y además intentId cuando el pago aprobado ya se hizo. Una clave del agente solo ve las aprobaciones de su propio agente.

Plazos y límites

Qué	Valor
Una aprobación pendiente caduca a los	15 minutos por defecto. Un owner puede fijar entre 5 minutos y 24 horas en los mismos ajustes.
Tras la aprobación, el agente debe reintentar	En 10 minutos como máximo.
Aprobaciones pendientes a la vez	5 por agente y 20 por organización. A partir de ahí: `approval_queue_full`.
Una aprobación denegada	`approval_denied` al reintentar. No la reintentes.
Una aprobación caducada	`approval_expired`. Llama a `fetch_paid` sin `idempotencyKey` para volver a pedirla.

Pruébalo en Base Sepolia

Con un agente en Base Sepolia y demo.burnbound.dev en sus hosts permitidos, fija el umbral en 0.50 USD y pide al agente que traiga https://demo.burnbound.dev/report, que cuesta 0.50 USDC de prueba. Recibes pending_approval, un mensaje en Slack y una entrada en la bandeja. Apruébalo y el reintento del agente se paga. El vendedor de demostración solo vende en Base Sepolia, por USDC de prueba sin valor.

Relacionado

Todos los límites que se aplican antes de la aprobación: Cómo limitar el gasto de un agente de IA.
El flujo de aprobación como referencia: Conceptos.
Reembolsos que esperan a una persona: Gateway de acciones: reembolsos de Stripe.
¿Nuevo en Burnbound? Empieza por los Primeros pasos.

Aprobación humana de los pagos de agentes con Slack

Cómo funciona una aprobación

El agente llama a fetch_paid. Todas las reglas permiten el precio del vendedor, pero está en el umbral de aprobación del agente o por encima.
No se firma nada. fetch_paid devuelve status: "pending_approval" con un approvalId, el amountUsd, el thresholdUsd, el host y una idempotencyKey.
Burnbound publica un mensaje en tu canal de Slack y, si lo activaste, envía un email a los owners de la organización.
Una persona abre el pago en la bandeja de aprobaciones del panel (importe, host, payee y red) y lo aprueba o lo deniega.
El agente consulta get_approval_status con el approvalId. Cuando está approved, vuelve a llamar a fetch_paid con la misma url, method, headers, body e idempotencyKey, y el pago se firma y se envía.

La clave de idempotencia une el reintento a la compra aprobada. Un reintento con la misma clave nunca crea un segundo pago; una petición distinta con esa clave falla con idempotency_key_reused.

Paso 1: Activa la aprobación reforzada en el agente

Paso 2: Crea un webhook entrante de Slack

Burnbound avisa a Slack con un webhook entrante, que publica en un canal. En Slack (guía oficial):

Crea una app de Slack en api.slack.com/apps en tu workspace.
Abre Incoming Webhooks y activa Activate Incoming Webhooks.
Pulsa Add New Webhook to Workspace, elige el canal y autoriza.
Copia la URL del webhook. Empieza por https://hooks.slack.com/services/.

Trata la URL como un secreto: quien la tenga puede publicar en ese canal.

Paso 3: Añade el webhook en Burnbound

En el panel, abre Organización → Avisos de aprobación. Solo un owner de la organización puede cambiarlo.

Pega la URL del webhook y guárdala. Burnbound solo acepta URLs https://hooks.slack.com/services/…, guarda la URL cifrada y no la vuelve a mostrar (solo sus últimos caracteres).
Pulsa Enviar prueba y comprueba que el mensaje de prueba llega al canal.
Si quieres, activa el email a los owners de la organización.

Qué contiene el mensaje de Slack

Cada pago pendiente publica un mensaje con:

el importe y el umbral, por ejemplo Aprobación pendiente: 0.50 USD (umbral de 0.25 USD);
el método, el host, el destinatario y el recurso que nombró el vendedor (en un reembolso, el cargo, el cliente y lo que la política sabía de ellos);
las reglas que lo retuvieron;
lo que el agente declaró con la petición (su context, por ejemplo un ticket), bajo Declarado por el agente, sin verificar;
cuándo caduca la aprobación;
los botones Aprobar, Rechazar y Abrir en el panel.

Paso 4: Deja que el agente espere y reintente

La mayoría de los agentes gestionan pending_approval por su cuenta cuando el resultado de la herramienta lo explica, pero una línea en tus instrucciones lo hace fiable:

If fetch_paid returns pending_approval, tell me the amount and host, then poll
get_approval_status every 30 seconds. When it is approved, call fetch_paid again
with exactly the same url, method, headers, body and idempotencyKey. If it is
denied or expired, do not retry.

get_approval_status devuelve pending, approved, denied o expired, y además intentId cuando el pago aprobado ya se hizo. Una clave del agente solo ve las aprobaciones de su propio agente.

Plazos y límites

Qué	Valor
Una aprobación pendiente caduca a los	15 minutos por defecto. Un owner puede fijar entre 5 minutos y 24 horas en los mismos ajustes.
Tras la aprobación, el agente debe reintentar	En 10 minutos como máximo.
Aprobaciones pendientes a la vez	5 por agente y 20 por organización. A partir de ahí: `approval_queue_full`.
Una aprobación denegada	`approval_denied` al reintentar. No la reintentes.
Una aprobación caducada	`approval_expired`. Llama a `fetch_paid` sin `idempotencyKey` para volver a pedirla.

Pruébalo en Base Sepolia

Relacionado

Todos los límites que se aplican antes de la aprobación: Cómo limitar el gasto de un agente de IA.
El flujo de aprobación como referencia: Conceptos.
Reembolsos que esperan a una persona: Gateway de acciones: reembolsos de Stripe.
¿Nuevo en Burnbound? Empieza por los Primeros pasos.