Zum Hauptinhalt springen
Wenn Sie einen Payments-Support-Agenten, einen Chargeback-Triage-Bot oder einen beliebigen LLM-Workflow betreiben, der irgendwo in der Nähe einer Primary Account Number sitzt, lautet die Frage nicht „ist mein Modell PCI-zertifiziert” — kein Modell ist es. Die Frage ist, ob die Datenebene zwischen Ihrer App und dem Modell eine PAN, ein Karten-Secret oder einen destruktiven Tool-Call davon abhalten kann, das Modell zu erreichen oder gegen Ihre Karteninhaberdaten-Umgebung zu laufen. Genau das gibt Ihnen das PCI-DSS-Pack: ein Satz Gateway-Kontrollen, abgebildet auf PCI DSS 4.0, in einem Aufruf installiert, signierte Nachweise erzeugend — mit der organisatorischen Grenze klar im Voraus angegeben.
Ihre Karteninhaberdaten-Umgebung (CDE) — Segmentierung, physischer Zugang und Ihre Informationssicherheits-Policy — ist die Verantwortung Ihrer Organisation, keine Kontrolle, die das Gateway durchsetzen kann. OrcaRouter kann PANs maskieren, Karten-Secrets blockieren, gefährliche Tools verweigern und Nachweise signieren — aber das CDE-Programm gehört Ihnen. Das Pack legt diese Klauseln als organisatorische Kontrollen offen, die Sie attestieren, nie als automatisierte Coverage. Siehe die Grenze unten.

​
1. Was „pci dss ai”-Governance am Gateway bedeutet

Das PCI-DSS-Pack (pci_dss, PCI DSS 4.0) bildet Anforderungen des Standards auf Live-Gateway-Kontrollen ab. Wie jedes Compliance-Pack materialisiert seine Installation echte, editierbare Guardrail- und Firewall-Policies in Ihrem Workspace — es fügt keine neue Runtime-Engine hinzu. Drei durchsetzbare Kontrollen erledigen die Karteninhaberdaten-Arbeit:
pci.pan_block (PCI DSS Req 3.4, PAN unlesbar machen) blockiert Luhn-validierte Kartennummern in Prompts, bevor sie das Modell erreichen, und paart sie mit Bank-Routing-Instrumenten — IBANs und SWIFT/BIC-Codes — geschützt durch ihr wörtliches Kontextwort, sodass eine Großbuchstaben-Rechnungs- oder Tracking-ID, die bloß die strukturelle Form teilt, nicht fälschlich abgelehnt wird. Die PAN-Erkennung reitet auf der credit_card-PII-Entität, sodass die Luhn-Prüfung eingebaut ist.
pci.secret_hygiene (PCI DSS Req 8.3, starke Kryptografie für Credentials) blockiert API-Keys und Private Keys vom Transitieren durch das Gateway, sodass ein Credential nicht in einen Prompt oder eine Response geleakt werden kann. Das ist das Secrets-Blocker-Guardrail — dieselbe Kontrolle, die Secrets auf jedem Request auffängt.
pci.dangerous_tools (PCI DSS Req 2.2, sichere Konfigurationen) ist eine Firewall-Regel, die Shell- und Exec-Klasse-Tool-Calls über jede Namenskonvention hinweg verweigert — auf sowohl der inbound- als auch der MCP-Surface — sodass ein Agent keinen destruktiven Befehl ausführen kann, der Karteninhaberdaten berührt. Alles andere bleibt beim audit-Default der Policy.
Die ersten zwei Kontrollen leben auf der Content-Ebene (Guardrails); die dritte lebt auf der Tool-Call-Ebene (Firewall). Die Installation verschmilzt sie zu einem Guardrail und einer Firewall-Policy, die Ihnen gehört und die Sie tunen können.
Zwei weitere Klauseln werden mit dem Framework ausgeliefert, sind aber als organisatorisch markiert: das Aufrechterhalten einer Informationssicherheits-Policy (Req 12.1) und das Einschränken des physischen Zugangs zu Karteninhaberdaten (Req 9). Das sind People-and-Process-Kontrollen, die ein Proxy niemals durchsetzen kann — der Report legt sie als attestiert oder als Lücken offen, nicht als automatisierte Coverage. Die Ehrlichkeit ist der Punkt.

​
2. Das PCI-DSS-Pack installieren — ein konkretes Beispiel

Die Compliance-Konfiguration nutzt Ihre Konsolen-Session, niemals einen Relay-sk-orca-…-Key. Das Durchstöbern des Katalogs und das Prüfen der Readiness sind für jedes Workspace-Mitglied kostenlos; das Installieren ist eine Workspace-Admin-Aktion auf einem kostenpflichtigen Plan, beidseitig server-gated.
1

Das PCI-DSS-Pack öffnen

Gehen Sie in der Workspace-Konsole zu Compliance → Catalog und öffnen Sie PCI DSS 4.0 (es lebt unter der financial-Kategorie). Jede Kontrolle listet ihre Ebene, ihre Anforderung und einen Deep Link zur offiziellen PCI-SSC-Dokumentbibliothek.
2

Im Observe-Mode installieren

Klicken Sie als Workspace-Admin auf einem kostenpflichtigen Plan auf Install. Das Pack materialisiert sofort im Observe-Mode — das Guardrail flaggt statt zu blockieren, die Firewall läuft im Shadow — sodass Sie zuerst hätte-blockiert-Nachweise gegen echten Traffic sammeln.
3

Beobachten, dann live schalten

Lassen Sie die Shadow-Kontrollen Matches ansammeln, prüfen Sie sie, und schalten Sie dann das Pack live, um die deklarierten block / deny-Aktionen einzuschalten. Siehe Observe vs. Enforce.
Die Konsole treibt einen Endpunkt unter Ihrem Admin-Session-Token — hier gezeigt, damit Sie ihn auditieren oder skripten können, nicht als etwas, das Sie mit einem Relay-Key aufrufen: 
POST /api/compliance/packs/pci_dss/install
Authorization: Bearer <your-console-session-token>
Content-Type: application/json

{ }
Ein leerer Body installiert jede Kontrolle im Pack. Die Response ist der Install-Datensatz — die gepinnte Version, mode: observe und die guardrail_id und firewall_policy_id der zwei materialisierten Policies, sodass Sie sie sofort öffnen können.
Weil die Installation Standard-Guardrail- und Firewall-Objekte erzeugt, können Sie die materialisierte Firewall-Policy via firewall_policy_id an einen Agenten-Key anhängen, das Guardrail via guardrail_id an einen Key anhängen (oder es workspace-default setzen) und die PAN-Regel Entität für Entität tunen — genau wie eine Policy, die Sie von Hand verfasst haben.

​
3. Die ehrliche Grenze — das CDE gehört Ihnen

Ein PCI-Programm ist weit mehr als ein Redaktionsfilter. Das Gateway deckt die Kontrollen ab, die eine Datenebene tatsächlich durchsetzen kann; alles andere bleibt bei Ihrer Organisation. Hier ist die Aufteilung, gezeichnet genauso wie die Geteilte-Verantwortung-Karte:
KontrollbereichGateway setzt durchIhre Organisation besitzt
PAN im TrafficLuhn-geprüfte PANs, IBAN, SWIFT/BIC in Prompts blockierenScopen, welche Felder Karteninhaberdaten sind
Karten-SecretsAPI- / Private Keys blockieren, die das Gateway transitierenKey-Verwahrung außerhalb des Gateway-Pfads
Gefährliche ToolsShell- / Exec-Calls in der Nähe des CDE verweigernTools absichern, die das Gateway umgehen
CDE & Policy— (offengelegt als attested / gap)Segmentierung; physischer Zugang; die InfoSec-Policy
Das Gateway ist der auditierte Pfad, kein Kernel-Level-Interceptor. Ein Tool, das Ihr Agent vollständig in-Prozess ausführt — eines, das nie https://api.orcarouter.ai überquert und nie ein Egress-Ziel meldet — liegt außerhalb des Sichtfelds der Firewall. Routen Sie karteninhaberdaten-berührende Tools und MCP-Calls durch das Gateway (über das Firewall-MCP-Gateway), sodass die Gefährliche-Tool-Kontrolle sie sehen kann, oder sichern Sie sie selbst in Ihrem CDE.

​
4. Beweisen Sie es — signierter, regions-gestempelter Nachweis

Sobald das Pack live ist, erzeugen Sie einen PCI-DSS-Report. Reports sind Ed25519-signiert und SHA-256-gestempelt, exportierbar als CSV / JSON / PDF und öffentlich verifizierbar — ein Assessor kann die Authentizität eines Reports ohne Login bestätigen. Jede Zeile verfolgt eine Anforderung hinab zur exakten Guardrail- oder Firewall-Policy, die sie durchsetzt, und den Matches, die sie über den Zeitraum erzeugt hat; die zwei organisatorischen Klauseln rendern als offengelegte Lücken oder Eigentümer-Attestierungen. Sie deklarieren außerdem eine Daten-Residency-Region für das Report-Artefakt (us / eu / uk / ap / cn / global) — signierte Reports werden nur unter Ihrer deklarierten Region gespeichert und ausgeliefert, und ein regionsübergreifender Lesezugriff wird zurückgehalten. Das stempelt das Nachweis-Artefakt, nicht die Geografie der Inferenz.
Ein Pack installieren und live schalten erfordern Workspace-Admin auf einem kostenpflichtigen Plan, serverseitig durchgesetzt. Die Report-Erzeugung ist Admin (kostenloser Plan: ein PDF; CSV/JSON und zusätzliche Reports sind kostenpflichtig); das Setzen der Residency ist Admin-gated. Das Durchstöbern des Katalogs und das Prüfen der Readiness bleiben kostenlos. Siehe Plan-Gating.

​
5. Wohin als Nächstes

Ein Pack installieren

Der vollständige Install-Flow — Kontrollauswahl, Observe-Mode und Live-Schalten.

Signierter Report

Was der Ed25519-signierte PCI-DSS-Nachweis-Report enthält.

Einen Report verifizieren

Wie ein Assessor bestätigt, dass ein Report ohne Login authentisch ist.

Guardrails-Referenz

Die Content-Ebene, die das Pack materialisiert — PII-Entitäten, Secrets Blocker, Aktionen.

Gefährliche Tool-Calls

Die Bedrohung, gegen die die Firewall-Kontrolle verteidigt.

Daten-Residency

Die Region deklarieren, unter der Ihr signierter Nachweis gespeichert und ausgeliefert wird.
Das PCI-DSS-Pack verwandelt die 4.0-Anforderungen, die Sie auf eine Datenebene legen können, in PAN-Maskierung, Secret-Blockierung, Gefährliche-Tool-Verweigerung und signierte Nachweise, die Sie einem Assessor übergeben können — während es klar sagt, dass das CDE, die Segmentierung und Ihre Informationssicherheits-Policy Ihnen bleiben. Für den Rest des Katalogs siehe Frameworks.