Enforce what your agents can do

Norviq is a policy enforcement point for LLM agent tool calls. Every call the agent submits is evaluated against OPA/Rego policy scoped to the workload's identity, and returned as allow, block, escalate, or audit before the tool runs.

Get started Take the product tour View on GitHub

This site documents Norviq 0.2.5 — chart 0.2.5, appVersion 0.2.5, PyPI package norviq==0.2.5. Every install command on the site pins --version 0.2.5.

Install

Kubernetes 1.30 or newer (the chart declares kubeVersion: ">=1.30.0-0" and helm install refuses on anything older), kubectl, and Helm 3.

# 1. Create the tenant namespace FIRST — it gets a namespaced ResourceQuota, so it must exist.
kubectl create namespace chatbot-prod

# 2. Install the control plane into its own namespace.
helm install norviq oci://ghcr.io/norviq-dev/charts/norviq --version 0.2.5 \
  -n norviq --create-namespace \
  --set 'policyQuotaNamespaces={chatbot-prod}'

# 3. Reach the console (port-forward is the eval path; use an ingress in production).
kubectl -n norviq port-forward svc/norviq-ui 8080:80

The CRDs (NrvqPolicy, NrvqClass, NrvqConfig) ship inside the chart, so Helm installs them on first install — there is nothing to kubectl apply beforehand. PostgreSQL, Redis and OPA are bundled; nothing external is required.

Sign in at http://localhost:8080 as admin. The chart generates a strong random first password on install and preserves it across upgrades:

kubectl get secret norviq-secrets -n norviq -o jsonpath='{.data.NRVQ_AUTH_ADMIN_PASSWORD}' | base64 -d ; echo

You are forced to change it on first sign-in, and nothing writes the new password back to that Secret — store it yourself. Prefer no password at all? pip install norviq then norviq login -n norviq --console-url http://localhost:8080 mints a short-lived token inside the API pod and prints a sign-in deep link.

Two things that bite on a first install

policyQuotaNamespaces is required, not optional. It defaults to [], and with baselineClusterPolicy.enabled=true (the default) an empty list fails the install rather than rendering no baseline. List your tenant namespaces, or set baselineClusterPolicy.enabled=false to run without a cluster baseline explicitly.
A stock install observes; it does not drop. baselineClusterPolicy.enforcementMode defaults to audit in 0.2.5 (it was block). The rendered per-namespace baseline evaluates every control, records a non-compliance event, and lets the call proceed. Set it to block, or promote individual controls, once you know the blast radius. The class policies you apply yourself enforce regardless of the baseline’s mode.

The full walkthrough — from install to watching a decision flip from allow to block — is in Get started.

Start here

Get started

Install the chart, sign in, apply a policy to an agent class, and watch a tool call flip from allow to block. Start the walkthrough →

How it works

Intercept → identify → evaluate → enforce: the deployed components, the decision path, and zero-touch internal mTLS. See how it works →

Concepts

Agent identity, policy tiers and precedence, enforcement modes, trust score, and the asset & attack graph. Read the concepts →

New to the product rather than the install? What is Norviq is the one-page problem statement.

Choose an enforcement model

Both paths produce the same allow / block / escalate / audit decisions from the same policy model. The PEP is cooperative in both: the agent asks Norviq for a decision and the agent executes the tool, so a process that never asks reaches its tools directly. Bound that at the network layer with agentEgressPolicy.enabled=true (needs a NetworkPolicy-enforcing CNI — Calico or Cilium).

Sidecar injection

Enforcement as a property of the deployment: a mutating webhook injects the sidecar, wires every container to it, and delivers its credentials through a Secret. The agent image, build and credentials are untouched. Set up the sidecar →

SDK integration

In-process enforcement for LangChain, LangGraph, CrewAI, AutoGen and Semantic Kernel tool calls. See the adapters →

Author policy

Writing policies

Author NrvqPolicy Rego, positive-security allowlists, tighten-only overlays, and validation. Write a policy →

Policy cookbook

Copy-paste NrvqPolicy recipes — baselines, allowlists, human-approval escalation — plus validated Rego building blocks. Open the cookbook →

Understand & defend

Asset & attack graphs

See every agent’s real reach, walk the kill chains, Simulate a path against live policy, and Defend the gaps with generated drafts. Explore the graphs →

Compliance & coverage

Map enforced policy to MITRE ATLAS and the OWASP LLM Top 10 (2025), close gaps with generated remediation, and export an evidence pack. Check coverage →

Example — end to end

Protect a real agent from “no controls” to enforced: define its class, apply policy, deploy it, confirm the block. Walk the example →

Operate

CLI reference

First login, password recovery, policies, audit, agent trust, red team, and fleet — every norviq command. Open the reference →

Configuration

The helm/norviq/values.yaml reference, grouped by component, with the shipped defaults. Configure the chart →

Deployment

From a first install through production HA, cloud (AKS / EKS), and the multi-cluster fleet. Deploy Norviq →

Security model

Trust boundaries, threat model, authentication & authorization, multi-tenancy, and supply chain. Review the model →

SPIFFE/SPIRE identity

Opt-in high-assurance workload identity — bring your own SPIRE plus the SPIFFE CSI driver and switch Norviq to attested SVIDs. Set it up →