cap_cost, y por qué
audit es el valor por defecto desde el que empiezas.
Para dónde viven los veredictos en la gramática de reglas ver
Reglas del Firewall; para elegir un veredicto
por defecto al crear una política ver
Crear y adjuntar.
1. Los seis veredictos de regla
Una regla produce exactamente uno de seis veredictos. Autóralos en el editor de reglas de la consola; el motor recorre las reglas en orden de prioridad y gana la primera coincidencia.allow — deja pasar la llamada, registrada
allow — deja pasar la llamada, registrada
La llamada procede intacta. Aún aterriza en el
feed de eventos como un
allow, así
que mantienes un rastro de auditoría sin bloquear nada. Úsalo como un
permiso explícito en una política defecto-deny.audit — permite, pero lo registra para revisión
audit — permite, pero lo registra para revisión
Resultado de tráfico idéntico a
allow, pero la llamada se marca como
algo que quisiste observar. Este es también el valor sobre el que
aterriza el veredicto por defecto de fábrica — observa todo, no
bloquea nada, hasta que estés listo para aplicar.deny — bloquea la llamada
deny — bloquea la llamada
La llamada nunca llega a la herramienta. En la superficie
inbound el
relay devuelve HTTP 400 con el código de error firewall_blocked,
nombrando la herramienta y la razón; en la superficie mcp vuelve como
un error de herramienta para que el modelo pueda reaccionar. Ver
cómo se ve un bloqueo.sanitize — redacta argumentos, luego reenvía
sanitize — redacta argumentos, luego reenvía
Redacta las subcadenas coincidentes de los argumentos de la llamada a
herramienta (un secreto o PII que el agente puso en un campo
command o
body) y reenvía la llamada limpia. Redacta solo argumentos — nunca el
contenido que una herramienta devuelve. En la superficie inbound aún no
hay argumentos en tiempo de llamada, así que sanitize escala a un
deny. Ver
sanear respuestas.pending_approval — retiene para un humano
pending_approval — retiene para un humano
Convierte la llamada en una revisión fuera de banda. El relay devuelve
HTTP 400 con el código
firewall_approval_pending y un id de
aprobación; la llamada no llega a la herramienta. Un revisor lo resuelve
en la consola o vía callback de webhook, y el agente reenvía con una
cabecera de aprobación de un solo uso. Ver
aprobaciones.cap_cost — deniega una vez que se cruza un techo de gasto
cap_cost — deniega una vez que se cruza un techo de gasto
Un interruptor de circuito de coste — autorado como una regla pero
resuelto a
allow o deny en tiempo de evaluación. Ver
§3 y
limitar coste.El modo shadow aplana la aplicación. En
modo shadow, cada veredicto de
aplicación (
deny, sanitize, pending_approval y un cap_cost que
resolvió a deny) se degrada a audit y la razón se prefija con [shadow] would …. Lanza una política de aplicación de esta forma y observa el feed
de eventos antes de cambiarla a vivo.2. El veredicto por defecto
El veredicto por defecto (default_verdict en la política) es lo que la
política hace cuando ninguna regla coincide con una llamada a
herramienta. Es el piso de tu postura, y a diferencia de un veredicto de
regla acepta solo tres valores:
default_verdict | Cuando ninguna regla coincide… |
|---|---|
audit (por defecto) | Permite la llamada, pero la registra. El lugar seguro para empezar. |
allow | Permite y registra, sin registro de revisión. |
deny | Bloquea cualquier cosa que una regla no permita explícitamente — una postura defecto-deny. |
audit: observa cada llamada a
herramienta y no bloquea nada hasta que añades reglas de aplicación. Los tres
veredictos exclusivos de regla — sanitize, pending_approval y cap_cost
— no pueden ser un valor por defecto; un veredicto por defecto es un
fallback general, y esos veredictos solo tienen sentido acotados a una
coincidencia específica.
3. cap_cost se resuelve a allow o deny
cap_cost es el único veredicto que no es lo que aparece en tus
eventos. Autoras una regla con un techo cap_cost_cents, pero en tiempo de
evaluación el motor lo resuelve a un allow o deny concreto antes de
que el evento se registre — así que el
feed de eventos nunca lleva un veredicto
cap_cost literal, solo el allow/deny que el agente realmente vio.
El techo es por ejecución de agente: el motor compara el gasto acumulado
de la ejecución contra tu tope.
- Bajo el tope → resuelve a
allow. (Internamente esto se trata como no coincidente, así que la evaluación continúa a la siguiente regla en vez de dejar quecap_costgane por primera coincidencia como una concesión.) - Sobre el tope → resuelve a
deny, con una razón que nombra el total de la ejecución frente al tope. Este es el resultado terminal, de interruptor de circuito.
4. Cómo se elige un veredicto
Para cualquier llamada a herramienta, la resolución es la misma sin importar qué veredicto gane:1. Resolver la política
1. Resolver la política
El gateway elige la política adjunta a la clave que llama
(
firewall_policy_id), o el valor por defecto del espacio de trabajo —
ver
resolución.2. Recorrer reglas, gana la primera coincidencia
2. Recorrer reglas, gana la primera coincidencia
Las reglas se ejecutan en orden
priority ASC. La primera regla cuya
superficie, glob de herramienta, cláusulas de argumentos opcionales y
alcance de egress opcional todos coinciden produce el veredicto.3. Ninguna coincidencia → el veredicto por defecto
3. Ninguna coincidencia → el veredicto por defecto
Si ninguna regla coincide, aplica el
default_verdict de la política —
audit a menos que lo hayas cambiado.4. La aplicación de skill cabalga encima
4. La aplicación de skill cabalga encima
Si la llamada es propiedad de una
skill gobernada, una skill en modo
block fuerza un deny y una skill en modo quarantine escala cualquier
cosa por debajo de deny a pending_approval.5. Comportamiento de coste y reintento de un deny
Un veredicto del firewall en la superficieinbound se dispara antes de
la llamada al modelo upstream, así que un deny ahí no cuesta tokens de
modelo. El error se marca como skip-retry — reejecutar la misma llamada
bloqueada simplemente volvería a bloquear, así que el gateway le dice al
cliente que no la reintente.
Esto es distinto de un bloqueo de
guardrail, que examina el
texto de prompt/respuesta (PII, secretos) en vez de las acciones de
herramienta, y devuelve su propio error guardrail_blocked. Una solicitud
puede pasar por ambos planos.
Cada veredicto deja un rastro. Cada evaluación — allow, audit, deny, el
cap_cost resuelto, la aprobación retenida — se registra como un evento del
firewall, filtrable por veredicto, superficie, herramienta y ejecución. El
feed de eventos es cómo confirmas que una política está produciendo los
veredictos que esperas. Ver
registro de eventos y
analítica.
Dónde ir a continuación
Crear y adjuntar una política
Elige un veredicto por defecto y vincula una política a una clave.
Limitar coste
Autora un techo de gasto y cómo se resuelve por ejecución.
Modo shadow
Degrada cada veredicto de aplicación a audit mientras mides el impacto.
Referencia de reglas
El lenguaje de coincidencia completo detrás de un veredicto.