Saltar al contenido principal
Un agente autónomo de larga duración es lo más difícil de asegurar. Itera por su cuenta durante horas, elige sus propias herramientas, obtiene sus propias URLs y gasta tu dinero todo el tiempo. Los modos de fallo no son un solo prompt malo — son un bucle de reintento que quema $400 de noche, una llamada a herramienta que nunca revisaste, una clave que acuñaste para un experimento de una semana y que sigue funcionando seis meses después. Esta receta cablea cuatro controles alrededor de exactamente esa forma de agente. Configuras todos ellos en la consola (o la API REST) — el agente sigue llamando a https://api.orcarouter.ai/v1/... exactamente como antes.
¿Nuevo aquí? Aplica la línea base balanced primero y vigila lo que hace tu agente durante un día. Esta página es el siguiente paso: convertir la observación en aplicación para un agente que no puedes supervisar.

​
1. La receta del agente autónomo seguro

Un agente autónomo seguro necesita cuatro cosas que un chatbot no:

Un techo de coste duro

Una regla cap_cost deniega la ejecución una vez que su gasto acumulado cruza tu tope — el interruptor de circuito para un bucle que no se detiene.

Detección de picos

La detección de anomalías aprende la forma normal de hora-de-la-semana del agente y marca picos de tasa y coste que se escapan de las reglas estáticas.

Aprobación en las llamadas peligrosas

Un veredicto pending_approval retiene las llamadas a herramienta destructivas o irreversibles para un humano, en vez de confiar en que el agente sea cuidadoso.

Una clave que expira

Acota la clave del agente a una expiración y un techo de crédito para que un experimento olvidado no pueda ejecutarse — ni gastar — para siempre.
Cada uno mapea a una política de Firewall o a un campo de clave. Ninguno toca el código de tu agente.

​
2. Limita el coste de cada ejecución

Lo primero que un bucle descontrolado revienta es tu presupuesto. Una regla cap_cost es un techo de coste de verificación previa estricto: cuando coincide, el gateway estima el coste de la solicitud y deniega antes del despacho una vez que el gasto acumulado de la ejecución excedería el tope — así que una llamada por encima del presupuesto nunca alcanza al proveedor. El tope tiene alcance de ejecución. El gateway suma el gasto previo a lo largo de toda la ejecución del agente, así que una ejecución larga que ya ha quemado la mayor parte de su presupuesto se deniega incluso cuando la siguiente llamada individual es barata. Eso es lo que lo hace un interruptor de circuito en vez de un límite por solicitud. Añade una regla comodín a tu política de firewall: 
{
  "priority": 50,
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 1000
}
Esto limita la ejecución a $10 (cap_cost_cents está en centavos de USD). El veredicto resuelve a allow mientras está bajo presupuesto y a deny una vez que la estimación lo cruzaría. La mayoría de plantillas de firewall integradas (Coding, Support, RAG, Data, DevOps, Browser) incluyen un tope de coste por ejecución exactamente como este — aplica una y edita el tope.
La acumulación con alcance de ejecución necesita la captura de registro de solicitudes habilitada para el espacio de trabajo. Con ella apagada, el acumulado de gasto previo lee cero y el tope se degrada a solo por-solicitud — aún seguro, pero no capturará un goteo lento de 500 llamadas. Ver denial-of-wallet.

​
3. Detecta picos contra una línea base aprendida

Un tope detiene la catástrofe; la detección de anomalías captura lo raro antes de que se convierta en una. El Firewall aprende la forma normal de uso de herramientas de cada espacio de trabajo — un promedio móvil de 14 días agrupado por hora-de-la-semana, así que el tráfico de martes-14:00 se compara contra el historial de martes-14:00, no una media diaria plana — y expone las desviaciones en un feed legible por el visualizador:
Volumen de llamadas por herramienta puntuado contra la línea base aprendida. “143 llamadas a db.query en una hora contra una línea base de 8” resalta incluso cuando cada llamada individual está permitida.
La misma línea base, aplicada al gasto en vez del conteo — una ejecución que de repente quema mucho más de lo que esta hora suele hacer.
La firma de un agente autónomo atascado reintentando la misma llamada rota. Ver excessive-agency.
Un salto de herramienta a herramienta que este espacio de trabajo nunca ha hecho — la forma de un agente yendo a algún lugar nuevo.
El feed reporta nombres de herramienta, ids de token redactados y conteos — nunca argumentos en bruto. Leerlo está abierto a cualquier Member; un Developer+ puede posponer (snooze) el feed hasta 7 días mientras investiga. Empareja el feed con una regla cap_cost para que un pico que también está por encima del presupuesto sea detenido, no solo notado.

​
4. Retén las llamadas peligrosas para un humano

No puedes revisar cada llamada que hace un agente autónomo — pero puedes hacer que se detenga y pregunte antes del puñado que importa. Un veredicto pending_approval retiene una llamada a herramienta fuera de banda:
  1. El agente emite, digamos, una llamada payments.transfer. La regla coincide y el motor devuelve HTTP 400 firewall_approval_pending con un id de aprobación — la llamada nunca alcanza la herramienta.
  2. Un revisor la resuelve desde la consola (Developer+), o tu propio sistema la resuelve vía un callback de webhook firmado con HMAC a POST /api/v1/firewall/approvals/:id/callback.
  3. El agente hace polling de GET /api/v1/firewall/approvals/:id; una vez aprobado reenvía la llamada original con una cabecera X-OrcaRouter-Firewall-Approval de un solo uso, y el gateway la deja pasar esa única vez.
Una regla que retiene escrituras a una superficie destructiva: 
{
  "priority": 20,
  "tool_name_glob": "payments.*",
  "verdict": "pending_approval"
}
Lanza esto en modo shadow primero — pending_approval se degrada a audit, así que ves qué llamadas retendrían sin bloquear realmente a tu agente. Apaga shadow cuando el feed se vea bien.

​
5. Dale al agente una clave que expira

El control que sobrevive a toda política es la clave misma. Un agente autónomo debería obtener una clave con alcance, no la tuya por defecto. Establece estos campos cuando la acuñas (consola → keys, o la API de tokens):
CampoEstablécelo enPor qué
expired_timeuna marca de tiempo UnixEl experimento termina; la clave muere con él. -1 significa nunca — no lo uses aquí.
credit_limit_usdun techo en dólaresUn tope de gasto en la clave independiente del tope de ejecución. 0 significa ilimitado.
firewall_policy_idtu política de arribaVincula las reglas cap_cost + aprobación a esta clave.
allow_ipslas IPs de egress del agenteUna clave filtrada es inútil desde cualquier otro lugar.
Establece también una etiqueta environment, para que la clave — y todo lo que hace en Events y Matches — sea atribuible a este agente. Una clave que expira, con tope de crédito y fijada por IP es la última línea: incluso si toda política fuera de algún modo eludida, el radio de explosión está acotado por tiempo y dólares.
La configuración de claves es una acción de consola / API de tokens y está restringida por rol. Leer el texto plano de una clave de gateway de firewall requiere Admin+.

​
6. Júntalo todo

Un agente autónomo endurecido acaba con una política de firewall y una clave con alcance:
CapaControlCaptura
PresupuestoRegla cap_cost, con alcance de ejecuciónBucles descontrolados, denial-of-wallet
ComportamientoFeed de anomalías (rate / burn / retry / novel)Lo raro-pero-permitido
Confianzapending_approval en herramientas destructivasAcciones irreversibles
AlcanceClave que expira, con tope de crédito y fijada por IPClaves olvidadas o filtradas
Autora juntas las reglas de presupuesto y aprobación, establece un tope por ejecución con reglas del firewall, y lee el resto de la referencia del Firewall para superficies, veredictos y observabilidad. Para las amenazas relacionadas contra las que esta receta defiende, ver excessive-agency, dangerous-tool-calls y denial-of-wallet.

​
7. Próximos pasos

Endurecer un agente MCP

Gobierna un agente que alcanza herramientas a través de servidores MCP.

Detener la exfiltración

Reglas de egress para un agente que obtiene sus propias URLs.

Modos de aplicación

Observe → shadow → enforce, el lanzamiento seguro.

Reglas del firewall

El lenguaje de coincidencia detrás de cada regla de arriba.