Saltar al contenido principal
AprenderGlosarioPolítica de gasto del agente
GLOSARIO

Qué es una política de gasto de agente.

DEFINICIÓN

Una política de gasto de agente es el conjunto de reglas adjuntas a una billetera de agente de IA que gobiernan lo que se le permite pagar al agente - una asignación por período (diaria, semanal o mensual), un límite por transacción y una ventana de validez de fechas de inicio y fin. La política se establece en el panel y se aplica a nivel de API de billetera (fuera del alcance manipulable del agente), verificada en cada pago antes de que se liquide. La API la expone solo para lectura.

POR QUÉ ES IMPORTANTE

Lo único que hace que el pago autónomo sea seguro.

Sin una política de gasto, darle a un agente una billetera es darle a un LLM acceso ilimitado a un chequera denominada en dólares. Dos modos de fallo son inevitables. El primero es el bucle descontrolado: el planificador de un agente se queda atascado reintentando una herramienta de pago y quema el saldo del espacio de trabajo en minutos. El segundo es la inyección de aviso: un atacante convence al agente de pagar una billetera controlada por el atacante bajo la apariencia de parecer una tarea normal.

Una política de gasto limita ambos modos de fallo por construcción. El bucle descontrolado agota la asignación por período y se detiene. El pago inyectado excede el límite por transacción (o la asignación restante) y nunca se liquida. El agente no necesita ser perfectamente confiable porque la billetera se niega a liquidar cualquier cosa fuera de la política. Esta es la diferencia entre 'agentes que pagan' siendo utilizables en producción y siendo un experimento.

CÓMO FUNCIONA

Configura una vez, evalúa cada llamada.

  1. Configura. El usuario humano establece la política en el panel de control: una asignación por período, un límite por transacción y una ventana de validez opcional (fechas de inicio y fin). La API expone la política como solo lectura; los cambios se registran en auditoría.
  2. Vincular a la identidad. La política se adjunta a la identidad de pago del agente. Los espacios de trabajo de múltiples agentes tienen una política por agente, además de un límite a nivel de espacio de trabajo que limita la suma.
  3. Evalúa en cada intención. Cuando el agente envía una intención de pago (típicamente impulsada por una respuesta 402), la API de la billetera ejecuta la política: verifica el límite por transacción, verifica la asignación restante por período, verifica la ventana de validez.
  4. Liquidar o rechazar. Si todas las verificaciones pasan, la billetera liquida el pago y decrementa la asignación restante. Si alguna verificación falla, la billetera rechaza el pago (excede un límite o cae fuera de la ventana) y no liquida.
  5. Auditoría. Cada intención aceptada y cada intención rechazada se registra con la decisión de política adjunta. El humano puede revisar el registro en cualquier momento para ver qué intentó el agente y qué permitió la política.

La política es el mismo tipo de objeto independientemente de cuántos agentes compartan la billetera. Las políticas por agente aíslan los presupuestos de manera limpia; una política de espacio de trabajo a nivel de padre aplica un techo estricto en todos los agentes hijos combinados.

EJEMPLOS

Tres formas de política que vemos en producción.

EJEMPLO 1

Límite diario por agente con techo de llamada única

Un agente de investigación tiene un límite de $5/día y un techo de $0.50 por llamada. Puede hacer 10 llamadas de $0.50, o 100 llamadas de $0.05, o cualquier combinación bajo el total diario. Una factura sorpresa de $2.00 de una herramienta es rechazada en el techo de la llamada antes de que se liquide. Ambos límites se aplican simultáneamente; el más estricto gana por llamada.

EJEMPLO 2

Cierre solo de recepción

Un agente que solo recibe pagos tiene su asignación y límite por transacción establecidos en cero. Puede ser pagado por cualquiera en cualquier momento, pero no puede enviar USDC en absoluto - independientemente de lo que su código o una inyección de prompt intenten hacerle. Establecer ambos límites en cero es la defensa más fuerte contra la redirección de pagos impulsada por inyección de prompt: la billetera rechaza cada pago saliente.

EJEMPLO 3

Ventana de compromiso con límite de tiempo

A un agente contratista se le otorga un permiso de gasto que es válido solo por la ventana de 30 días del compromiso (una fecha de inicio y fin). Dentro de la ventana puede gastar hasta su asignación semanal; después de la fecha de finalización, el permiso expira y no se liquidan más pagos, sin que nadie tenga que recordar desactivarlo.

Preguntas frecuentes

Tres preguntas comunes.

¿Cuál es la diferencia entre una política de gasto y un límite de tasa?

Un límite de tasa gobierna el conteo de llamadas; una política de gasto gobierna el valor en dólares a través de las llamadas. Un agente puede estar limitado a 100 llamadas por minuto, pero aún así arruinar su espacio de trabajo si esas llamadas cuestan $1 cada una y el agente las realiza durante una hora. Una política de gasto limita la exposición en dólares independientemente del conteo de llamadas. Los dos controles se complementan entre sí: los límites de tasa previenen la denegación de servicio en el tiempo de ejecución del agente, las políticas de gasto previenen la denegación de fondos en la billetera del agente.

¿Dónde se aplica la política - en el código del agente o en la billetera?

En la billetera, en la capa de la API de pago. Hacerlo en el código del agente significaría que cualquier ataque de inyección de comandos que eluda el planificador del agente también elude el presupuesto. Al hacerlo cumplir en la API de la billetera, la política está fuera del alcance manipulable del agente. El agente envía una intención de pago; la billetera evalúa la intención contra la política; la billetera ya sea liquida o rechaza. El agente no puede aumentar sus propios límites.

¿Puede el usuario ajustar la política en medio de la ejecución si un gasto legítimo está siendo rechazado?

Sí, pero solo el usuario humano (o otro humano autorizado) puede ajustarlo; nunca el agente mismo. El panel de administración de la billetera expone el editor de políticas; los cambios se registran en auditoría con quién y cuándo. Esto mantiene al agente dentro de los límites por defecto mientras le da al humano la anulación que necesita cuando surge un gasto legítimo mayor. El agente no tiene forma de pedir 'por favor, aumenta mi límite' dentro de su bucle de planificación, porque eso derrotaría el propósito de tener un límite.
Última revisión: 2026-05-15. Publicado bajo CC BY 4.0.

Dale a tu agente un sobre de presupuesto.

Asignaciones por período y límites por transacción, establecidos en el panel de control. Gratis para comenzar.