Zum Hauptinhalt springen
Sie bauen eine SaaS, in der viele Kunden-Mandanten eine Codebasis und einen OrcaRouter-Workspace teilen. Jeder Mandant sendet Prompts und betreibt Agenten durch Ihr Gateway, und das harte Problem ist der Blast-Radius: Ein geleakter Mandanten-Schlüssel, ein außer Kontrolle geratener Mandanten-Agent oder die PII eines Mandanten, die in den Logs eines anderen landet, dürfen nicht über die Grenze überschwappen. Dieses Rezept verdrahtet die drei Kontrollen, die ein geteiltes Gateway mandantensicher machen — einen eingegrenzten Schlüssel pro Mandant, Policy auf Workspace-Ebene, die jeder Mandant erbt, und Pro-Mandant-Overrides, wo ein Mandant mehr braucht — alles aus der Konsole, mit null Änderung an Ihrem Anwendungscode.
Alles hier bindet an Ihren Workspace und wird aus der Konsole konfiguriert. Ihre App ruft weiterhin https://api.orcarouter.ai/v1/chat/completions mit dem sk-orca-...-Schlüssel jedes Mandanten auf — nur die Policy im Gateway ändert sich. Konfigurationsaktionen benötigen die pro Schritt genannten Rollen; nur /v1/*-Relay-Aufrufe verwenden einen Mandanten-Schlüssel.

​
1. Das Modell für mandantenfähige KI-Sicherheit

Ein mandantenfähiges Gateway hat eine andere Bedrohungsform als eine einzelne App. Die Risiken, die zählen, skalieren mit der Anzahl der Mandanten:

Key-Leak = Blast-Radius eines Mandanten

Ein geleakter Mandanten-Schlüssel sollte nicht Ihr Konto leeren, Modelle aufrufen, die Sie nie exponiert haben, oder über das Budget dieses Mandanten hinausreichen können.

Cross-Mandant-Datenleck

Die PII eines Mandanten, die in geteilten Logs landet oder in einer Antwort, die an einen anderen Mandanten geroutet wird, bricht Ihr Datenisolations-Versprechen.

Ein lärmender Mandanten-Agent

Der Agent eines Mandanten, der auf einem Tool loopt oder beliebige Hosts holt, sollte das Gateway nicht für alle anderen verschlechtern.

Pro-Mandant-Compliance

Ein regulierter Mandant kann PII-Masking und Datenresidenz brauchen, die der Rest Ihrer Mandanten nicht braucht.
Das Modell unten besteht aus zwei Ebenen: einer Workspace-Baseline, die jeder Mandanten-Schlüssel erbt, plus Pro-Schlüssel-Scope und -Overrides, die einen Mandanten verschärfen, ohne die anderen zu berühren. Siehe Schlüssel, Policies, Workspaces eingrenzen für die vollständigen Auflösungsregeln.

​
2. Die Baseline: eine Workspace-Policy, die jeder Mandant erbt

Verfassen Sie Ihre Sicherheitshaltung einmal auf Workspace-Ebene, sodass jeder Mandanten-Schlüssel sie per Default erbt — keine Pro-Mandant-Duplizierung.
1

Ein Default-Guardrail

Verfassen Sie in Guardrails → Neues Guardrail eine benannte Policy (z. B. tenant-baseline) und markieren Sie sie als Workspace-Default (is_default). Fügen Sie eine PII-Regel hinzu, Stage input, Aktion mask, sodass kein Mandanten-Request rohe PII upstream trägt:
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "credit_card", "ssn", "ip"],
  "entity_actions": { "credit_card": "block", "ssn": "block" }
}
Jeder Mandanten-Schlüssel mit keiner expliziten Guardrail-Bindung fällt auf diesen Default zurück. Ein Guardrail zu verfassen erfordert die Rolle Developer.
2

Eine Default-Firewall-Policy

Wenn Ihre Mandanten Agenten betreiben, tun Sie dasselbe auf der Aktionsebene: Verfassen Sie in Firewall → Policies eine Default-Policy oder — schneller — öffnen Sie Firewall → Posture und wenden Sie das balanced-Autonomie-Level an. Das auditiert die Tool-Calls jedes Mandanten und flaggt PII workspace-weit, während es die destruktivsten Aktionen ablehnt, sodass Sie echtes Mandanten-Verhalten beobachten, bevor Sie breit durchsetzen. Developer-Rolle.
Rollen Sie die Baseline in der Reihenfolge observe → shadow → enforce aus, sodass eine neue Regel einen Mandanten nicht mitten im Flug brechen kann. Eine Firewall-Policy unterstützt ein Pro-Policy-shadow_mode-Flag (durchsetzende Verdikte loggen als [shadow] would …); starten Sie Guardrail-Regeln bei der flag-Aktion. Siehe Enforcement-Modi.

​
3. Ein eingegrenzter Schlüssel pro Mandant

Das ist der Kern der Mandanten-Isolation: teilen Sie nie einen Schlüssel über Mandanten hinweg und geben Sie einem Mandanten nie Ihren kontoweiten Schlüssel. Prägen Sie einen Schlüssel pro Mandant, eingegrenzt auf genau das, was dieser Mandant tun darf. Setzen Sie in API Keys → Neuer Schlüssel:
Setzen Sie credit_limit_usd auf die Obergrenze dieses Mandanten (0 = unbegrenzt). Das ist die einzelne wichtigste mandantenfähige Kontrolle: Ein geleakter oder missbrauchter Mandanten-Schlüssel kann immer nur das Budget dieses Mandanten verbrennen, niemals Ihr Konto. Siehe Denial-of-Wallet.
Schalten Sie model_limits ein (model_limits_enabled) und listen Sie nur das/die Modell(e), das/die der Plan dieses Mandanten enthält — sodass ein geleakter Schlüssel kein teures Modell ausführen kann, für das der Mandant nie bezahlt hat.
Setzen Sie environment (ein freiformiges Deployment-Label, z. B. prod / staging), sodass der Traffic eines Mandanten in Ihren Logs zurechenbar ist und Sie Produktions-Schlüssel auf einen Blick von Test-Schlüsseln unterscheiden können.
Setzen Sie allow_ips auf die Backend-Egress-IPs dieses Mandanten, wenn er von einem festen Server aus aufruft, und expired_time für Trial- oder zeitlich begrenzte Mandanten (-1 = läuft nie ab).
Jeder Mandanten-Schlüssel erbt automatisch das Workspace-tenant-baseline- Guardrail und die Default-Firewall-Policy — Sie haben einen eingegrenzten Schlüssel geprägt, und er ist bereits gesteuert. Der Schlüssel wird nach der Erstellung bei der Anzeige maskiert, kopieren Sie ihn also einmal, wenn Sie den Mandanten provisionieren.

​
4. Pro-Mandant-Overrides — einen verschärfen, ohne den Rest zu berühren

Die meisten Mandanten reiten auf der Baseline. Wenn einer mehr braucht — ein regulierter Mandant, ein Enterprise-Tier, ein Mandant auf einer Bewährungsliste — hängen Sie eine strengere benannte Policy an nur diesen Schlüssel:
Auf dem Schlüssel setzenEffekt für diesen einen Mandanten
guardrail_idTauscht ein strengeres benanntes Guardrail ein (z. B. Block-bei-PII).
firewall_policy_idTauscht eine engere Firewall-Policy ein (z. B. Default-Deny-Tools).
Die Auflösung unterscheidet sich zwischen den beiden Ebenen — kennen Sie den Unterschied:
Eine explizite guardrail_id (wenn sie existiert und aktiviert ist) gilt immer und fällt nie stillschweigend zurück. Wenn dieses angehängte Guardrail deaktiviert ist, bekommt der Schlüssel kein Guardrail — er fällt nicht auf den Workspace-Default. Lassen Sie guardrail_id ungesetzt (0/null), um den tenant-baseline-Default zu erben.
Eine angehängte firewall_policy_id gilt, wenn sie existiert und aktiviert ist; wenn diese Policy deaktiviert ist, fällt der Schlüssel auf die Default-Firewall-Policy des Workspaces zurück. (Das ist das Gegenteil des Guardrail-Aus-Schalter-Verhaltens — beabsichtigt.)
Das Bearbeiten einer benannten Policy verschiebt jeden daran gebundenen Schlüssel beim nächsten Aufruf. Wenn mehrere Mandanten eine strengere Policy teilen, trifft eine Bearbeitung alle auf einmal. Verwenden Sie eine distinkte benannte Policy pro Isolationsklasse, nicht eine riesige geteilte Policy, wenn Mandanten wirklich unterschiedliche Regeln brauchen.

​
5. Ein konkretes Zwei-Tier-Beispiel

Angenommen, Sie betreiben einen Free-Tier und einen regulierten Enterprise-Tier auf einem Workspace:
  1. Workspace-Baseline — tenant-baseline-Guardrail (PII-Mask auf Input, Block bei Karte/SSN) als is_default, plus das balanced-Firewall- Autonomie-Level. Jeder Mandant erbt dies.
  2. Free-Tier-Mandanten-Schlüssel — keine guardrail_id (erbt die Baseline), model_limits festgepinnt auf openai/gpt-4o-mini, ein niedriges credit_limit_usd.
  3. Enterprise-Mandanten-Schlüssel — guardrail_id gesetzt auf ein strengeres enterprise-pii-Guardrail (PII-block, nicht mask, auf Input; output-Stage-Secrets-Block), eine firewall_policy_id mit einer engeren Tool-Allowlist, eine höhere Credit-Obergrenze und allow_ips, festgepinnt auf ihr Backend.
Beide Tiers rufen denselben /v1/chat/completions-Endpunkt mit ihrem eigenen Schlüssel auf. Das Gateway löst die richtige Policy pro Schlüssel auf — Ihr Anwendungscode ist für jeden Mandanten identisch.

​
6. Pro-Mandant-Compliance & -Residency

Ein regulierter Mandant braucht oft eine Attestierung, die der Rest nicht braucht. Compliance läuft als Workspace-Peer von Guardrails und Firewall:
  • Das Durchsuchen des Framework-Katalogs und der Readiness ist für jedes Mitglied offen und kostenlos — bestätigen Sie die Abdeckung für das Framework, nach dem ein Mandant fragt (soc2, hipaa, gdpr, iso_27001, pci_dss und mehr).
  • Das Installieren eines Packs (POST /api/compliance/packs/:key/install) materialisiert die passenden Guardrails und Firewall-Policies in Ihren Workspace; es erfordert Workspace-Admin und einen kostenpflichtigen Plan.
  • Datenresidenz pinnt die Region Ihres Compliance-Report-Artefakts (us / eu / uk / ap / cn / global) über PUT /api/compliance/residency (Admin). Cross-Region-Lesungen werden zurückgehalten.
Residency steuert hier das Compliance-Report-Artefakt, nicht das Geo-Pinning von Inferenzdaten. Zur Request-Log-Geschichte: Logs werden für einen Default von 30 Tagen aufbewahrt (hart begrenzt auf 180), und eine Nutzer-Selbstlöschung läuft 30 Tage Grace, dann ein PII-Scrub, der zu den Guardrail-Matches und Request-Logs dieses Nutzers kaskadiert.
Für einen vollständigen auditierten Evidenz-Lauf siehe SOC-2-Evidenz generieren und für HIPAA deployen.

​
7. Jeden Mandanten aus einem Workspace beobachten

Alle Observability ist workspace-bezogen, sodass ein Satz von Feeds alle Ihre Mandanten abdeckt — filterbar bis auf einen einzelnen:
  • Guardrails → Matches (jedes Mitglied) — jede Regel, die über alle Mandanten feuerte: Typ, Aktion, Stage, Detail. Der gematchte Teilstring wird nur aufgezeichnet, wenn Log raw content für dieses Guardrail an ist (per Default aus — die datenschutzkonservative Haltung, die in der Mandantenfähigkeit am meisten zählt). Markieren Sie ein False Positive zum Tunen (Admin).
  • Firewall → Events / Runs (Developer+) — jeder Tool-Call, aufgerollt pro Agentenlauf, sodass die Schleife eines lärmenden Mandanten oder ein neuartiger Egress heraussticht.
  • Anomalie-Feed (Member) — Raten-/Kosten-Spikes, bewertet gegen eine gelernte Hour-of-week-Baseline, fangen einen Mandanten, der außerhalb des Musters verbrennt, selbst wenn jeder Aufruf einzeln erlaubt ist.
Ein blockierter Request gibt HTTP 400 (guardrail_blocked / firewall_blocked) zurück, kostet diesen Mandanten kein Kontingent und ist als skip-retry markiert — die Grenze hielt, ohne den Mandanten für die Ablehnung zu berechnen.

​
8. Wo es tiefer geht

Schlüssel, Policies, Workspaces eingrenzen

Die vollständige Auflösungsreihenfolge für Schlüsselbindung und Workspace-Defaults.

Guardrails-Referenz

Jeder Regeltyp, jede PII-Entität und jeder Pro-Entitäts-Override in Gänze.

Firewall-Referenz

Verdikte, Surfaces, Autonomie-Level und die Policy-Ebene.

Datenexfiltration stoppen

Den ausgehenden Egress eines Mandanten-Agenten eingrenzen.