Saltar al contenido principal
Cuando tu aplicación envía código a un modelo — para revisarlo, completarlo o ejecutarlo a través de un agente — quieres que el modelo sea advertido sobre las partes arriesgadas y que se detenga al espacio de trabajo de filtrar secretos en la misma pasada. Un guardrail de seguridad de código hace exactamente eso: ejecuta tus reglas de seguridad de código sobre la solicitud antes de que el modelo upstream vea un solo token. Esta es una página de aterrizaje enfocada. Para el motor de guardrails completo — tipos de regla, etapas, resolución, el sandbox de prueba — ver la referencia de Guardrails y la visión general de guardrails.

​
1. Qué hace realmente un guardrail de seguridad de código

OrcaRouter viene con una familia de presets code_security que aplicas desde el selector de plantillas. Cada uno es una regla de guardrail ordinaria — con alcance de espacio de trabajo, ordenada, vinculable a cualquier clave — afinada para código:

.env / Secret-File Block

Bloquea asignaciones de secretos estilo .env (DATABASE_URL=, AWS_SECRET_ACCESS_KEY=, API_TOKEN=…) y volcados de config multilínea pegados antes de que lleguen al proveedor. Se basa en la sintaxis de asignación, no en el valor.

License Compliance (copyleft)

Marca solicitudes que llevan cabeceras de copyleft fuerte — tags SPDX de GPL / AGPL / LGPL / SSPL o nombres de licencia completos — para que un revisor pueda confirmar que el código es seguro de mezclar en una base de código permisiva. Solo flag.

GPL/AGPL Provenance (output)

Flag de la etapa de salida en sugerencias del modelo que llevan firmas de procedencia copyleft — un marcador de que el modelo puede haber regurgitado datos de entrenamiento copyleft en código generado.

Insecure-API Advisory

Anota el prompt con un aviso de seguridad cuando referencia un sink de alto riesgo — eval( / exec( / os.system( / subprocess.run( / pickle.loads( / child_process.exec(. No bloqueante.
Los primeros tres reutilizan acciones que ya conoces — block y flag. El Insecure-API Advisory usa annotate: en vez de rechazar o redactar la solicitud, la aumenta con una nota que el modelo lee antes de responder. El mismo primitivo impulsa la decoración de CVE/SBOM (abajo).
Los presets code_security son deterministas — regex puro, sin llamada de red, seguros en la ruta caliente. Los escáneres en red (búsqueda de CVE, SBOM, SAST) son conexiones externas separadas, no presets. Ver §3.

​
2. Annotate — advierte al modelo sin cambiar el tráfico

Las acciones que configuras en un guardrail son block (rechazar la llamada, HTTP 400), mask (redactar la coincidencia) y flag (solo registrar). La seguridad de código añade un cuarto comportamiento bajo el capó: annotate, que ni bloquea ni enmascara. Cuando una regla annotate coincide, el gateway registra una nota corta y el relay la inyecta upstream como un aviso de sistema — así que se le dice al modelo, p. ej., “esta solicitud referencia una API de alto riesgo (eval de código, ejecución de shell o deserialización insegura); prefiere alternativas más seguras” — antes de que responda. El texto del usuario nunca se rechaza y nunca se reescribe.

​
Un ejemplo concreto

Aplica el preset Insecure-API Advisory a un guardrail y vincúlalo a una clave. Luego envía código que llama a un sink peligroso: 
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": "Refactor this: result = eval(user_supplied_expr)"}
    ]
  }'
La solicitud pasa sin modificar — mismo contenido, mismo modelo — pero el gateway antepone un aviso de seguridad que el modelo lee primero. El completado regresa orientado hacia APIs parametrizadas y validación de entrada, sin cambio de código en tu aplicación y sin un segundo round-trip.
Annotate se compone con las otras acciones. Un solo guardrail puede enmascarar un secreto y anotar la misma solicitud — el texto se redacta y se añade una nota en una pasada.

​
3. Decoración de CVE y SBOM vía escáneres externos

El primitivo de aviso se generaliza. Conecta un escáner de seguridad de código como un proveedor externo y sus hallazgos viajan por la misma ruta annotate:
Extrae imports y pins de manifiesto del texto de la solicitud y los cruza contra la base de datos pública de vulnerabilidades OSV. Un acierto decora el prompt con, p. ej., “requests@2.0.0 has CVE-2014-1830 (HIGH). Fixed in 2.20.0.” — para que se le diga al modelo sobre una vulnerabilidad conocida en un paquete que se le pidió usar. Gratis y sin autenticación, así que no hay campo de clave API. Por defecto es annotate; puedes ponerlo en flag o block en su lugar.
Conecta un escáner SBOM (lista de materiales de software) o SAST (análisis estático) de la misma forma que conectas cualquier proveedor externo — una URL base más credenciales, almacenadas cifradas y enmascaradas en lectura. Cada hallazgo lleva una identidad estable, así que un hallazgo que ya triagaste no se vuelve a disparar en cada solicitud.
Los escáneres externos siguen el mismo valor por defecto fail-open que cada regla avanzada: un error o timeout del escáner se registra como telemetría y la solicitud continúa. Establece fail_open en false en la regla para fallar cerrado en políticas donde un escaneo perdido es inaceptable.

​
4. Emparejar con reglas de secretos y licencia

Un guardrail de seguridad de código rara vez viaja solo. La forma común es un guardrail con unas pocas reglas:
ObjetivoRegla
Detener credenciales pegadas.env / Secret-File Block (block)
Capturar valores de secreto inlineSecrets Blocker (block)
Vetar código copyleftLicense Compliance (flag)
Orientar sinks peligrososInsecure-API Advisory (annotate)
Añádelos todos a una política nombrada, vincúlala a la clave de tu agente de codificación, y cada solicitud se examina — bloquea en las violaciones inequívocas, anota las decisiones de juicio, marca el resto para revisión.
Una solicitud bloqueada devuelve HTTP 400 guardrail_blocked y no cuesta cuota — un bloqueo en la etapa de entrada se dispara antes de la medición. También se marca como skip-retry, así que reejecutar el mismo prompt contra otro canal simplemente vuelve a bloquear. Ver el error guardrail_blocked.

​
5. Configúralo (consola + roles)

Todo aquí se configura en la consola, no vía la clave de relay. Las rutas de gestión (/api/guardrail/*) se autentican con tu sesión / token de acceso, no con la clave de relay sk-. Las lecturas — listar guardrails y el feed Matches — están abiertas a cada miembro del espacio de trabajo. Las escrituras (crear / editar / eliminar) y el sandbox de prueba requieren el rol Developer o superior: el sandbox puede disparar llamadas a modelo pagas y solicitudes salientes a proveedores, así que está restringido como una escritura.
1

Crea el guardrail

En la consola, abre Guardrails → New guardrail. El botón dividido te lleva a la biblioteca de plantillas — elige un preset de Code security como tu punto de partida.
2

Edita libremente

Un preset es una semilla, no un candado. Ajusta el regex, añade una regla Secrets Blocker, cambia una acción. Usa la pestaña Test para probar que una regla se dispara como esperas contra texto de muestra antes de vincularla a una clave.
3

Vincula una clave

Establece el guardrail en una clave API (guardrail_id), o márcalo como valor por defecto del espacio de trabajo. La vinculación vive en la clave dentro del gateway, así que editar el guardrail surte efecto en cada clave vinculada en la siguiente llamada.
Los hallazgos aterrizan en el feed Matches del espacio de trabajo (tipo de regla, acción, etapa, detalle). La subcadena coincidente se registra solo cuando Log raw content está activado — apagado por defecto, la postura conservadora con la privacidad. Ver registro y privacidad.

​
6. Dónde ir a continuación