Saltar al contenido principal
Un agente no tiene que filtrar datos para hacerte daño. Simplemente puede gastar — un bucle de reintento martilleando un modelo caro, una instrucción inyectada por prompt que abre en abanico mil llamadas a herramienta, o una clave API filtrada acumulando inferencia hasta que llega la factura. Esto es denegación de cartera: el ataque es el coste en sí. A diferencia de una denegación de servicio clásica, el gateway sigue en pie y cada solicitud parece individualmente legítima — el daño es el gasto agregado. OrcaRouter te da tres techos independientes que todos se sitúan delante del modelo upstream, así que ninguna ruta descontrolada individual puede disparar tu factura sin límite.

​
1. La amenaza de denegación de cartera a la IA

Un incidente de denegación de cartera usualmente se rastrea a una de tres formas:
Un agente reintenta la misma herramienta que falla o re-planifica en un bucle ajustado, re-pagando por tokens en cada pasada. No se requiere malicia — una condición de parada mala es suficiente.
Una inyección de prompts dirige al agente a spamear una herramienta o emitir solicitudes sobredimensionadas, multiplicando el gasto por turno.
Una clave termina en algún lugar que no debería — un .env commiteado, un notebook compartido — y un atacante ejecuta inferencia en tu cuenta hasta que el gasto se nota.
La defensa es la misma en los tres casos: un techo duro que el atacante no puede sortear con palabras, aplicado en el gateway, no en el código de tu agente.

​
2. Techo de coste por ejecución con cap_cost

El veredicto cap_cost del Firewall es un interruptor de circuito para bucles descontrolados. Lo autoras como una regla con un tope en centavos por ejecución; el motor suma el gasto acumulado de la ejecución del agente y, una vez que la ejecución cruza el tope, resuelve el veredicto a deny — cada llamada a herramienta posterior en esa ejecución se bloquea. cap_cost es un techo previo al despacho: evalúa antes de que la llamada llegue a la herramienta, así que detiene la siguiente llamada cara en vez de reembolsar una ya hecha. Un tope típico para todo sobre cada herramienta: 
{
  "priority": 50,
  "label": "cap runaway spend at $5 per run",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
Por debajo del tope la llamada se permite; por encima, la ejecución se deniega con un HTTP 400 firewall_blocked — marcado como skip-retry, así que el bucle no puede martillear alrededor de la denegación. El techo es por ejecución de agente y sumado a través de toda la política de tu espacio de trabajo, así que una conversación descontrolada no puede sangrar en el presupuesto de otra.
cap_cost lee el gasto en curso de tus logs de solicitud. Mantén la captura de logs de solicitud activada para el espacio de trabajo para que el resumen de gasto-en-curso tenga filas que sumar — de lo contrario la estimación de gasto previo es conservadoramente 0 y el tope no puede ver lo que una ejecución ya costó.
Ver la referencia de reglas del Firewall para el lenguaje de coincidencia completo y dónde se sitúa cap_cost entre los otros veredictos.

​
3. Presupuesto duro por clave con credit_limit_usd

cap_cost acota una sola ejecución. Para acotar una clave — cada ejecución que emite — establece credit_limit_usd en la clave API. Es un techo duro en USD sobre el gasto de por vida de esa clave: el gateway lo convierte en la cuota restante de la clave, y una vez que la clave ha gastado su asignación, las llamadas de relay posteriores se rechazan por crédito insuficiente. 0 significa ilimitado. Emparéjalo con los otros alcances de la clave para que una clave filtrada esté acotada en cada eje a la vez:

credit_limit_usd

Techo duro de gasto en USD para la clave (0 = ilimitado).

expired_time

Marca de tiempo de auto-expiración (-1 = nunca). Una clave de vida corta acota la ventana de radio de explosión.

allow_ips

Fija la clave a IPs de origen conocidas — una clave filtrada es inútil fuera de la red.

model_limits

Restringe la clave a modelos específicos, así que no puede alcanzar los más caros en absoluto.
Da a cada agente su propia clave de alcance estrecho con un credit_limit_usd que nunca debería exceder legítimamente. El límite es el presupuesto, no una conjetura sobre el comportamiento del atacante — incluso una clave totalmente comprometida se detiene en el techo.
Configura todo esto desde el editor de claves de la consola (o la API de token) bajo tu sesión — estos son ajustes de clave, no llamadas de relay. Solo las solicitudes de inferencia /v1/* usan la clave sk-orca-... en sí. Editar el límite surte efecto en la siguiente solicitud de la clave; sin redespliegue.

​
4. Captura el pico que no predijiste: anomalías de coste

Un tope estático detiene el gasto que anticipaste. La detección de anomalías del Firewall captura el gasto que no. Aprende la forma normal de uso de herramientas de cada espacio de trabajo contra una línea base de hora-de-la-semana (un promedio móvil de 14 días) y muestra desviaciones en un feed legible por Member:
AnomalíaQué marca
burn_spikeCoste para una herramienta muy por encima de su coste de línea base aprendido — la señal de denegación de cartera.
rate_spikeVolumen de llamadas muy por encima de la línea base — abanicos e inundaciones.
retry_loopLa misma herramienta con los mismos argumentos repitiéndose en una ventana ajustada — el bucle descontrolado clásico.
Así “esta herramienta quemó 40× su coste habitual esta hora” resalta incluso cuando cada llamada individual fue permitida por la política. Puedes posponer (snooze) una anomalía hasta 7 días mientras investigas.
La detección de anomalías es tu alerta temprana; cap_cost y credit_limit_usd son los frenos duros. Observa el feed para descubrir dónde vive tu gasto real, luego escribe un tope alrededor de él.

​
5. Juntándolo todo

Apila los tres para que un descontrolado nunca llegue a la factura:
ControlAlcanceCuándo se dispara
Regla cap_costUna ejecución de agenteEl gasto acumulado de la ejecución cruza el tope en centavos
credit_limit_usdUna clave, de por vidaEl gasto total de la clave alcanza su techo en USD
burn_spike / retry_loopEspacio de trabajo, aprendidoEl gasto o el patrón de repetición se desvía de la línea base
Una línea base práctica: un cap_cost por ejecución sobre *, un credit_limit_usd en cada clave de agente, y el hábito de revisar el feed de anomalías. Lanza una nueva política cap_cost en modo shadow primero — registra [shadow] would deny sin bloquear — para que puedas dimensionar el tope contra tráfico real antes de que muerda.
cap_cost y el feed de anomalías acotan las llamadas a herramienta y ejecuciones que cruzan el gateway. Una herramienta que un agente ejecuta enteramente dentro de su propio proceso nunca llega al motor. Enruta las llamadas a herramienta mediadas por modelo y MCP a través del gateway — y da a cada clave un credit_limit_usd — para que el techo se mantenga sin importar cómo el agente itere.

​
6. Amenazas relacionadas

La denegación de cartera rara vez llega sola — el bucle que quema tu presupuesto a menudo es impulsado por algo upstream:
  • Inyección de prompts — las instrucciones inyectadas son un disparador común para el abanico y el spam de herramientas.
  • Agencia excesiva — un agente con demasiada latitud tiene más formas de gastar.
  • Llamadas a herramienta peligrosas — el mismo plano de reglas del firewall acota qué puede hacer una herramienta, no solo cuánto cuesta.
  • El modelo de amenazas — dónde encaja el coste descontrolado en la superficie de ataque agéntica completa.

Visión general del Firewall

Veredictos, detección de anomalías, niveles de autonomía y observabilidad.

Claves y políticas con alcance

Cómo se componen los límites de clave, los guardrails y las políticas de firewall por clave.