Passer au contenu principal
Vous construisez un SaaS où de nombreux locataires-clients partagent une seule base de code et un seul espace de travail OrcaRouter. Chaque locataire envoie des prompts et exécute des agents à travers votre passerelle, et le problème difficile est le rayon d’explosion : une clé de locataire fuitée, un agent de locataire emballé, ou la PII d’un locataire atterrissant dans les journaux d’un autre ne peut pas être autorisée à déborder à travers la frontière. Cette recette câble les trois contrôles qui rendent une passerelle partagée sûre pour les locataires — une clé scopée par locataire, une politique au niveau de l’espace de travail dont chaque locataire hérite, et des overrides par locataire là où un locataire a besoin de plus — le tout depuis la console, sans aucun changement dans le code de votre application.
Tout ici se lie à votre espace de travail et est configuré depuis la console. Votre app continue d’appeler https://api.orcarouter.ai/v1/chat/completions avec la clé sk-orca-... de chaque locataire — seule la politique dans la passerelle change. Les actions de config nécessitent les rôles indiqués à chaque étape ; seuls les appels de relais /v1/* utilisent une clé de locataire.

​
1. Le modèle de sécurité IA multi-locataire

Une passerelle multi-locataire a une forme de menace différente d’une seule app. Les risques qui comptent passent à l’échelle avec le nombre de locataires :

Fuite de clé = rayon d'explosion d'un locataire

Une clé de locataire fuitée ne devrait pas pouvoir drainer votre compte, appeler des modèles que vous n’avez jamais exposés, ou atteindre au-delà du budget de ce locataire.

Fuite de données inter-locataires

La PII d’un locataire atterrissant dans des journaux partagés, ou dans une réponse routée vers un autre locataire, brise votre promesse d’isolation des données.

Un agent de locataire bruyant

L’agent d’un locataire bouclant sur un outil ou récupérant des hôtes arbitraires ne devrait pas dégrader la passerelle pour tous les autres.

Conformité par locataire

Un locataire réglementé peut avoir besoin de masquage PII et de résidence des données dont le reste de vos locataires n’a pas besoin.
Le modèle ci-dessous comporte deux couches : un référentiel d’espace de travail dont chaque clé de locataire hérite, plus des portée et overrides par clé qui resserrent un locataire sans toucher les autres. Voir clés, politiques, espaces de travail pour les règles de résolution complètes.

​
2. Le référentiel : une politique d’espace de travail dont chaque locataire hérite

Rédigez votre posture de sécurité une fois au niveau de l’espace de travail afin que chaque clé de locataire en hérite par défaut — aucune duplication par locataire.
1

Un guardrail par défaut

Dans Guardrails → Nouveau guardrail, rédigez une politique nommée (par ex. tenant-baseline) et marquez-la comme défaut de l’espace de travail (is_default). Ajoutez une règle PII, stage input, action mask, afin qu’aucune requête de locataire ne porte de PII brute en amont :
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "credit_card", "ssn", "ip"],
  "entity_actions": { "credit_card": "block", "ssn": "block" }
}
Toute clé de locataire sans attachement de guardrail explicite retombe sur ce défaut. Rédiger un guardrail nécessite le rôle Developer.
2

Une politique firewall par défaut

Si vos locataires exécutent des agents, faites de même sur le plan action : dans Firewall → Policies, rédigez une politique par défaut ou — plus rapide — ouvrez Firewall → Posture et appliquez le niveau d’autonomie balanced. Cela audite les appels d’outils de chaque locataire et signale la PII à l’échelle de l’espace de travail tout en refusant les actions les plus destructrices, de sorte que vous observiez le comportement réel des locataires avant d’appliquer largement. Rôle Developer.
Déployez le référentiel dans l’ordre observe → shadow → enforce afin qu’une nouvelle règle ne puisse pas casser un locataire en plein vol. Une politique firewall supporte un flag shadow_mode par politique (les verdicts appliquants journalisent comme [shadow] would …) ; commencez les règles de guardrail à l’action flag. Voir modes d’application.

​
3. Une clé scopée par locataire

C’est le cœur de l’isolation de locataire : ne partagez jamais une clé entre locataires, et ne remettez jamais à un locataire votre clé à portée de compte. Frappez une clé par locataire, scopée exactement à ce que ce locataire peut faire. Dans API Keys → Nouvelle clé, définissez :
Définissez credit_limit_usd sur le plafond de ce locataire (0 = illimité). C’est le contrôle multi-locataire le plus important : une clé de locataire fuitée ou abusée ne peut jamais brûler que le budget de ce locataire, jamais votre compte. Voir denial-of-wallet.
Activez model_limits (model_limits_enabled) et ne listez que le(s) modèle(s) que le plan de ce locataire inclut — de sorte qu’une clé fuitée ne puisse pas exécuter un modèle coûteux que le locataire n’a jamais payé.
Définissez environment (une étiquette de déploiement libre, par ex. prod / staging) afin que le trafic d’un locataire soit attribuable dans vos journaux et que vous puissiez distinguer les clés de production des clés de test en un coup d’œil.
Définissez allow_ips sur les IPs d’egress du backend de ce locataire s’il appelle depuis un serveur fixe, et expired_time pour les locataires en essai ou limités dans le temps (-1 = n’expire jamais).
Chaque clé de locataire hérite automatiquement du guardrail tenant-baseline de l’espace de travail et de la politique firewall par défaut — vous avez frappé une clé scopée, et elle est déjà gouvernée. La clé est masquée à l’affichage après création, donc copiez-la une seule fois quand vous provisionnez le locataire.

​
4. Overrides par locataire — resserrer un sans toucher le reste

La plupart des locataires chevauchent le référentiel. Quand l’un a besoin de plus — un locataire réglementé, un palier entreprise, un locataire sur une liste de probation — attachez une politique nommée plus stricte à cette clé uniquement :
Défini sur la cléEffet pour ce seul locataire
guardrail_idÉchange contre un guardrail nommé plus strict (par ex. block-on-PII).
firewall_policy_idÉchange contre une politique firewall plus serrée (par ex. deny par défaut sur les outils).
La résolution diffère entre les deux plans — connaissez la différence :
Un guardrail_id explicite (lorsqu’il existe et est activé) s’applique toujours et ne retombe jamais silencieusement. Si ce guardrail attaché est désactivé, la clé n’obtient aucun guardrail — elle ne retombe pas sur le défaut de l’espace de travail. Laissez guardrail_id non défini (0/null) pour hériter du défaut tenant-baseline.
Un firewall_policy_id attaché s’applique lorsqu’il existe et est activé ; si cette politique est désactivée, la clé retombe sur la politique firewall par défaut de l’espace de travail. (C’est l’opposé du comportement de l’interrupteur d’arrêt du guardrail — par conception.)
Éditer une politique nommée fait basculer chaque clé qui y est attachée au prochain appel. Si plusieurs locataires partagent une politique plus stricte, une édition les touche tous à la fois. Utilisez une politique nommée distincte par classe d’isolation, pas une seule politique partagée géante, quand les locataires ont besoin de règles véritablement différentes.

​
5. Un exemple concret à deux paliers

Disons que vous exploitez un palier gratuit et un palier entreprise réglementé sur un seul espace de travail :
  1. Référentiel d’espace de travail — guardrail tenant-baseline (masque PII sur input, block sur carte/SSN) comme is_default, plus le niveau d’autonomie firewall balanced. Chaque locataire en hérite.
  2. Clé de locataire palier gratuit — pas de guardrail_id (hérite du référentiel), model_limits épinglé à openai/gpt-4o-mini, un credit_limit_usd bas.
  3. Clé de locataire entreprise — guardrail_id défini sur un guardrail enterprise-pii plus strict (PII block, pas mask, sur input ; block de secrets au stage output), un firewall_policy_id avec une allow-list d’outils plus serrée, un plafond de crédit plus élevé, et allow_ips épinglé sur leur backend.
Les deux paliers appellent le même endpoint /v1/chat/completions avec leur propre clé. La passerelle résout la bonne politique par clé — votre code d’application est identique pour chaque locataire.

​
6. Conformité et résidence par locataire

Un locataire réglementé a souvent besoin d’une attestation dont le reste n’a pas besoin. La conformité s’exécute comme un pair d’espace de travail des guardrails et du firewall :
  • Parcourir le catalogue de frameworks et l’état de préparation est ouvert à tout Member et gratuit — confirmez la couverture pour le framework qu’un locataire demande (soc2, hipaa, gdpr, iso_27001, pci_dss, et plus).
  • Installer un pack (POST /api/compliance/packs/:key/install) matérialise les guardrails et politiques firewall correspondants dans votre espace de travail ; cela nécessite Admin de l’espace de travail et un plan payant.
  • La résidence des données épingle la région de votre artefact de rapport de conformité (us / eu / uk / ap / cn / global) via PUT /api/compliance/residency (Admin). Les lectures inter-régions sont refusées.
La résidence ici gouverne l’artefact de rapport de conformité, pas un géo-épinglage des données d’inférence. Pour l’histoire des journaux de requêtes : les journaux sont retenus pour un défaut de 30 jours (plafonné à 180), et une auto-suppression d’utilisateur exécute une grâce de 30 jours puis un nettoyage PII qui se propage en cascade aux matches de guardrail et aux journaux de requêtes de cet utilisateur.
Pour une exécution de preuve auditée complète, voir générer une preuve SOC 2 et déployer pour HIPAA.

​
7. Surveillez chaque locataire depuis un seul espace de travail

Toute l’observabilité est à portée d’espace de travail, de sorte qu’un seul jeu de flux couvre tous vos locataires — filtrable jusqu’à un seul :
  • Guardrails → Matches (tout Member) — chaque règle qui s’est déclenchée à travers tous les locataires : type, action, stage, détail. La sous-chaîne correspondante n’est enregistrée que si Log raw content est activé pour ce guardrail (désactivé par défaut — la posture prudente en matière de vie privée, qui compte le plus en multi-locataire). Marquez un faux positif pour ajuster (Admin).
  • Firewall → Events / Runs (Developer+) — chaque appel d’outil, agrégé par exécution d’agent, de sorte que la boucle d’un locataire bruyant ou un egress inédit ressorte.
  • Flux d’anomalies (Member) — les pics de débit/coût scorés contre une baseline heure-de-la-semaine apprise attrapent un locataire qui brûle hors de son motif même quand chaque appel est individuellement autorisé.
Une requête bloquée renvoie une HTTP 400 (guardrail_blocked / firewall_blocked), ne coûte aucun quota à ce locataire, et est marquée skip-retry — la frontière a tenu sans facturer le locataire pour le rejet.

​
8. Pour aller plus loin

Clés, politiques, espaces de travail

L’ordre de résolution complet pour l’attachement de clé et les défauts d’espace de travail.

Référence Guardrails

Chaque type de règle, entité PII, et override par entité en entier.

Référence Firewall

Verdicts, surfaces, niveaux d’autonomie, et le plan de politique.

Arrêter l'exfiltration de données

Verrouillez l’egress sortant d’un agent de locataire.