Skip to main content
If you run a payments support agent, a chargeback triage bot, or any LLM workflow that sits anywhere near a Primary Account Number, the question isn’t “is my model PCI-certified” — no model is. The question is whether the data plane between your app and the model can keep a PAN, a card secret, or a destructive tool call from reaching the model or running against your cardholder data environment. That’s what the PCI DSS pack gives you: a set of gateway controls mapped to PCI DSS 4.0, installed in one call, producing signed evidence — with the organizational boundary stated plainly up front.
Your cardholder data environment (CDE) — segmentation, physical access, and your information-security policy — is your organization’s responsibility, not a control the gateway can enforce. OrcaRouter can mask PANs, block card secrets, deny dangerous tools, and sign evidence — but the CDE program is yours. The pack discloses those clauses as organizational controls you attest to, never as automated coverage. See the boundary below.

​
1. What “pci dss ai” governance means on the gateway

The PCI DSS pack (pci_dss, PCI DSS 4.0) maps requirements of the standard to live gateway controls. Like every compliance pack, installing it materializes real, editable Guardrail and Firewall policies in your workspace — it does not add a new runtime engine. Three enforceable controls do the cardholder-data work:
pci.pan_block (PCI DSS Req 3.4, render PAN unreadable) blocks Luhn-validated card numbers in prompts before they reach the model, and pairs them with bank-routing instruments — IBANs and SWIFT/BIC codes — guarded by their literal context word so an uppercase invoice or tracking ID that merely shares the structural shape isn’t falsely rejected. PAN detection rides the credit_card PII entity, so the Luhn check is built in.
pci.secret_hygiene (PCI DSS Req 8.3, strong cryptography for credentials) blocks API keys and private keys from transiting the gateway, so a credential can’t be leaked into a prompt or response. This is the Secrets Blocker guardrail — the same control that catches secrets on every request.
pci.dangerous_tools (PCI DSS Req 2.2, secure configurations) is a firewall rule that denies shell- and exec-class tool calls across every naming convention — on both the inbound and MCP surfaces — so an agent can’t run a destructive command that touches cardholder data. Everything else stays at the policy’s audit default.
The first two controls live on the content plane (Guardrails); the third lives on the tool-call plane (Firewall). Install merges them into one guardrail and one firewall policy you own and can tune.
Two more clauses ship with the framework but are marked organizational: maintaining an information-security policy (Req 12.1) and restricting physical access to cardholder data (Req 9). Those are people-and-process controls a proxy can never enforce — the report discloses them as attested or as gaps, not as automated coverage. The honesty is the point.

​
2. Install the PCI DSS pack — one concrete example

Compliance configuration uses your console session, never a relay sk-orca-… key. Browsing the catalog and checking readiness are free for any workspace Member; installing is a workspace Admin action on a paid plan, server-gated both ways.
1

Open the PCI DSS pack

In the workspace console, go to Compliance → Catalog and open PCI DSS 4.0 (it lives under the financial category). Each control lists its plane, its requirement, and a deep link to the official PCI SSC document library.
2

Install in observe mode

As workspace Admin on a paid plan, click Install. The pack materializes immediately in observe mode — the guardrail flags instead of blocking, the firewall runs in shadow — so you collect “would-have-blocked” evidence against real traffic first.
3

Watch, then go live

Let the shadow controls accumulate matches, review them, then take the pack live to switch the declared block / deny actions on. See Observe vs enforce.
The console drives one endpoint under your Admin session token — shown here so you can audit or script it, not as something you call with a relay key: 
POST /api/compliance/packs/pci_dss/install
Authorization: Bearer <your-console-session-token>
Content-Type: application/json

{ }
An empty body installs every control in the pack. The response is the install record — the pinned version, mode: observe, and the guardrail_id and firewall_policy_id of the two materialized policies so you can open them straight away.
Because install produces standard guardrail and firewall objects, you can attach the materialized firewall policy to an agent key by firewall_policy_id, attach the guardrail to a key by guardrail_id (or set it workspace-default), and tune the PAN rule entity-by-entity — exactly like a policy you authored by hand.

​
3. The honest boundary — the CDE is yours

A PCI program is far more than a redaction filter. The gateway covers the controls a data plane can actually enforce; everything else stays with your organization. Here’s the split, drawn the same way as the shared-responsibility map:
Control areaGateway enforcesYour organization owns
PAN in trafficBlock Luhn-checked PANs, IBAN, SWIFT/BIC in promptsScoping which fields are cardholder data
Card secretsBlock API / private keys transiting the gatewayKey custody outside the gateway path
Dangerous toolsDeny shell / exec calls near the CDESecuring tools that bypass the gateway
CDE & policy— (disclosed as attested / gap)Segmentation; physical access; the InfoSec policy
The gateway is the audited path, not a kernel-level interceptor. A tool your agent runs entirely in-process — one that never crosses https://api.orcarouter.ai and never reports an egress destination — is outside the firewall’s view. Route cardholder-data-touching tools and MCP calls through the gateway (via the Firewall MCP gateway) so the dangerous-tool control can see them, or secure them yourself inside your CDE.

​
4. Prove it — signed, region-stamped evidence

Once the pack is live, generate a PCI DSS report. Reports are Ed25519-signed and SHA-256-stamped, exportable as CSV / JSON / PDF, and publicly verifiable — an assessor can confirm a report’s authenticity without a login. Each row traces a requirement down to the exact guardrail or firewall policy enforcing it and the matches it produced over the period; the two organizational clauses render as disclosed gaps or owner attestations. You also declare a data-residency region for the report artifact (us / eu / uk / ap / cn / global) — signed reports are stored and served only under your declared region, and a cross-region read is withheld. This stamps the evidence artifact, not the geography of inference.
Installing a pack and going live require workspace Admin on a paid plan, enforced server-side. Report generation is Admin (free plan: one PDF; CSV/JSON and additional reports are paid); setting residency is Admin-gated. Browsing the catalog and checking readiness stay free. See Plan gating.

​
5. Where to go next

Install a pack

The full install flow — control selection, observe mode, and go-live.

Signed report

What the Ed25519-signed PCI DSS evidence report contains.

Verify a report

How an assessor confirms a report is authentic without a login.

Guardrails reference

The content plane the pack materializes — PII entities, Secrets Blocker, actions.

Dangerous tool calls

The threat the firewall control defends against.

Data residency

Declaring the region your signed evidence is stored and served under.
The PCI DSS pack turns the 4.0 requirements you can put on a data plane into PAN masking, secret blocking, dangerous-tool denial, and signed evidence you can hand an assessor — while saying plainly that the CDE, segmentation, and your information-security policy stay yours. For the rest of the catalog, see Frameworks.