Saltar para o conteúdo principal
Se você roda um agente de suporte a pagamentos, um bot de triagem de chargebacks, ou qualquer fluxo de LLM que fica perto de um Primary Account Number, a pergunta não é “meu modelo é certificado PCI” — nenhum modelo é. A pergunta é se o plano de dados entre a sua app e o modelo consegue impedir que um PAN, um segredo de cartão ou uma chamada de ferramenta destrutiva chegue ao modelo ou rode contra o seu cardholder data environment. É isso que o pack PCI DSS te dá: um conjunto de controles de gateway mapeados para o PCI DSS 4.0, instalados em uma chamada, produzindo evidência assinada — com a fronteira organizacional declarada claramente de antemão.
Seu cardholder data environment (CDE) — segmentação, acesso físico e sua política de segurança da informação — é responsabilidade da sua organização, não um controle que o gateway pode aplicar. O OrcaRouter pode mascarar PANs, bloquear segredos de cartão, negar ferramentas perigosas e assinar evidência — mas o programa de CDE é seu. O pack divulga essas cláusulas como controles organizacionais que você atesta, nunca como cobertura automatizada. Veja a fronteira abaixo.

​
1. O que a governança “pci dss ai” significa no gateway

O pack PCI DSS (pci_dss, PCI DSS 4.0) mapeia os requisitos do padrão para controles ao vivo do gateway. Como todo compliance pack, instalá-lo materializa políticas reais e editáveis de Guardrail e Firewall no seu workspace — ele não adiciona um novo motor de runtime. Três controles aplicáveis fazem o trabalho de dados de portador de cartão:
pci.pan_block (PCI DSS Req 3.4, tornar o PAN ilegível) bloqueia números de cartão validados por Luhn em prompts antes que cheguem ao modelo, e os combina com instrumentos de roteamento bancário — IBANs e códigos SWIFT/BIC — protegidos pela sua palavra de contexto literal para que uma fatura ou ID de rastreamento em maiúsculas que apenas compartilha a forma estrutural não seja falsamente rejeitado. A detecção de PAN usa a entidade de PII credit_card, então a checagem de Luhn é embutida.
pci.secret_hygiene (PCI DSS Req 8.3, criptografia forte para credenciais) bloqueia chaves de API e chaves privadas de transitar pelo gateway, de modo que uma credencial não possa ser vazada em um prompt ou resposta. Este é o guardrail Secrets Blocker — o mesmo controle que captura segredos em cada requisição.
pci.dangerous_tools (PCI DSS Req 2.2, configurações seguras) é uma regra de firewall que nega chamadas de ferramenta da classe shell e exec em toda convenção de nomenclatura — nas superfícies inbound e MCP — de modo que um agente não possa rodar um comando destrutivo que toca dados de portador de cartão. Todo o resto permanece no padrão audit da política.
Os primeiros dois controles vivem no plano de conteúdo (Guardrails); o terceiro vive no plano de chamada de ferramenta (Firewall). A instalação os mescla em um guardrail e uma política de firewall que você possui e pode ajustar.
Mais duas cláusulas vêm com o framework mas são marcadas organizacionais: manter uma política de segurança da informação (Req 12.1) e restringir o acesso físico aos dados de portador de cartão (Req 9). Essas são controles de pessoas-e-processo que um proxy nunca pode aplicar — o relatório as divulga como atestadas ou como gaps, não como cobertura automatizada. A honestidade é o ponto.

​
2. Instale o pack PCI DSS — um exemplo concreto

A configuração de compliance usa a sua sessão de console, nunca uma chave de relay sk-orca-…. Navegar pelo catálogo e verificar a prontidão são gratuitos para qualquer Member do workspace; instalar é uma ação de Admin do workspace em um plano pago, gated no servidor de ambos os lados.
1

Abra o pack PCI DSS

No console do workspace, vá em Compliance → Catalog e abra PCI DSS 4.0 (ele vive sob a categoria financial). Cada controle lista seu plano, seu requisito e um deep link para a biblioteca de documentos oficial do PCI SSC.
2

Instale em observe mode

Como Admin do workspace em um plano pago, clique em Install. O pack materializa imediatamente em observe mode — o guardrail sinaliza em vez de bloquear, o firewall roda em shadow — então você coleta evidência de “would-have-blocked” contra o tráfego real primeiro.
3

Observe, depois vá ao ar

Deixe os controles em shadow acumularem correspondências, revise-as, depois leve o pack ao ar para ligar as ações declaradas de block / deny. Veja Observe vs enforce.
O console conduz um endpoint sob o seu token de sessão de Admin — mostrado aqui para que você possa auditá-lo ou criar um script, não como algo que você chama com uma chave de relay: 
POST /api/compliance/packs/pci_dss/install
Authorization: Bearer <your-console-session-token>
Content-Type: application/json

{ }
Um corpo vazio instala todos os controles no pack. A resposta é o registro de instalação — a versão fixada, mode: observe, e o guardrail_id e o firewall_policy_id das duas políticas materializadas para que você possa abri-las imediatamente.
Como a instalação produz objetos de guardrail e firewall padrão, você pode vincular a política de firewall materializada a uma chave de agente por firewall_policy_id, vincular o guardrail a uma chave por guardrail_id (ou defini-lo como padrão do workspace), e ajustar a regra de PAN entidade-por-entidade — exatamente como uma política que você autorou à mão.

​
3. A fronteira honesta — o CDE é seu

Um programa PCI é muito mais do que um filtro de redação. O gateway cobre os controles que um plano de dados pode de fato aplicar; tudo o mais continua com a sua organização. Aqui está a divisão, desenhada da mesma forma que o mapa de responsabilidade compartilhada:
Área de controleO gateway aplicaSua organização possui
PAN no tráfegoBloquear PANs verificados por Luhn, IBAN, SWIFT/BIC em promptsEscopar quais campos são dados de portador de cartão
Segredos de cartãoBloquear chaves de API / privadas que transitam pelo gatewayCustódia de chaves fora do caminho do gateway
Ferramentas perigosasNegar chamadas shell / exec perto do CDEProteger ferramentas que contornam o gateway
CDE & política— (divulgado como attested / gap)Segmentação; acesso físico; a política de InfoSec
O gateway é o caminho auditado, não um interceptador em nível de kernel. Uma ferramenta que seu agente roda inteiramente in-process — uma que nunca cruza https://api.orcarouter.ai e nunca reporta um destino de egress — está fora da visão do firewall. Roteie ferramentas e chamadas de MCP que tocam dados de portador de cartão através do gateway (via o gateway MCP do Firewall) para que o controle de ferramenta-perigosa possa vê-las, ou proteja-as você mesmo dentro do seu CDE.

​
4. Prove — evidência assinada e carimbada por região

Uma vez que o pack esteja ao ar, gere um relatório PCI DSS. Os relatórios são assinados com Ed25519 e carimbados com SHA-256, exportáveis como CSV / JSON / PDF, e verificáveis publicamente — um avaliador pode confirmar a autenticidade de um relatório sem um login. Cada linha rastreia um requisito até a política exata de guardrail ou firewall que o aplica e as correspondências que ele produziu sobre o período; as duas cláusulas organizacionais renderizam como gaps divulgados ou atestações do owner. Você também declara uma região de residência de dados para o artefato de relatório (us / eu / uk / ap / cn / global) — os relatórios assinados são armazenados e servidos apenas sob a sua região declarada, e uma leitura cross-region é retida. Isto carimba o artefato de evidência, não a geografia da inferência.
Instalar um pack e ir ao ar exigem Admin do workspace em um plano pago, aplicados no servidor. A geração de relatório é Admin (plano gratuito: um PDF; CSV/JSON e relatórios adicionais são pagos); definir a residência é gated por Admin. Navegar pelo catálogo e verificar a prontidão continuam gratuitos. Veja Plan gating.

​
5. Para onde ir a seguir

Instale um pack

O fluxo completo de instalação — seleção de controles, observe mode e go-live.

Relatório assinado

O que o relatório de evidência PCI DSS assinado com Ed25519 contém.

Verifique um relatório

Como um avaliador confirma que um relatório é autêntico sem um login.

Referência de Guardrails

O plano de conteúdo que o pack materializa — entidades de PII, Secrets Blocker, ações.

Chamadas de ferramenta perigosas

A ameaça contra a qual o controle de firewall defende.

Residência de dados

Declarar a região sob a qual sua evidência assinada é armazenada e servida.
O pack PCI DSS transforma os requisitos do 4.0 que você pode colocar em um plano de dados em mascaramento de PAN, bloqueio de segredos, negação de ferramenta perigosa e evidência assinada que você pode entregar a um avaliador — enquanto diz claramente que o CDE, a segmentação e a sua política de segurança da informação continuam sendo seus. Para o resto do catálogo, veja Frameworks.