Saltar al contenido principal
Un guardrail de la etapa de entrada examina la solicitud del llamador antes de que llegue al modelo. Es el lugar más barato para aplicar una política de contenido: el gateway inspecciona el prompt a su llegada, y si una regla bloquea, la solicitud es rechazada antes de la medición — no pagas nada por la llamada. Aquí es donde detienes que un secreto filtrado, un campo PII o un intento de inyección lleguen alguna vez al modelo upstream. Para el motor completo — cada tipo de regla, campo y ruta — ver la referencia de Guardrails. Esta página es la mirada enfocada en la etapa de entrada: qué se ejecuta antes del modelo, y por qué un bloqueo aquí no cuesta cuota.

​
1. Guardrails de entrada para apps de LLM, antes del modelo

Cada regla de guardrail lleva una etapa — input, output o both. Una regla input se ejecuta contra el texto de la solicitud en el momento en que llega, de camino al modelo upstream: 
caller → [ input guardrail ] → metering → model → [ output guardrail ] → caller
Ese orden es el punto. Una regla de entrada ve el prompt antes de que el gateway preconsuma cualquier cuota, así que un bloqueo en esta etapa es gratis — la solicitud nunca llega al modelo y nunca factura. Compara con la etapa de salida, que examina la respuesta del modelo después de que regresa (un bloqueo de salida reembolsa la cuota preconsumida en su lugar).
Las reglas de entrada examinan la solicitud del llamador. Si también usas prompts del registro, el mensaje de sistema inyectado se añade más tarde en el enrutamiento — así que las reglas de entrada ven los mensajes que tu app envió, no el prompt inyectado. Las reglas de salida examinan la respuesta en cualquier caso.

​
2. Qué puedes ejecutar en la etapa de entrada

Cualquier tipo de regla puede ejecutarse en input. Las razones más comunes para vetar la solicitud antes del modelo:

Enmascarar PII en el prompt

Una regla pii con la acción mask reescribe entidades a etiquetas tipadas (jane@acme.com → [EMAIL]) para que el modelo upstream nunca vea el valor en bruto. Ver PII Shield.

Bloquear secretos antes de que se filtren

Una solicitud que lleva una clave API o credencial de nube es rechazada en la puerta — pre-medición, sin llamada upstream. Ver Bloquear secretos.

Detener intentos de inyección

El preset de básicos de inyección de prompts empareja detectores keyword/regex con una regla llm_judge para la intención de inyección. Ver Inyección de prompts.

Topar el tamaño del prompt

Una regla max_chars rechaza un prompt sobredimensionado antes de que facture tokens. Ver Guardrails de coste.
Los siete tipos de regla — keyword, regex, pii, max_chars, external, llm_judge, grounding — y las cinco acciones block, mask, flag, annotate y spotlight aplican todas aquí. (spotlight envuelve el texto no confiable coincidente en delimitadores para que el modelo lo trate como datos, no como instrucciones — una defensa de inyección de prompts en la etapa de entrada; annotate adjunta una nota sin cambiar el tráfico.) Una excepción que vale la pena conocer: grounding mide la respuesta contra las fuentes recuperadas, así que es inherentemente una verificación de la etapa de salida. Todo lo demás encaja naturalmente en la etapa de entrada.
El enmascarado en la etapa de entrada está activo hoy — con o sin streaming. El gateway reescribe la solicitud antes de que el modelo la vea en cada ruta. Mask de salida redacta solo respuestas sin streaming; la reescritura de salida en el stream está en el roadmap, así que una regla de enmascarado aún no redacta una respuesta con streaming. Block de salida, en cambio, se aplica en ambos sentidos — con y sin streaming (ver Cobertura de streaming).

​
3. Un ejemplo concreto

Crea la regla en la consola (bajo tu propia sesión — la configuración de guardrails necesita Developer+), no con una clave de relay. Añade una sola regla input a un guardrail llamado secrets-shield: 
{
  "type": "regex",
  "stage": "input",
  "action": "block",
  "pattern": "sk-[A-Za-z0-9]{20,}"
}
Vincula el guardrail a una clave (establece guardrail_id, o márcalo como valor por defecto del espacio de trabajo — ver Vincular a una clave), luego llama al gateway con esa clave de relay sk-orca-...: 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Debug this: OPENAI_API_KEY=sk-abcdefghij1234567890"}
    ]
  }'
La solicitud coincide en la etapa de entrada y es rechazada con HTTP 400 guardrail_blocked antes de que el gateway reenvíe nada upstream: 
{
  "error": {
    "type": "guardrail_blocked",
    "message": "request blocked by guardrail \"secrets-shield\": regex(...)"
  }
}
Ver el error guardrail_blocked para la forma completa de la respuesta.

​
4. Por qué un bloqueo de entrada no cuesta cuota

Esta es la ventaja estructural de capturar las cosas a la entrada. Un bloqueo en la etapa de entrada se sitúa antes del preconsumo, así que:
PropiedadBloqueo en la etapa de entrada
Estado HTTP400 guardrail_blocked
Cuota cobradaNinguna — se dispara antes de la medición
Llamada upstreamNunca se hace
ReintentoMarcado skip-retry — reejecutar vuelve a bloquear
Como la solicitud nunca llega a un canal, un bloqueo de entrada se marca skip-retry: reejecutar el mismo prompt contra otro canal simplemente volvería a bloquear y malgastaría esfuerzo. La etapa de salida difiere — un bloqueo allí reembolsa la cuota que el gateway ya preconsumió. Mismo 400, contabilidad diferente.

​
5. Resolución y fallback

Una regla de la etapa de entrada solo se ejecuta si un guardrail realmente resuelve en la solicitud. La resolución es explícita:
  1. El guardrail_id explícito de la clave, si existe y está habilitado.
  2. De lo contrario el guardrail por defecto del espacio de trabajo.
  3. De lo contrario ninguno — la solicitud es idéntica byte a byte a un espacio de trabajo sin política.
Una vinculación explícita nunca hace fallback silencioso. Deshabilitar un guardrail vinculado es el interruptor de apagado — no cae al valor por defecto del espacio de trabajo. (Las políticas de firewall se comportan diferente aquí; ver Guardrails vs. firewall.)

​
6. Pruébalo antes de lanzarlo

No vincules una regla de entrada bloqueante al tráfico en vivo por fe. Dos formas de validar primero:
Abre la pestaña Test en el editor del guardrail, pega una muestra, elige la etapa input y ejecuta. El sandbox evalúa la política actual localmente — sin llamada upstream, sin cuota — y devuelve el veredicto más (para reglas mask) el texto renderizado. Ver Pruebas y eval.
Establece la acción a flag primero. Un flag no cambia nada del tráfico — solo registra una coincidencia — así que puedes medir con qué frecuencia se dispararía una regla sobre entrada real antes de cambiarla a block. Ver Afinar falsos positivos.
Cada regla que se dispara registra una coincidencia — tipo, acción, etapa y una cadena de detalle. La subcadena coincidente se registra solo cuando Log raw content está activado (apagado por defecto). Ver el Feed de coincidencias y Registro y privacidad.

​
7. Dónde ir a continuación

La etapa de entrada detiene que la entrada mala llegue al modelo. Para vetar la respuesta del modelo, empareja con la etapa de salida; para gobernar las llamadas a herramienta de un agente, usa el firewall. Lee la referencia de Guardrails para el motor completo, o el inicio rápido de seguridad para conectar los guardrails de entrada y el firewall juntos para una línea base de agente.