Vai al contenuto principale
Se gestisci un agent di supporto pagamenti, un bot di triage dei chargeback, o qualsiasi workflow LLM che si trova in qualunque modo vicino a un Primary Account Number, la domanda non è “il mio modello è PCI-certified” — nessun modello lo è. La domanda è se il data plane tra la tua app e il modello può impedire a un PAN, a un segreto di carta, o a una chiamata a tool distruttiva di raggiungere il modello o di girare contro il tuo cardholder data environment. È questo che il pack PCI DSS ti dà: un insieme di controlli del gateway mappati su PCI DSS 4.0, installati in una sola chiamata, che producono evidenze firmate — con il confine organizzativo dichiarato chiaramente in anticipo.
Il tuo cardholder data environment (CDE) — segmentazione, accesso fisico, e la tua information-security policy — è responsabilità della tua organizzazione, non un controllo che il gateway può applicare. OrcaRouter può mascherare i PAN, bloccare i segreti di carta, negare i tool pericolosi, e firmare le evidenze — ma il programma CDE è tuo. Il pack dichiara quelle clausole come controlli organizzativi che attesti, mai come copertura automatizzata. Vedi il confine qui sotto.

​
1. Cosa significa governance “pci dss ai” sul gateway

Il pack PCI DSS (pci_dss, PCI DSS 4.0) mappa i requisiti dello standard su controlli live del gateway. Come ogni compliance pack, installarlo materializza policy reali e modificabili di Guardrail e Firewall nel tuo workspace — non aggiunge un nuovo motore di runtime. Tre controlli applicabili fanno il lavoro sui dati dei titolari di carta:
pci.pan_block (PCI DSS Req 3.4, rendere il PAN illeggibile) blocca i numeri di carta validati con Luhn nei prompt prima che raggiungano il modello, e li abbina agli strumenti di bank-routing — IBAN e codici SWIFT/BIC — protetti dalla loro parola di contesto letterale così un numero di fattura o ID di tracking in maiuscolo che condivide solo la forma strutturale non viene falsamente rifiutato. La detection del PAN cavalca l’entità PII credit_card, quindi il controllo Luhn è integrato.
pci.secret_hygiene (PCI DSS Req 8.3, crittografia forte per le credenziali) blocca le chiavi API e le chiavi private dal transitare nel gateway, così una credenziale non può trapelare in un prompt o una risposta. Questo è il guardrail Secrets Blocker — lo stesso controllo che intercetta i segreti su ogni richiesta.
pci.dangerous_tools (PCI DSS Req 2.2, configurazioni sicure) è una regola di firewall che nega le chiamate a tool di classe shell ed exec attraverso ogni convenzione di naming — su entrambe le superfici inbound e MCP — così un agent non può eseguire un comando distruttivo che tocca i dati dei titolari di carta. Tutto il resto resta al default audit della policy.
I primi due controlli vivono sul piano dei contenuti (Guardrails); il terzo vive sul piano delle chiamate a tool (Firewall). L’installazione li fonde in un guardrail e una policy di firewall che possiedi e puoi regolare.
Altre due clausole escono con il framework ma sono marcate organizzative: mantenere una information-security policy (Req 12.1) e limitare l’accesso fisico ai dati dei titolari di carta (Req 9). Quelli sono controlli su persone-e-processo che un proxy non può mai applicare — il report li dichiara come attested o come gap, non come copertura automatizzata. L’onestà è il punto.

​
2. Installa il pack PCI DSS — un esempio concreto

La configurazione di compliance usa la tua sessione di console, mai una chiave di relay sk-orca-…. Sfogliare il catalogo e controllare la readiness sono gratis per qualsiasi Member del workspace; installare è un’azione da Admin del workspace su un piano a pagamento, server-gated in entrambi i sensi.
1

Apri il pack PCI DSS

Nella console del workspace, vai su Compliance → Catalog e apri PCI DSS 4.0 (vive sotto la categoria financial). Ogni controllo elenca il suo piano, il suo requisito, e un deep link alla document library ufficiale del PCI SSC.
2

Installa in observe mode

Come Admin del workspace su un piano a pagamento, clicca Install. Il pack si materializza immediatamente in observe mode — il guardrail segnala anziché bloccare, il firewall gira in shadow — così raccogli prima evidenze “avrebbe-bloccato” contro il traffico reale.
3

Osserva, poi vai live

Lascia che i controlli in shadow accumulino match, passali in rassegna, poi porta il pack live per attivare le azioni dichiarate block / deny. Vedi Observe vs enforce.
La console guida un solo endpoint sotto il tuo token di sessione Admin — mostrato qui così puoi auditarlo o scriptarlo, non come qualcosa che chiami con una chiave di relay: 
POST /api/compliance/packs/pci_dss/install
Authorization: Bearer <your-console-session-token>
Content-Type: application/json

{ }
Un body vuoto installa ogni controllo del pack. La risposta è il record di installazione — la versione fissata, mode: observe, e il guardrail_id e il firewall_policy_id delle due policy materializzate così puoi aprirle subito.
Poiché l’installazione produce oggetti guardrail e firewall standard, puoi collegare la policy firewall materializzata a una chiave di agent tramite firewall_policy_id, collegare il guardrail a una chiave tramite guardrail_id (o impostarlo come default del workspace), e regolare la regola del PAN entità-per-entità — esattamente come una policy che hai autorato a mano.

​
3. Il confine onesto — il CDE è tuo

Un programma PCI è molto più di un filtro di redazione. Il gateway copre i controlli che un data plane può effettivamente applicare; tutto il resto resta alla tua organizzazione. Ecco lo split, tracciato allo stesso modo della mappa di responsabilità condivisa:
Area di controlloIl gateway applicaLa tua organizzazione possiede
PAN nel trafficoBlocca PAN verificati con Luhn, IBAN, SWIFT/BIC nei promptDefinire lo scope di quali campi sono dati dei titolari di carta
Segreti di cartaBlocca chiavi API / private in transito nel gatewayCustodia delle chiavi fuori dal percorso del gateway
Tool pericolosiNega le chiamate shell / exec vicine al CDEMettere in sicurezza i tool che aggirano il gateway
CDE & policy— (dichiarato come attested / gap)Segmentazione; accesso fisico; la policy InfoSec
Il gateway è il percorso sottoposto ad audit, non un intercettore a livello kernel. Un tool che il tuo agent esegue interamente in-process — uno che non attraversa mai https://api.orcarouter.ai e non riporta mai una destinazione di egress — è al di fuori della vista del firewall. Instrada i tool e le chiamate MCP che toccano i dati dei titolari di carta attraverso il gateway (tramite il gateway MCP del Firewall) così il controllo sui tool pericolosi può vederli, o mettili in sicurezza tu stesso dentro il tuo CDE.

​
4. Dimostralo — evidenze firmate e region-stamped

Una volta che il pack è live, genera un report PCI DSS. I report sono firmati Ed25519 e marcati SHA-256, esportabili come CSV / JSON / PDF, e verificabili pubblicamente — un assessor può confermare l’autenticità di un report senza un login. Ogni riga traccia un requisito fino all’esatta policy guardrail o firewall che la applica e i match che ha prodotto sul periodo; le due clausole organizzative rendono come gap dichiarati o attestazioni dell’owner. Dichiari anche una regione di data-residency per l’artefatto report (us / eu / uk / ap / cn / global) — i report firmati sono archiviati e serviti solo sotto la tua regione dichiarata, e una lettura cross-region viene trattenuta. Questo marca l’artefatto di evidenze, non la geografia dell’inferenza.
Installare un pack e andare live richiedono il ruolo Admin del workspace su un piano a pagamento, applicato lato server. La generazione dei report è Admin (piano gratuito: un PDF; CSV/JSON e report aggiuntivi sono a pagamento); impostare la residency è Admin-gated. Sfogliare il catalogo e controllare la readiness restano gratis. Vedi Plan gating.

​
5. Dove andare dopo

Installa un pack

L’intero flusso di installazione — selezione dei controlli, observe mode e go-live.

Report firmato

Cosa contiene il report di evidenze PCI DSS firmato Ed25519.

Verifica un report

Come un assessor conferma che un report è autentico senza un login.

Riferimento Guardrails

Il piano dei contenuti che il pack materializza — entità PII, Secrets Blocker, azioni.

Chiamate a tool pericolose

La minaccia da cui il controllo del firewall difende.

Data residency

Dichiarare la regione sotto cui le tue evidenze firmate sono archiviate e servite.
Il pack PCI DSS trasforma i requisiti 4.0 che puoi mettere su un data plane in masking dei PAN, blocco dei segreti, negazione dei tool pericolosi, ed evidenze firmate che puoi consegnare a un assessor — dicendo chiaramente che il CDE, la segmentazione, e la tua information-security policy restano tuoi. Per il resto del catalogo, vedi Framework.