Saltar al contenido principal
Estás construyendo un SaaS donde muchos inquilinos-cliente comparten una base de código y un espacio de trabajo de OrcaRouter. Cada inquilino envía prompts y ejecuta agentes a través de tu gateway, y el problema difícil es el radio de explosión: una clave de inquilino filtrada, un agente de inquilino descontrolado, o la PII de un inquilino aterrizando en los registros de otro no pueden permitirse derramar a través del límite. Esta receta cablea los tres controles que hacen seguro para inquilinos un gateway compartido — una clave con alcance por inquilino, política a nivel de espacio de trabajo que cada inquilino hereda, y overrides por inquilino donde uno necesita más — todo desde la consola, con cero cambio en el código de tu aplicación.
Todo aquí se vincula a tu espacio de trabajo y se configura desde la consola. Tu app sigue llamando a https://api.orcarouter.ai/v1/chat/completions con la clave sk-orca-... de cada inquilino — solo cambia la política en el gateway. Las acciones de configuración necesitan los roles indicados por paso; solo las llamadas de relay /v1/* usan una clave de inquilino.

​
1. El modelo de seguridad de IA multi-inquilino

Un gateway multi-inquilino tiene una forma de amenaza diferente a la de una sola app. Los riesgos que importan escalan con el número de inquilinos:

Fuga de clave = radio de explosión de un inquilino

Una clave de inquilino filtrada no debería poder drenar tu cuenta, llamar a modelos que nunca expusiste, o alcanzar más allá del presupuesto de ese inquilino.

Sangrado de datos entre inquilinos

La PII de un inquilino aterrizando en registros compartidos, o en una respuesta enrutada a otro inquilino, rompe tu promesa de aislamiento de datos.

Un agente de inquilino ruidoso

El agente de un inquilino iterando en bucle sobre una herramienta u obteniendo hosts arbitrarios no debería degradar el gateway para todos los demás.

Cumplimiento por inquilino

Un inquilino regulado puede necesitar enmascarado de PII y residencia de datos que el resto de tus inquilinos no.
El modelo de abajo son dos capas: una línea base de espacio de trabajo que cada clave de inquilino hereda, más alcance y overrides por clave que endurecen un inquilino sin tocar a los demás. Ver alcance de claves, políticas, espacios de trabajo para las reglas de resolución completas.

​
2. La línea base: una política de espacio de trabajo que cada inquilino hereda

Autora tu postura de seguridad una vez a nivel de espacio de trabajo para que cada clave de inquilino la herede por defecto — sin duplicación por inquilino.
1

Un guardrail por defecto

En Guardrails → New guardrail, autora una política nombrada (p. ej. tenant-baseline) y márcala como default del espacio de trabajo (is_default). Añade una regla PII, etapa input, acción mask, para que ninguna solicitud de inquilino lleve PII en bruto upstream:
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "credit_card", "ssn", "ip"],
  "entity_actions": { "credit_card": "block", "ssn": "block" }
}
Cualquier clave de inquilino sin adjunción explícita de guardrail hace fallback a este valor por defecto. Autorar un guardrail necesita el rol Developer.
2

Una política de firewall por defecto

Si tus inquilinos ejecutan agentes, haz lo mismo en el plano de acción: en Firewall → Policies, autora una política por defecto o — más rápido — abre Firewall → Posture y aplica el nivel de autonomía balanced. Eso audita las llamadas a herramienta de cada inquilino y marca PII en todo el espacio de trabajo mientras deniega las acciones más destructivas, así que vigilas el comportamiento real del inquilino antes de aplicar ampliamente. Rol Developer.
Lanza la línea base en orden observe → shadow → enforce para que una regla nueva no pueda romper a un inquilino en pleno vuelo. Una política de firewall soporta un flag shadow_mode por política (los veredictos de aplicación se registran como [shadow] would …); empieza las reglas de guardrail en la acción flag. Ver modos de aplicación.

​
3. Una clave con alcance por inquilino

Este es el núcleo del aislamiento de inquilinos: nunca compartas una clave entre inquilinos, y nunca entregues a un inquilino tu clave de toda la cuenta. Acuña una clave por inquilino, con alcance a exactamente lo que ese inquilino puede hacer. En API Keys → New key, establece:
Establece credit_limit_usd al techo de ese inquilino (0 = ilimitado). Este es el control multi-inquilino más importante: una clave de inquilino filtrada o abusada solo puede quemar el presupuesto de ese inquilino, nunca tu cuenta. Ver denial-of-wallet.
Activa model_limits (model_limits_enabled) y lista solo el/los modelo(s) que incluye el plan de ese inquilino — así una clave filtrada no puede ejecutar un modelo caro que el inquilino nunca pagó.
Establece environment (una etiqueta de despliegue de forma libre, p. ej. prod / staging) para que el tráfico de un inquilino sea atribuible en tus registros y puedas distinguir las claves de producción de las de prueba de un vistazo.
Establece allow_ips a las IPs de egress del backend de ese inquilino si llama desde un servidor fijo, y expired_time para inquilinos de prueba o con tiempo limitado (-1 = nunca expira).
Cada clave de inquilino hereda el guardrail tenant-baseline del espacio de trabajo y la política de firewall por defecto automáticamente — acuñaste una clave con alcance, y ya está gobernada. La clave se enmascara en pantalla tras la creación, así que cópiala una vez cuando aprovisiones el inquilino.

​
4. Overrides por inquilino — endurece uno sin tocar el resto

La mayoría de los inquilinos cabalgan la línea base. Cuando uno necesita más — un inquilino regulado, un nivel empresarial, un inquilino en una lista de prueba — adjunta una política nombrada más estricta a esa clave solamente:
Establecer en la claveEfecto para ese único inquilino
guardrail_idCambia a un guardrail nombrado más estricto (p. ej. bloqueo-ante-PII).
firewall_policy_idCambia a una política de firewall más ajustada (p. ej. herramientas default-deny).
La resolución difiere entre los dos planos — conoce la diferencia:
Un guardrail_id explícito (cuando existe y está habilitado) siempre aplica y nunca hace fallback silencioso. Si ese guardrail adjunto está deshabilitado, la clave no obtiene guardrail — no cae al valor por defecto del espacio de trabajo. Deja guardrail_id sin establecer (0/null) para heredar el valor por defecto tenant-baseline.
Un firewall_policy_id adjunto aplica cuando existe y está habilitado; si esa política está deshabilitada, la clave hace fallback a la política por defecto del espacio de trabajo. (Esto es lo opuesto al comportamiento del interruptor de apagado del guardrail — por diseño.)
Editar una política nombrada cambia cada clave adjunta a ella en la siguiente llamada. Si múltiples inquilinos comparten una política más estricta, una edición los afecta a todos a la vez. Usa una política nombrada distinta por clase de aislamiento, no una política compartida gigante, cuando los inquilinos necesitan reglas genuinamente diferentes.

​
5. Un ejemplo concreto de dos niveles

Digamos que ejecutas un nivel gratuito y un nivel empresarial regulado en un espacio de trabajo:
  1. Línea base del espacio de trabajo — guardrail tenant-baseline (máscara de PII en input, bloqueo en tarjeta/SSN) como is_default, más el nivel de autonomía de firewall balanced. Cada inquilino hereda esto.
  2. Clave de inquilino del nivel gratuito — sin guardrail_id (hereda la línea base), model_limits fijado a openai/gpt-4o-mini, un credit_limit_usd bajo.
  3. Clave de inquilino empresarial — guardrail_id establecido a un guardrail enterprise-pii más estricto (PII block, no mask, en input; bloqueo de secretos en la etapa output), un firewall_policy_id con una lista de permitidos de herramientas más ajustada, un tope de crédito más alto, y allow_ips fijado a su backend.
Ambos niveles llaman al mismo endpoint /v1/chat/completions con su propia clave. El gateway resuelve la política correcta por clave — tu código de aplicación es idéntico para cada inquilino.

​
6. Cumplimiento y residencia por inquilino

Un inquilino regulado a menudo necesita una atestación que el resto no. El cumplimiento se ejecuta como un par de espacio de trabajo de guardrails y firewall:
  • Navegar el catálogo de marcos y la disposición está abierto a cualquier Member y es gratis — confirma la cobertura para el marco que un inquilino pregunta (soc2, hipaa, gdpr, iso_27001, pci_dss y más).
  • Instalar un pack (POST /api/compliance/packs/:key/install) materializa los guardrails y políticas de firewall coincidentes en tu espacio de trabajo; requiere Admin del espacio de trabajo y un plan de pago.
  • La residencia de datos fija la región del artefacto de informe de cumplimiento (us / eu / uk / ap / cn / global) vía PUT /api/compliance/residency (Admin). Las lecturas inter-región se retienen.
La residencia aquí gobierna el artefacto de informe de cumplimiento, no la geofijación de datos de inferencia. Para la historia del registro de solicitudes: los registros se retienen por defecto 30 días (acotado duro a 180), y una auto-eliminación de usuario ejecuta una gracia de 30 días, luego una limpieza de PII que cae en cascada a las coincidencias de guardrail y los registros de solicitudes de ese usuario.
Para una ejecución de evidencia auditada completa, ver generar evidencia SOC 2 y desplegar para HIPAA.

​
7. Vigila cada inquilino desde un espacio de trabajo

Toda la observabilidad tiene alcance de espacio de trabajo, así que un solo conjunto de feeds cubre todos tus inquilinos — filtrable hasta uno solo:
  • Guardrails → Matches (cualquier Member) — cada regla que se disparó en todos los inquilinos: tipo, acción, etapa, detalle. La subcadena coincidente se registra solo si Log raw content está activado para ese guardrail (apagado por defecto — la postura conservadora de privacidad, que importa más en multi-inquilino). Marca un falso positivo para afinar (Admin).
  • Firewall → Events / Runs (Developer+) — cada llamada a herramienta, agregada por ejecución de agente, para que el bucle de un inquilino ruidoso o un egress novedoso destaque.
  • Feed de anomalías (Member) — picos de tasa/coste puntuados contra una línea base aprendida de hora-de-la-semana capturan a un inquilino quemando fuera de patrón incluso cuando cada llamada está individualmente permitida.
Una solicitud bloqueada devuelve HTTP 400 (guardrail_blocked / firewall_blocked), no cuesta cuota a ese inquilino, y se marca skip-retry — el límite se mantuvo sin cobrar al inquilino por el rechazo.

​
8. Dónde profundizar

Alcance de claves, políticas, espacios de trabajo

El orden de resolución completo para la adjunción de clave y los valores por defecto del espacio de trabajo.

Referencia de Guardrails

Cada tipo de regla, entidad PII y override por entidad al completo.

Referencia de Firewall

Veredictos, superficies, niveles de autonomía y el plano de política.

Detener la exfiltración de datos

Asegura el egress saliente de un agente de inquilino.