Open Source
Self-hosted runtimeSelf-host the open-source runtime and enforce policy in your stack. The full detection engine runs in your boundary, with no account and no metering.
AI Security Platform
The open-source AI security platform for LLMs & agents.
ZNYX secures the whole AI request path - inputs, retrieval, tool calls, agent steps, and outputs - behind one engine. It runs in your infrastructure on every plan, so your prompts, PII, and secrets stay inside your own boundary.
znyx · platformin your boundary
Self-hosted · in your VPC
ZNYX
runtime + sidecar
- ZNYX runtimeevaluate · enforce
- Inference sidecarML + judge models
- Your LLM / agentany provider
- Vector store & toolsMCP · retrieval
Data stays in boundary
Definition
What is an AI security platform?
An AI security platform inspects and governs the full request path of LLM and agentic applications - inputs, retrieved context, tool calls, agent steps, and outputs - enforcing policy in real time and producing audit-ready evidence. ZNYX runs this protection inside your own boundary, independent of any single cloud or model vendor, so sensitive data never has to leave your environment to be secured.
What that means here
- Where inspection runs
- your boundary
- Stages governed
- 8
- Cloud & model
- neutral
- Enforcement
- real time
- Evidence
- audit-ready
The platform
Four pillars, one platform
Each pillar is part of the same self-hosted engine. Compose them into policies and apply protection wherever your AI runs.
01
Runtime AI Firewall
Inputs, outputs & streams
Inspect every prompt, response, and token stream through a deterministic to ML to LLM-judge engine with a fail-closed scorecard gate.
- 40 detectors: prompt injection, jailbreak, PII (65+ types), secrets, toxicity, malicious URLs
- Remediation actions: block, redact, mask, re-ask, refrain, or ask-human
- Output egress/DLP gate with host allowlist and structured-output enforcement
02
Agentic AI Security
Plans, steps & memory
Govern agents and the tools they call across retrieval, agent-plan, agent-step, and memory-write evaluation stages.
- MCP and tool-manifest supply-chain scanning with tool-output guards
- Embedding and vector integrity checks (OWASP LLM09) and excessive-agency limits
- Denial-of-wallet budgets to cap runaway tool and model spend
03
Evidence & Compliance
Proof you can hand auditors
Turn every decision into audit-ready evidence - coverage scorecards, detector quality metrics, and model cards.
- OWASP LLM Top-10 coverage scorecard mapped to your policies
- Detector scorecards: precision, recall, F1, AUROC, ECE, and per-language quality
- ISO 42001 model cards and audited LLM-judge events
04
Release Safety & Observability
Ship changes with confidence
Benchmark detectors, watch for drift, roll out model versions safely, and trace every request end to end.
- Benchmarks, drift detection, and model-version staging
- Traces with a detector waterfall, OpenTelemetry spans, and metric alerting
- FP/FN annotation feedback and a policy playground to test before you ship
znyx · platformin your boundary
Four pillars · one engine
ZNYXSelf-hosted runtime
One console
All four pillars, operated from one place
Author a policy, watch the detector waterfall, and export the evidence, without leaving your boundary. The runtime stays in your infrastructure on every plan.
Request path
Secure the whole request path
Point tools filter a single prompt. ZNYX applies policy at every stage a request moves through - from the user's input to the streamed response.
1
Input
Screen incoming prompts for injection, jailbreak, PII, secrets, toxicity, and policy topics before the model ever sees them.
2
Retrieval
Evaluate retrieved context and embedding/vector integrity to catch poisoned documents and indirect prompt injection (OWASP LLM09).
3
Tool calls
Scan MCP and tool manifests for supply-chain risk and guard tool outputs before they re-enter the model loop.
4
Agent steps
Check agent plans and individual steps for excessive agency, and enforce denial-of-wallet budgets across the run.
5
Output & stream
Apply an egress/DLP gate, enforce JSON schemas, and evaluate responses in real time over SSE streaming.
Data residency
Your data stays in your boundary
The detection runtime is open source and runs in your environment. An in-VPC inference sidecar keeps ML and LLM-judge models in your boundary too, so prompts, PII, and secrets are inspected without being shipped to a third party.
- Open-source runtime - pull it, inspect it, run it anywhere.
- In-VPC inference sidecar runs ML and judge models inside your network.
- Cloud- and model-neutral, with an air-gappable Enterprise option.
Inspection in, metadata out
Runs in your environment
The open-source runtime and an in-boundary inference sidecar evaluate prompts, outputs, tool payloads, and ML/judge models inside your VPC.
What the hosted console sees
Operational metadata by default: trace id, policy decision, detector summary, latency, and scope, not prompt and response bodies.
Enterprise option
Self-host the control plane as well for fully private, air-gappable deployment.
Deployment tiers
Same engine, different placement
Starter, Growth, and Enterprise run the exact same security engine - only where the control plane lives and how teams operate it differs.
Starter
Free hosted consoleThe hosted console on its free tier: policy versioning, traces, and evidence for one project, at 10,000 evaluations a month.
Growth
+ team operationsAdd the hosted control plane for centralized policies, evidence, traces, and team workflows - inspection still runs in your VPC.
Enterprise
Fully privateSelf-host the control plane too for a fully private, air-gappable deployment with SSO/SAML, SCIM, MFA, and data residency.
FAQ
Frequently asked questions
How the platform secures LLMs and agents, how it differs from other open-source guardrails, and how self-hosting keeps your data in your boundary.
An AI security platform inspects and governs the full request path of LLM and agentic applications - inputs, retrieved context, tool calls, agent steps, and outputs - enforcing policy in real time and producing audit-ready evidence. ZNYX is an open-source, self-hostable AI security platform that runs this protection inside your own boundary, so prompts, PII, and secrets never have to leave your environment.
Yes. The detection runtime is open source and runs entirely in your environment. You can also self-host the control plane for a fully private, air-gappable deployment, or use the optional hosted console for centralized policies, evidence, and traces while inspection still happens in your boundary.
Managed tools like AWS Bedrock Guardrails, Azure Prompt Shields, and Google Model Armor are coupled to a single cloud and model family. ZNYX is independent, open-source, and cloud- and model-neutral: it secures the same way whether you run OpenAI, Anthropic, an open-weights model, or several at once, and your data stays in your boundary.
ZNYX evaluates inputs (prompt injection, jailbreak, PII, secrets), retrieved context and embeddings, tool and MCP manifests, individual agent steps and plans, and the model output and stream. A single deterministic to ML to LLM-judge engine with a fail-closed gate applies your policy at each of these stages.
Not your application traffic. Inspection runs in your boundary via the open-source runtime and an in-VPC inference sidecar, and the hosted console receives operational metadata by default - trace id, policy decision, detector summary, latency, and scope - not prompt and response bodies. The one exception is text you type into the console's policy playground yourself, which is evaluated by the console and not persisted. Enterprise can self-host the control plane to keep everything private.