Editions and Runtime Guarantees

For: developers, security reviewers, and buyers who need one unambiguous answer to “what is free, what is paid, and what still holds if the agent is compromised?”

InnerWarden is sold in three tiers, the same three as Pricing: Community (free), Pro (paid, bought online) and Enterprise (paid, scoped with us). They share an agent decision model and dashboard contract, but they do not make the same security guarantee.

Pro and Enterprise install the same paid host stack from the same installer, with the same features; the licence carries no tier. What Enterprise adds is contractual: more hosts under one agreement, and the services listed below. The paid dashboard's header reads Enterprise on a Pro host too. That is a known limitation, not a design choice: the header does not show the licensed tier yet. The free Community dashboard's header reads Community.

	Community	Pro	Enterprise
Price	Free, open source	Per protected agent, bought online	Scoped per deployment
Primary job	Reduce risky agent actions before execution	Contain a compromised agent at the host boundary	The same, across a fleet, with organisation controls and assurance
Platforms	Linux, macOS, Windows	Linux for the kernel-enforced boundary	Linux for the kernel-enforced boundary
Privilege	Per-user; no root, sensor, or kernel component	Host installation; elevated privileges required	Host installation; elevated privileges required
Agent layer	Command hook, direct check, local API, MCP proxy	Everything in Community	Everything in Community
Host layer	None	Host sensor, eBPF telemetry, detectors, correlation, verified response	Everything in Pro
Kernel controls	None in the Community artifact	Agent-scoped Execution Gate and Secret Read Guard on supported BPF LSM kernels	Everything in Pro
Network control	MCP traffic inspection for wrapped local servers	DNS Guard (malicious domains refused, once armed) and host network detection	Everything in Pro
Evidence	Local Community decision history	Host decision chain, live outcome verification, signed off-host anchors for one host	Signed off-host anchors across the fleet
Scale and organisation	One developer machine	One operator, per-tenant attribution for Kubernetes pods	Multiple hosts under one agreement, with fleet operations across them. Multi-user access with roles and SSO is on the roadmap, not in the product yet
Assurance and service	None	The evidence mapped to ISO 27001 Annex A and MITRE, in the stack	Everything in Pro, plus an anomaly model trained on your infrastructure, curated policy and a managed allowlist, a quarterly assurance audit, SLA and support, air-gapped deployment design

"Everything in Community" means the Community binary, installed. The paid host stack is the host half of one product; the agent half is Community itself. The host installer puts it in place and joins the two, so a watched server is never a server whose own agents are unguarded, and the agent-facing verbs (check, contain, graph, observe, allow, mute, serve, hook, llm) come from that binary rather than from innerwarden-ctl. Typing innerwarden reaches both: anything the free CLI does not own is forwarded to the host CLI, which is why every host command in these docs is written that way.

Machines with no host stack, laptops, dev boxes, still need Community installed directly. There is no server there to do it for them.

Community is useful, not a demo

Community is the free, cross-platform innerwarden binary. It provides:

• deterministic allow, review, and deny decisions for integrated commands;
• inspection and enforcement for local MCP traffic placed behind the proxy;
• guided agent discovery and opt-in monitor-mode wiring;
• AI Jail on supported environments;
• local agent activity, token intelligence where a reviewed local source exists, dashboard, alerts, and decision history.

Install Community. The shortest path that works on a machine straight out of the box is the signed release script: curl -fsSL https://innerwarden.com/free | sh on macOS and Linux, irm https://www.innerwarden.com/free.ps1 | iex on Windows. It verifies sha256 and an Ed25519 signature before installing to ~/.local/bin, and needs no root. npm is equally supported and is the one path carrying npm provenance, though on Linux npm install -g needs sudo because npm's global prefix is root-owned there.

npm install -g innerwarden

Or run it once without installing:

npx innerwarden

Secondary methods are also available. Signed release, no Node required, on macOS or Linux:

curl -fsSL https://innerwarden.com/free | sh

On Windows PowerShell:

irm https://innerwarden.com/free.exe -OutFile innerwarden.exe

From source with Rust:

cargo install --git https://github.com/InnerWarden/inner-warden innerwarden

Community does not install the host sensor or a kernel control. Its direct check and local HTTP adapter are advisory unless the caller honors the verdict. Its command hook holds only where that supported hook is actually wired. Its MCP proxy holds only for the MCP servers placed behind it.

Pro and Enterprise assume an earlier layer can fail

Pro and Enterprise add the host stack and Active Defence. Their design assumption is that a prompt, dependency, tool result, or the agent process itself can be compromised.

On Linux, the paid host stack can add:

• eBPF host telemetry and cross-layer correlation;
• an agent-scoped Execution Gate that denies an unauthorized binary at bprm_check_security;
• an agent-scoped Secret Read Guard that denies access to declared sensitive paths at file_open;
• DNS Guard, verified response, binary-integrity checks, and restart supervision;
• host, agent, workload and per-tenant attribution;
• tamper-evident decision history and external anchor verification.

Neither paid tier makes a universal “kernel protected” claim. The kernel guarantee applies only when:

1. the host runs a supported Linux kernel;
2. BPF LSM is active;
3. the gate is scoped to the intended agent or workload;
4. observe mode has captured the legitimate workflow;
5. rehearsal reports no unresolved legitimate denial;
6. an operator explicitly enables enforcement; and
7. InnerWarden verifies the live kernel state rather than trusting configuration.

If any required state is missing, the dashboard must report unavailable, observe-only, degraded, or failed. It must not infer protection from an installed binary, a licence, or a configuration file.

DNS Guard

DNS Guard is a forwarding resolver that refuses to resolve malicious domains: in enforce, a lookup of a domain on its threat-feed denylist is answered NXDOMAIN, and every other lookup is forwarded upstream. It is a denylist, not an allowlist, so it does not make every domain wait for approval, and it only covers the processes pointed at it as their resolver.

It runs in observe by default: denylisted lookups are recorded and still resolve. The operator arms enforce. We recommend a rehearse first, which lists the domains that would have been refused; arming does not require one, and only asks whether it was run. From 0.16.68 a rehearse that measured nothing says so and exits non-zero: no heartbeat from the guard in the window, or nothing on the host resolves through it and nothing sent to it hit a list. The enforce path is shown in a lab recording on /proof. No host we run has DNS Guard in enforce today: on our public challenge box it is set to observe, and only the challenge agent is pointed at it.

What holds against which agent state

Agent state	Direct check / local API	Supported command hook	MCP proxy	Paid host and kernel boundary (Pro and Enterprise)
Cooperative	Holds when called	Holds for wired commands	Holds for wrapped servers	Observes and enforces when active
Buggy or careless	Bypassable if not called	Holds for wired commands	Holds for wrapped servers	Holds for scoped host actions
Compromised or hostile	Bypassable	Holds only while the hook remains in path	Holds for traffic that cannot route around the proxy	Holds outside the agent process when the live controls are active

The paid value is not “more rules.” It is the independent control boundary and the operational evidence that the boundary was actually active.

Agent discovery is not the same as agent-aware integration

InnerWarden can recognize supported agents from reviewed installation, process, or configuration markers. The paid host telemetry can also observe unknown processes. Neither fact alone means every action from every unknown agent carries semantic agent context.

For agent-aware command or tool policy, use one of the supported paths:

• a native agent hook;
• an MCP server wrapped by innerwarden proxy;
• the local HTTP adapter exposed by innerwarden serve; or
• a direct innerwarden check integration in a custom runner.

An unknown agent still benefits from the paid tiers' host detection and scoped containment after it is identified and attached to a workload boundary.

Source and distribution

The Community tier is open source (Apache-2.0) at github.com/InnerWarden/inner-warden: you can read and build the exact code. The paid stack (Pro and Enterprise) is source-available, not open source: shipped as signed binaries, with licensed source access for security review and audit under the InnerWarden Source-Available Licence. The presence of a host or kernel primitive in a source workspace does not mean it is part of the Community artifact or that a live Pro or Enterprise guarantee is active.

For installation details, continue to Install and First Run. For the exact bypass boundary of each agent layer, read AI Agent Guardrail. For safe activation, read Safe Observe and Allowlist.