AI Runtime Security
ZNYX inspects prompts, model responses, streams, retrieved context, and tool calls as they happen, escalating deterministic to ML to LLM-judge and failing closed on a scorecard gate. The runtime is open-source and self-hosted, so enforcement runs in your own boundary.
Definition
AI runtime security enforces LLM guardrails in real time on live traffic: every prompt, response, stream, and tool call is evaluated against policy at request time and blocked or transformed before it can do harm. ZNYX runs this enforcement in a self-hosted runtime through a deterministic to ML to LLM-judge ladder with a fail-closed gate, so the safety decision is made in your boundary, not after the fact.
Defense in depth
Each detector declares its own strategy on the ladder. Cheap exact checks run first, fuzzy signals escalate to ML, and the hardest calls reach an audited judge. The combined result must clear a fail-closed scorecard gate before the request proceeds.
Layer 1 · Deterministic
Pattern, regex, checksum, allowlist, and schema checks run on every request with negligible cost. They catch known-bad signals - leaked secrets, malformed structured output, blocked topics - and resolve most traffic before any model is touched.
Layer 2 · ML
When deterministic rules are not enough, per-detector ML models score nuanced risks - prompt injection, jailbreak, toxicity, sentiment, PII entities - running in your in-boundary inference sidecar so payloads never leave your environment.
Layer 3 · LLM judge
The hardest calls escalate to an audited LLM-judge layer with K-member consensus and denial-of-wallet budgets. Judges adjudicate ambiguous intent and groundedness, and every judgment is recorded as an audit event.
Detector results across the ladder roll up into a scorecard, and the gate denies the request unless it meets policy thresholds. If a required detector errors or a model is unavailable, the default is to deny: uncertainty becomes a block, not a silent pass. Per policy, you can choose fail-open on non-critical paths.
The hot path
The runtime is built so the security decision is fast in the common case and the system scales by adding replicas. Enforcement does not become the bottleneck.
The escalation ladder runs deterministic rules before ML before judges, so the common case resolves on the cheap path and heavy models only run when a request is genuinely ambiguous.
Each runtime instance holds no per-request state. Verdicts are computed from the request plus bundle-delivered policy, so any replica can serve any request.
Because the hot path is stateless, you add capacity by adding runtime replicas behind your load balancer - no shared session store on the enforcement path.
Runtime security has to behave predictably even when something breaks. ZNYX makes the failure mode an explicit, per-policy choice rather than an accident.
Many LLM apps stream responses token by token. ZNYX evaluates Server-Sent Events (SSE) streams as they flow, so policy applies to streamed output, not only to a final buffered response.
Go deeper
The runtime is the enforcement seam. See where it sits relative to the control plane, and how the same engine powers the AI firewall on the request path.
How the self-hosted runtime, the in-boundary inference sidecar, and the control plane split enforcement from operations.
Explore the architectureThe same engine on the request path: input and output filtering, an egress and DLP gate, and structured-output enforcement.
See the AI firewallFAQ
How real-time enforcement, the fail-closed gate, latency, streaming, and graceful degradation work in the ZNYX runtime.
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.