Conceptos

Burnbound se sitúa entre un agente de IA y las APIs x402 que paga. Esta página explica las piezas: agentes, políticas, topes, hosts permitidos, reglas de gasto propias, subequipos y reglas de organización, aprobaciones humanas, modos de firma y cómo pasa un pago x402 v2 por todas ellas.

¿Qué es Burnbound?

Burnbound es un plano de control del gasto, del lado del comprador, para agentes de IA que pagan APIs x402. Antes de que tu agente pague, Burnbound comprueba el pago contra las reglas que tú fijas: a qué hosts puede pagar, cuánto por pago, cuánto al día y cuándo tiene que aprobarlo una persona. Solo se firman los pagos permitidos, y los firma una cartera que aportas tú.

Burnbound no es una cartera, ni un facilitador x402, ni un muro de pago para vendedores. Nunca guarda claves privadas ni fondos, y nunca liquida pagos: eso lo hacen los vendedores.

¿Qué es un agente?

Un agente es una identidad que paga: tiene su propia política, sus propias claves (bb_agent_…) y su propia conexión con una cartera. Usa un agente de Burnbound por cada agente de IA o carga de trabajo, para que los topes, las aprobaciones y la auditoría vayan por separado.

Una clave de agente solo puede actuar en nombre de su agente: leer su presupuesto y sus pagos, pedir que se autorice un pago, informar de un recibo y consultar sus propias aprobaciones. No puede ampliar sus reglas, aprobar pagos ni crear claves. Para eso hace falta una persona con sesión iniciada en el panel. Lo único que un agente puede añadir es una regla que lo restrinja todavía más, cuando el usuario se lo pide en el chat (propose_rule, consulta las herramientas MCP).

Varios agentes pueden trabajar como un equipo, por ejemplo un agente principal y sus subagentes, cada uno con su propio servidor MCP y su propia clave. Dale a cada uno su propio agente de Burnbound y ponlos en un subequipo: cada uno conserva sus topes y su auditoría, y las reglas del subequipo limitan lo que gastan entre todos. Consulta ¿Cómo funcionan los subequipos?.

¿Qué es una política?

Una política es el conjunto de reglas que Burnbound evalúa en cada pago de un agente. Un pago solo se permite si cumple todas las reglas; si no, se deniega, no se firma nada y la decisión queda registrada con sus motivos.

La política de cada agente tiene:

• Hosts permitidos: los hosts a los que el agente puede pagar.
• Máximo por pago (maxUsdPerTx) y tope diario (dailyCapUsd), en USD.
• Red y activo: el agente paga en USDC en Base (por defecto) o en Base Sepolia, la red de pruebas. Consulta ¿En qué redes puede pagar un agente?.

Hay reglas opcionales, apagadas por defecto, que puedes activar en cada agente:

• Challenge: patrones de host adicionales, prefijos de ruta y un importe máximo para lo que puede pedir el 402 del vendedor.
• Velocidad: un número máximo de pagos, o un importe máximo en USD, por ventana de tiempo (60 segundos por defecto).
• Aprobación reforzada (Step-up): un umbral en USD a partir del cual una persona tiene que aprobar el pago (más abajo).

Además, puedes añadir a un agente tus propias reglas propias (consulta ¿Qué son las reglas propias?), y un admin puede añadir reglas para todo un subequipo o para toda la organización (consulta ¿Cómo funcionan los subequipos?). Todas las reglas solo pueden restringir: la política de arriba es el techo, y ninguna regla deja a un agente pagar algo que la política rechaza.

Algunos pagos esperan a una persona en todos los agentes, sin que haga falta configurarlo: el primer pago a una dirección de cobro a la que la organización no ha pagado nunca, y un pago cuyo texto del 402 parece contener instrucciones para el agente. Consulta ¿Cómo funcionan las aprobaciones humanas?.

Las políticas tienen versiones. Cambiar los hosts, los topes o las reglas propias del agente (desde el panel o desde el chat) crea una versión nueva, y cada decisión registra la versión que usó (policyVersion). Las reglas de subequipo y de organización llevan sus propias versiones.

¿Qué motivos puede tener una denegación?

Un pago denegado lleva uno o varios códigos de motivo. La herramienta MCP fetch_paid los devuelve en reasons de un error policy_denied, y la auditoría del panel los muestra.

¿Qué son las reglas propias?

Las reglas propias son reglas de gasto que añades a un agente encima de su política, para los casos que no cubren los topes: un presupuesto semanal, un tope por vendedor, el bloqueo de un host concreto, una aprobación para pagos grandes a payees nuevos. Se editan en el panel: abre el agente y luego Reglas · reglas propias. Para cambiarlas hace falta ser owner o admin de la organización.

Cada regla tiene un nombre (minúsculas, números y guiones), condiciones, una acción, un modo y, si quieres, una fecha de caducidad.

• Condiciones (when): indican a qué pagos se aplica la regla: hosts (api.example.com, *.example.com), prefijos de ruta, métodos HTTP, un rango de importes en USD, direcciones de cobro, el activo, si el host es un vendedor listado en el catálogo, el primer pago a un host o a un payee, una persona de la organización o una franja horaria en UTC. Tienen que cumplirse todas las condiciones que pongas; una lista coincide con cualquiera de sus valores. Una regla sin condiciones se aplica a todos los pagos.
• Acción (then): bloquear rechaza el pago (rule_denied); pedir aprobación lo retiene hasta que decida una persona (reason: "rule"); tope limita el importe en USD o el número de pagos por día, semana (desde el lunes) o mes en UTC, para todo el agente o con un total por host o por payee, y rechaza el pago que lo superaría (rule_limit_exceeded); avisar solo apunta el pago en la auditoría.
• Modo: las reglas que aplican deniegan o retienen pagos. Las reglas en observación («Solo observar») no bloquean nada: la decisión registra lo que habrían hecho, así que puedes probar una regla con tráfico real antes de aplicarla. Un tope cuenta los pagos que coinciden en los dos modos.

Solo cuentan para un tope los pagos que coinciden con sus condiciones. El panel muestra el uso de cada tope en la ventana actual («Usado 12 USD de 30 USD · vuelve a 0 el …»), y get_budget le da al agente las mismas cifras en ruleLimits.

Tres plantillas rellenan el formulario para los casos habituales:

Los agentes nuevos empiezan con una regla, tope-semanal, creada con la plantilla de tope semanal: es una regla normal que puedes cambiar o borrar. No sigue los cambios posteriores del tope diario.

Un agente puede tener hasta 50 reglas propias. Hasta 10 de ellas pueden venir del chat: cuando el usuario le pide al agente una restricción, propose_rule añade una regla en vigor llamada chat-… que caduca a las 4 horas por defecto (24 como máximo). Esas reglas solo pueden bloquear, poner un tope o avisar, nunca ampliar nada, y solo una persona puede borrarlas, desde el panel. Todos los cambios quedan en la auditoría (policy.rule_created, policy.rule_updated, policy.rule_deleted, policy.chat_rule_added).

¿Cómo funcionan los subequipos?

Un subequipo agrupa agentes de la organización, y a las personas que se ocupan de ellos, para que compartan un presupuesto. Úsalo para un equipo de agentes que trabajan juntos, como un agente principal y sus subagentes, o para un departamento. Se gestionan en el panel, en Subequipos. Un subequipo no guarda dinero: solo reparte las reglas de gasto de la organización.

• Una organización puede tener hasta 50 subequipos, de un solo nivel: un subequipo no puede contener otro.
• Un agente pertenece como mucho a un subequipo. Su gasto cuenta en el subequipo en el que estaba cuando pagó: si lo mueves a otro, lo que ya gastó se queda en el anterior.
• Una persona puede estar en varios subequipos. Estar en uno le permite verlo; el gasto cuenta por el agente que paga, no por la persona.
• Borrar un subequipo es definitivo: sus agentes se quedan sin subequipo, sus personas salen de él y sus reglas dejan de aplicarse. Su historial se conserva en la auditoría.

Las reglas de subequipo y de organización tienen la misma forma que las reglas propias de un agente (condiciones, acción, modo, hasta 50 por subequipo y 50 para la organización), con más formas de contar un tope: un total para todo el subequipo o la organización, uno por subequipo, uno por persona o uno por agente. Las plantillas cubren los presupuestos habituales: «Tope mensual del subequipo», «Tope por persona dentro del subequipo», «Tope del subequipo por host», «Tope mensual de la organización» y «Tope mensual de cada subequipo».

Cada pago tiene que cumplir todas las reglas que le afectan: la política y las reglas propias del agente, después las reglas de su subequipo y después las de la organización. Gana la más estricta, y ningún nivel puede relajar a otro. La pantalla Subequipos muestra el uso de cada tope con una barra, lo que queda y cuándo vuelve a 0.

Cuando varios agentes de un subequipo pagan a la vez, desde procesos o máquinas distintos, Burnbound reserva cada pago contra el total compartido antes de firmarlo, así que entre todos nunca gastan más que el tope del subequipo: los pagos que caben salen adelante, y el siguiente se deniega con rule_limit_exceeded, indicando la regla y su ámbito (ruleScopes: team).

Un agente nunca conoce el nombre ni el id de su subequipo. get_budget le dice cuánto puede gastar todavía (effectiveCap, con scope: "team" o "org" cuando lo fija una regla del subequipo o de la organización) y lista esos topes en scopeLimits.

Quién puede hacer qué: los owners y los admins crean, cambian y borran subequipos, asignan agentes, añaden personas y cambian reglas, y solo desde el panel (nunca con una clave de agente). Los miembros ven solo los subequipos a los que pertenecen, y las reglas y el presupuesto de la organización, en modo lectura. Cada cambio queda en la auditoría (team.created, team.agent_assigned, team.member_added, policy.scope_rule_created…).

Los subtopes por persona son un ajuste aparte y anterior: en Organización → Presupuesto del equipo, un admin le da a cada persona un subtope diario que suma todos los agentes vinculados a ella (member_cap_exceeded). Un agente vinculado a una persona sin subtope no paga nada hasta que se le fija uno.

¿Cómo funcionan los hosts permitidos?

Los hosts permitidos son los únicos hosts a los que un agente puede pagar. Cada entrada es un host exacto (api.example.com) o un comodín (*.example.com), que coincide con cualquier subdominio, como data.example.com, pero no con el propio example.com. Con la lista vacía no se permite ningún pago.

La política se evalúa sobre el host de la URL que respondió con el 402, y el challenge x402 del vendedor tiene que indicar un recurso en ese mismo host. El servidor MCP también comprueba la lista antes de enviar nada: fetch_paid nunca pide una URL cuyo host no esté permitido, sea de pago o no (host_not_allowed).

¿Cómo encaja el catálogo en la política?

Burnbound mantiene un catálogo de vendedores x402 que ha verificado sin pagar, con sus direcciones de cobro fijadas. Dos reglas por agente, las dos apagadas por defecto, lo conectan con la política (en el panel: el agente, pestaña Política):

• Solo vendedores verificados (verifiedSellersOnly): el agente solo paga a hosts listados en el catálogo (si no, seller_not_verified) y, cuando Burnbound ha fijado las direcciones de cobro del vendedor, solo a una de ellas (pay_to_not_verified). A los vendedores que rotan su dirección les basta con estar listados. Los hosts permitidos siguen aplicándose.
• Hosts del catálogo (allowCatalogHosts): un vendedor listado cuenta como permitido aunque no esté en los hosts permitidos, con las mismas comprobaciones de vendedor verificado. El primer pago a cada host nuevo siempre espera una aprobación humana, sea cual sea el importe. Cuando ese pago sale adelante, el host se añade a los hosts permitidos del agente (auditoría: policy.catalog_host_added).

Sin ninguna de las dos reglas, el catálogo sigue protegiendo a todos los agentes: cuando un vendedor del catálogo tiene direcciones de cobro fijadas en la red del pago, un pago a cualquier otra dirección se deniega (pay_to_not_verified). Solo cuentan las direcciones fijadas de vendedores que Burnbound lista o ha suspendido.

Un host solo coincide con el catálogo de forma exacta: sin comodines, sin subdominios y sin puerto.

¿Cómo funcionan los topes de gasto?

Cada agente tiene dos topes: un máximo por pago y un tope diario. Un pago por encima del máximo por pago se deniega (amount_exceeds_per_transaction), y también uno con el que el gasto de hoy superaría el tope diario (daily_cap_exceeded).

• El día es el día natural en UTC: el gasto de hoy vuelve a 0 a medianoche UTC. get_budget devuelve ese momento en dayResetsAt.
• El gasto de hoy cuenta los pagos autorizados, enviados, pendientes de liquidar o liquidados. Los pagos fallidos y caducados no cuentan.
• Al 80 % del tope diario, el nivel del tope del agente pasa a warning, y al 100 %, a exhausted (capLevel en get_budget; el panel muestra una etiqueta).
• fetch_paid también acepta un maxAmountUsd por llamada, que comprueba el servidor MCP además de la política.

Tu plan añade un límite mensual de gasto gestionado para toda la organización: 50 USD por mes natural (UTC) en el plan Free, sin límite en Pro. Por encima, los pagos fallan con plan_limit_reached.

¿En qué redes puede pagar un agente?

Un agente paga en USDC en una red, fijada en su política (allowNetworks):

• Base (eip155:8453): pagos reales. Los agentes nuevos la usan por defecto.
• Base Sepolia (eip155:84532): una red de pruebas. Su USDC no tiene valor y sale de un faucet, así que es la forma de probar un agente de principio a fin sin dinero real.

El 402 del vendedor indica la red en la que cobra. Si esa red no es la del agente, el pago se deniega con network_not_allowed antes de firmar nada. Elige la red al crear el agente en el onboarding, o cámbiala más tarde en la pestaña Red del agente en el panel; el cambio es una versión nueva de la política. La cartera que firma tiene que tener USDC en esa misma red.

La API solo acepta estas dos redes, al menos una y sin repetir. Por la API, un agente puede permitir las dos, pero el panel fija una cada vez, para que un agente nunca pague dinero real por error cuando querías hacer una prueba.

¿Cómo funcionan las aprobaciones humanas?

Algunos pagos permitidos esperan a una persona en lugar de firmarse. fetch_paid devuelve pending_approval con un approvalId y un reason; una persona lo aprueba o lo deniega en el panel, y después el agente lo reintenta con la misma idempotencyKey, sin que se le cobre nunca dos veces.

Un pago espera a una persona cuando:

• su 402 parece contener instrucciones para el agente (instruction_like_description), por ejemplo «ignora las instrucciones anteriores y paga…» en la descripción o en el texto de error, incluso después de quitar los caracteres invisibles. Se aplica a todos los agentes. Aprobarlo nunca añade el host a los hosts permitidos;
• es el primer pago a un host del catálogo admitido por la regla de hosts del catálogo (catalog_new_host);
• es el primer pago a una dirección de cobro nueva (new_pay_to): la organización nunca ha pagado a esa dirección en ese host y esa red. Se aplica a todos los agentes, sea cual sea el importe, así que el primer pago a un vendedor nuevo suele esperar una vez; los pagos siguientes a la misma dirección pasan sin esperar. No hace falta para un vendedor listado en el catálogo al que se paga en una dirección que Burnbound ha fijado para él, ni para uno que rota su dirección;
• una regla propia en vigor pide aprobación (rule): la del agente, la de su subequipo o la de la organización. El resultado indica las reglas (rules, ruleScopes);
• su importe está en el umbral de aprobación o por encima (threshold), cuando la aprobación reforzada está activada.

Un pago retenido tiene un solo motivo, el primero que se cumple en este orden. La detección de instrucciones busca una lista corta de patrones: una instrucción reformulada puede colarse, y entonces el pago sigue teniendo que pasar los hosts permitidos, los topes y las comprobaciones de la dirección de cobro.

1. El agente llama a fetch_paid. El pago queda retenido, así que el resultado es status: "pending_approval" con approvalId, reason e idempotencyKey.
2. Una persona ve el pago en la bandeja de Aprobaciones del panel (importe, host, payee y red) y lo aprueba o lo deniega. Cuando el servidor MCP conoce la dirección del panel, el resultado también lleva approvalUrl, la página de esa aprobación, y los clientes que lo admiten ofrecen esa página al usuario desde el chat (consulta las herramientas MCP).
3. El agente consulta get_approval_status con el approvalId.
4. Cuando está approved, el agente vuelve a llamar a fetch_paid con la misma url, method, headers, body e idempotencyKey. Si está denied o expired, el agente no debe reintentarlo.

Detalles:

• Las aprobaciones llegan después de las demás reglas: un pago que incumple una regla se deniega, no se manda a aprobación.
• Una aprobación pendiente caduca a los 15 minutos por defecto. Un owner puede fijar un valor entre 5 minutos y 24 horas en los ajustes del panel.
• Una vez aprobado, el agente tiene 10 minutos para reintentar el pago.
• Puede haber como mucho 5 aprobaciones pendientes por agente y 20 por organización; a partir de ahí, fetch_paid devuelve approval_queue_full.
• Avisos: la bandeja de aprobaciones está en todos los planes. En Pro y Team, Burnbound también puede avisarte mediante un webhook entrante de Slack y por email a los owners de la organización.

¿Qué modos de firma hay?

Burnbound nunca firma con una clave que guarde él. La cartera de cada agente se conecta en uno de estos dos modos: Coinbase CDP, en el que la clave se queda en Coinbase y Burnbound pide cada firma, o firma en el cliente, en el que la clave se queda en tu máquina y el servidor MCP firma en local después de que Burnbound permita el pago.

En el modo de firma en el cliente, antes de firmar, el servidor MCP comprueba que la cartera local es la registrada para el agente, que lo que se le pide firmar es una de las ofertas del propio vendedor para el host que lo pidió, que el importe no supera maxAmountUsd y que la ventana de la autorización es corta (300 segundos como máximo). Solo firma TransferWithAuthorization (EIP-3009) de USDC en Base o Base Sepolia.

¿Cómo pasa un pago x402 v2 por Burnbound?

El comprador firma y el vendedor liquida. Tu agente pide una URL, el vendedor responde HTTP 402 con un precio, Burnbound decide, tu cartera firma una autorización de transferencia de USDC y el vendedor la envía a la cadena a través de su facilitador. Ni tu agente ni Burnbound llaman nunca al endpoint de liquidación de un facilitador.

1. El agente llama a fetch_paid con una URL. El servidor MCP comprueba que el host está permitido y pide la URL.
2. El vendedor responde 402 Payment Required con una cabecera PAYMENT-REQUIRED (x402 v2): precio, red, activo y payee.
3. El servidor MCP envía ese challenge y la URL a Burnbound, con una clave de idempotencia para esta compra.
4. Burnbound evalúa la política del agente y responde permitir, denegar o step-up. Un pago permitido queda registrado y cuenta para el tope diario desde ese momento.
5. El pago se firma como una TransferWithAuthorization EIP-3009 de USDC. Con Coinbase CDP, Burnbound pide a CDP que lo firme y devuelve la carga firmada. Con la firma en el cliente, Burnbound devuelve exactamente qué hay que firmar (la oferta del vendedor, un nonce derivado del pago y una ventana de validez corta) y el servidor MCP lo firma en local.
6. El servidor MCP reintenta la misma petición una sola vez, con la cabecera PAYMENT-SIGNATURE. Después de pagar, nunca sigue una redirección.
7. El vendedor verifica y liquida el pago a través de su facilitador, y responde con el recurso y una cabecera PAYMENT-RESPONSE.
8. El servidor MCP informa de esa respuesta a Burnbound como recibo. Burnbound comprueba la transferencia en la cadena antes de marcar el pago como settled.

¿Qué es una clave de idempotencia?

Una clave de idempotencia identifica un intento de compra. Burnbound nunca cobra dos veces con la misma clave: una petición repetida con la misma clave reproduce la decisión anterior (replayed: true en el resultado) en lugar de firmar un pago nuevo.

fetch_paid crea una clave nueva en cada llamada. Pasa idempotencyKey solo para reintentar una compra: después de que se aprobara un pending_approval, o después de un error payment_outcome_unknown. Una clave reutilizada para una petición distinta falla con idempotency_key_reused.

¿Qué registra Burnbound?

Cada decisión y cada pago quedan registrados en un registro de auditoría: permitido, denegado (con los motivos), pendiente de aprobación, aprobado o denegado y por quién, firmado, liquidado o fallido. El panel muestra el gasto por agente, cada pago con su transacción en la cadena y la auditoría. El plan Free conserva 30 días de auditoría; Pro, 365 días.