A general policy does not know what an NHS number looks like, that a card number should be Luhn-validated before you act on it, or that a matter ID is privileged. Five official packs encode that knowledge as detector defaults, and each one arrives with a benchmark dataset so you can measure it rather than trust it.
Every pack is a policy bundle you can read, diff, and edit. What differs between them is the identifiers they know about and the action each detector takes.
Multi-region PHI detection with redaction on by default, forced secret blocking, and the self-harm and grooming content categories that a patient-facing channel cannot ship without.
Medical record and health-insurance identifiers
US SSN, UK NHS and NINO, India Aadhaar and PAN, NL BSN, CA SIN
Date of birth, address, and clinical contact details
Self-harm and grooming categories force-enabled
pii · secrets · toxicity · jailbreak
benchmark: healthcare-phi-v1
finance5 detectors
Finance & Banking
Retail banking assistants, wealth and advice chatbots, payment support
PCI-DSS, GLBA, and banking-specific guardrails, including Luhn-validated card detection and the payment-processor secrets that leak most often in this vertical.
Credit cards, Luhn-validated rather than pattern-matched
SSN, EIN, ITIN, IBAN, UK UTR, India IFSC and UPI, Brazil CPF and CNPJ
Stripe live and test keys, Twilio, Slack tokens
Jailbreak-on-advice defence for regulated advice boundaries
Attorney-client privilege protection, matter-ID redaction, and contract-party PII masking, with leakage blocking on privileged content.
Matter IDs and privileged-content markers
Contract-party personal data, masked rather than refused
Privileged-content leakage blocked on the output path
Exfiltration checks on both directions
pii · secrets · jailbreak · exfiltration · topic
benchmark: legal-privilege-v1
code_assistant6 detectors
Code Assistant
IDE copilots, code-review bots, PR-triage assistants
Aggressive secret detection across every vendor SaaS token plus SSH keys and cloud credentials, code-safety scanning on what the model generates, and malicious-URL blocking.
Vendor SaaS tokens, SSH keys, and cloud credentials
Generated code scanned for injection, unsafe deserialisation, and weak crypto
Malicious and look-alike URLs in suggestions
Prompt-injection defence on repository and issue text
B2C and B2B support chatbots, knowledge-base assistants, ticket summarisation
Customer PII redacted in both directions, prompt injection and toxic escalation blocked, competitor mentions rewritten rather than refused, and the grooming force-block for channels that serve minors.
Customer PII redacted on the way in and the way out
Competitor mentions transformed, so the answer still ships
Loading a pack publishes a policy bundle with the pack's defaults. From there it behaves like any other bundle: it versions, it diffs against what was running before, it rolls back, and your own edits survive the next update to the pack. There is no separate enforcement path and nothing hidden from the trace.
docker compose -f docker-compose.healthcare.yml up
docker compose -f docker-compose.finance.yml up
# or load the pack into an existing deployment
python scripts/seed_packs.py --pack healthcare
FAQ
Guard Pack questions
What a pack sets, whether you need one, and how much of it you can change.
A vertical starting policy: which detectors are on, what action each one takes, and which identifiers matter in that industry, bundled with a benchmark dataset so you can measure it before you trust it. It is a starting point you then tune, not a black box - every value a pack sets is a value you can see and change.
No. The default bundle is industry-neutral and works without one. A pack matters when your vertical has identifiers a general policy will not know about - an NHS number, a matter ID, a Luhn-validated card - and where getting those wrong is the whole risk.
Yes, and you should. A pack is a policy bundle like any other: it versions, it diffs, it rolls back, and your edits survive an update to the pack itself. Nothing in a pack is enforced by ZNYX rather than by your own published bundle.
Each pack ships with its own benchmark dataset and a scorecard recording how its rules were measured, so the pack arrives with evidence rather than an assurance. Run it against your own traffic before you promote it to production - that is what the benchmark endpoint is for.
Secure every prompt, agent, and tool call, in your boundary.
Pull the open-source runtime, drop it into your stack, and start enforcing policy in minutes, free, forever. Add the hosted control plane when you want centralized policies, evidence, traces, and team workflows.