Saltar al contenido principal
Cuando lees un evento del firewall o una coincidencia de guardrail, la fila te dice qué decidió el gateway — deny, sanitize, [EMAIL]. Esta página es la tabla de búsqueda de esas palabras: qué significa cada una, qué le hace a la llamada y a dónde ir para la mecánica completa. Mantenla abierta mientras autoras reglas o haces triaje del feed de eventos. Dos planos de control producen dos vocabularios. El Firewall gobierna las acciones de herramienta y emite un veredicto. Guardrails examinan el texto de prompt y respuesta y emiten una acción más, en un mask, una etiqueta de enmascarado tipada. Nunca comparten una palabra — un guardrail nunca dice deny, un firewall nunca dice mask.
Este es un índice de referencia, no un tutorial. Para el caso de uso detrás de cada control ve Guardrails vs Firewall; para los cuerpos HTTP ve Códigos de error de seguridad.

​
1. El glosario de veredictos del firewall

Una regla del firewall (o el default_verdict de la política) resuelve cada llamada a herramienta a exactamente uno de estos seis veredictos. El motor recorre las reglas en orden de prioridad, gana la primera coincidencia, y hace fallback al valor por defecto si nada coincide.
La llamada procede a la herramienta. Aún se registra como un evento del firewall, así que aparece en Runs y en el feed de eventos. Esto es lo que quieres para herramientas en las que un agente está explícitamente autorizado a usar.
Tráfico idéntico a allow, pero marcado como algo que querías observar. Es el default_verdict recomendado: observa todo, no bloquea nada, hasta que tus reglas estén afinadas. El nivel de autonomía balanced trae el guardrail PII Shield como solo-flag (audit), así que la PII se registra sin retener la llamada.
La llamada nunca alcanza la herramienta. En la superficie inbound esto devuelve HTTP 400 firewall_blocked; a través del gateway MCP vuelve como un error de herramienta (firewall deny: <reason>) para que el modelo pueda reaccionar en vez de tumbarse. Marcado skip-retry. No cuesta tokens de modelo.
Reemplaza las subcadenas coincidentes (secretos, PII) en los argumentos de la llamada a herramienta con un token [redacted:<preset>], luego reenvía la llamada con los argumentos limpios. Redacta argumentos solamente — nunca el contenido que una herramienta devuelve. En la superficie inbound, donde aún no hay argumentos en tiempo de llamada, sanitize escala a un deny.
La llamada se encola para revisión y el agente obtiene una respuesta retenida que lleva un id de aprobación (HTTP 400 firewall_approval_pending). Un revisor la resuelve en la consola o vía un callback de webhook HMAC; el agente hace polling del id y reenvía una vez con una cabecera de aprobación de un solo uso. Ve Aprobación humana.
Autorado como una regla con un techo en centavos por regla. Resuelve a allow mientras la ejecución del agente está bajo presupuesto y a deny una vez que el gasto acumulado cruza el tope — así que un evento muestra allow o deny, no la palabra literal cap_cost. Un interruptor de circuito para bucles descontrolados.
En modo shadow, deny / sanitize / pending_approval se degradan todos a audit y la razón se prefija [shadow] would …. El evento registra el veredicto que se habría disparado, pero el tráfico no cambia — ese es el punto entero de un lanzamiento seguro.

​
Veredicto por defecto

default_verdict acepta solo los tres veredictos no interactivos:
ValorSignificado cuando ninguna regla coincide
allowPermite las llamadas a herramienta no cubiertas silenciosamente.
auditPermite pero registra — el valor por defecto.
denyBloquea cualquier cosa que ninguna regla permita explícitamente (postura default-deny).
El nivel de autonomía tight establece default_verdict: deny; balanced y el valor por defecto enviado usan audit.

​
2. Acciones de guardrail

Una regla de guardrail dispara una de cinco acciones. Son el equivalente de plano de texto de los veredictos — y una regla de guardrail nunca produce un veredicto de firewall.
AcciónQué haceCuota
blockRechaza la solicitud entera con HTTP 400 guardrail_blocked.Ninguna — los bloqueos de entrada se disparan antes del medido; los bloqueos de salida reembolsan.
maskRedacta cada coincidencia a una etiqueta tipada (ve §3) y reenvía el texto limpio.Normal — la llamada procede.
flagSolo registra. Registra una coincidencia; no cambia nada del tráfico.Normal.
annotateNo bloqueante. Adjunta una nota legible por humanos a la solicitud (inyectada upstream como un aviso de seguridad) sin enmascarar ni bloquear el texto.Normal.
spotlightNo bloqueante. Envuelve el texto (no confiable) coincidente en delimitadores y le dice al modelo que trate la región delimitada como datos, nunca instrucciones — la defensa “spotlighting” contra inyección de prompts.Normal.
Una solicitud de guardrail bloqueada está marcada skip-retry — reejecutar el mismo prompt contra otro canal simplemente volvería a bloquear.
Usa flag para medir una regla nueva contra tráfico real antes de cambiarla a block o mask. El feed de Matches muestra qué se habría capturado con cero impacto en el tráfico — la contraparte de guardrail del modo shadow del firewall.
Una única regla pii puede aplicar diferentes acciones a diferentes entidades con entity_actions — enmascarar emails y teléfonos, pero bloquear en credit_card y ssn, desde una sola regla. Las claves deben ser una entidad habilitada en la regla; los valores deben ser block / mask / flag / annotate.

​
3. El glosario de etiquetas de enmascarado

En una acción mask, cada entidad coincidente se reemplaza en línea con una etiqueta tipada — [<NOMBRE_ENTIDAD_MAYUSCULAS>] — para que el modelo (etapa de entrada) o el llamante (etapa de salida) vea la forma de los datos sin el valor. El enmascarado se ejecuta en ambas etapas, incluyendo respuestas en streaming: un escáner de stream consciente de tokens enmascara las coincidencias que cruzan los límites de chunk antes de que alcancen al cliente.
EntidadEtiqueta
email[EMAIL]
phone[PHONE]
credit_card[CREDIT_CARD]
ssn[SSN]
ip[IP]
iban[IBAN]
mac_address[MAC_ADDRESS]
jwt[JWT]
aws_access_key[AWS_ACCESS_KEY]
api_key_openai[API_KEY_OPENAI]
bitcoin_address[BITCOIN_ADDRESS]
Tres identificadores regionales vienen encima del conjunto base:
EntidadEtiquetaRegión
jp_mynumber[JP_MYNUMBER]Japón
kr_rrn[KR_RRN]Corea del Sur
cn_resident_id[CN_RESIDENT_ID]China
Las entidades personalizadas siguen la misma convención. Una entidad personalizada llamada employee_id se enmascara a [EMPLOYEE_ID] a menos que establezcas un reemplazo mask_with explícito. Hasta 25 entidades personalizadas por regla, cada una un regex RE2 con un checksum luhn opcional. Ve Detección de PII.

​
4. Un ejemplo trabajado

Una única llamada a la herramienta db.query, leída de arriba abajo, toca ambos vocabularios: 
firewall verdict : sanitize        # secret stripped from the SQL argument
guardrail action : mask            # an email in the prompt redacted
masking tag      : [EMAIL]         # what the model actually receives
El sanitize del firewall limpió los argumentos de la herramienta; el mask del guardrail limpió el texto del prompt; la etiqueta [EMAIL] es lo que el modelo ve en lugar de la dirección. Misma solicitud, tres capas diferentes, tres palabras de este glosario.

​
5. Palabras de postura que verás junto a los veredictos

Estas no son veredictos ni acciones, pero deciden si un veredicto se aplica en absoluto — así que aparecen en las mismas vistas de eventos y configuración.
PalabraPlanoSignificado
Modo shadowFirewallFlag por política. Degrada cada veredicto de aplicación a audit, prefija la razón [shadow] would ….
Modo observeFirewallAjuste del espacio de trabajo. Cuando ninguna política resuelve, permite la llamada pero la registra como un hueco de cobertura (Discovered tools).
EnforceFirewallShadow apagado + una política adjunta: los veredictos surten efecto.
Fail-openGuardrailsPor defecto para reglas avanzadas (llm_judge, grounding, external) — un timeout se observa, la solicitud continúa. Cambia a fail-closed por regla.
Log raw contentGuardrailsApagado por defecto. Cuando está apagado, una coincidencia registra que una regla se disparó pero no la subcadena coincidente.
Para la distinción deny-vs-audit-vs-shadow en profundidad, ve Modos de aplicación.

​
6. Dónde se define cada palabra

SuperficieVocabularioPágina de origen
Política de firewallallow audit deny sanitize pending_approval cap_costFirewall
Coincidencia de regla de firewalltool_name_glob, args_match, egress, sequenceReglas del firewall
Regla de guardrailblock mask flag annotate spotlightGuardrails
PII de guardrailnombres de entidad + etiquetas de enmascaradoGuardrails
MCP y skillsbandas de riesgo de skill, modos quarantine / blockFirewall MCP, Firewall skills
Cuerpos de error HTTPguardrail_blocked, firewall_blocked, firewall_approval_pendingCódigos de error
Cada término aquí también aparece en el más amplio Glosario de conceptos, que añade términos de identidad, alcance y amenaza. Esta página es la porción estrecha, enfocada en decisiones — veredictos, acciones y etiquetas de enmascarado solamente.

​
7. Lectura relacionada

¿Por qué se bloqueó esto?

Rastrea una única llamada denegada hasta la regla y veredicto exactos que la detuvieron.

Modos de aplicación

Cómo se relacionan audit, shadow, observe y enforce — y cómo lanzar de forma segura.

Guardrails vs Firewall

Qué plano posee qué decisión, y por qué una solicitud puede pasar por ambos.

Llamadas a herramienta peligrosas

La amenaza que los veredictos deny y sanitize existen para detener.