Skip to content
Guard AI agents

Safe Observe and Allowlist

The never-blind workflow for tuning InnerWarden to a host: stay in observe, learn a baseline, verify each candidate, then arm enforcement gradually.

Safe Observe and Allowlist

For: operators (and AI agents acting for them) adapting InnerWarden to a specific machine, so it stops flagging what is genuinely normal, without handing an attacker a permanent free pass.

This is the page that keeps you out of trouble. Read it before you trust anything or arm enforcement. The agent-facing version of this same workflow ships on every box at /etc/innerwarden/AGENTS.md.

The trap, stated plainly

People will say, reasonably, "allowlist what is normal on this server so it stops alerting on it." The dangerous reading of that is "allowlist everything currently running." Do not do that.

The reason is simple and it is the whole point of running InnerWarden: malware on the box is "currently running" too. A miner, a reverse shell, an attacker's cron job, are all "normal" by the lazy definition of "it is here right now." If you allowlist by presence, you blind the tool to exactly the thing you installed it to catch, and you do it permanently. Blind-allowlisting is the single most damaging mistake you can make here.

So InnerWarden is built to never trust blindly. The safe workflow below goes through five gates, in order, and the product enforces some of them for you. Skipping ahead is what gets people compromised.

The never-blind workflow

1. Stay in observe / dry-run

A fresh install already starts here: it watches and explains, it does not block or kill. Nothing is being suppressed and nothing is being enforced, everything is logged. Confirm you are in this posture before doing anything else (the dry-run state is the responder setting; see Configuration for the key and CLI Reference for the command). This is your safe place to learn from.

2. Let the baseline learn

InnerWarden learns this host's normal over a window before it trusts anything: the event rate per hour by source, which process spawns which child, when users normally log in, where processes normally connect out. You do not configure "normal," it is observed. Check how far along that learning is with innerwarden get posture. Do not arm enforcement until there is a real baseline, an empty baseline trusts nothing and over-reacts to everything.

3. Review what is actually firing, do not guess

Look at the real activity before you decide anything is benign:

innerwarden get incidents --days 7
innerwarden get decisions --days 7

You are looking for the handful of things that fire repeatedly and that you can explain. An alert you cannot account for is a candidate for investigation, not for the allowlist.

4. Verify every candidate before you trust it

For each IP, user, or process you are tempted to allowlist, confirm it is genuinely benign. Do not take its presence as proof.

  • Cross-check reputation: innerwarden get entity <ip>, and the loopback check-ip from Connect Your Agent.
  • Confirm a flagged process is an expected service with a known parent, not something masquerading.
  • Ask a human to confirm anything ambiguous. An unexplained long-running process, or an outbound connection you cannot account for, is precisely what you must not wave through.

This is the gate attackers count on you skipping.

5. Propose, never silently apply, then arm gradually

Show the human the exact list you intend to trust and why. Add only what they confirm. The trust commands are owned by CLI Reference; the shape is:

innerwarden trust add --ip <addr> --reason "<why this is known-good>"
innerwarden trust list
innerwarden trust suppress <pattern>

One thing that surprises people, and is deliberate: trust means monitor-only. A trusted entity is still detected, still logged, still notified. Only the automatic block is held back. You keep full visibility even on things you trust, so if a "trusted" service starts behaving like an attacker you still see it. Trust suppresses the trigger, never the truth.

Only after a clean baseline and a human-confirmed trust list do you arm enforcement, and even then, gradually. Leave dry-run on first, watch the decisions it would have made, and remove dry-run only once you trust those decisions. The responder enable / dry-run controls live in CLI Reference and the underlying key in Configuration.

The safety floor the product enforces for you

You do not have to remember all of this perfectly, because InnerWarden holds a hard line in code:

  • The skill_gate proof floor. Before any block (or any decision that would suppress a block) executes, it is validated against your configuration. An allowlist-driven attempt to bypass a block without a valid proof cannot get through. Even a maliciously crafted AI response, a buggy detector, or a compromised upstream library cannot route around your policy without changing the gate's code, which would require a code review. The contract is documented in Trust and Safety Invariants. Do not try to work around it, it is there to protect you from your own automation.
  • Detection is never suppressed at detect time. False-positive handling happens in layers after detection (organised defaults, then the learned baseline, then AI triage, then your decision), never by switching a detector off at the source. Specific high-confidence signals stay always-on; only generic heuristics are ever relaxed.

The hard rules, restated: you are forbidden from auto-allowlisting a process, IP, or path just because it is present, and from arming enforcement before a clean baseline plus a human-confirmed trust list.

The stronger guarantee: Execution Gate rehearsal (paid Active Defence)

If you want pre-authorized-execution hardening, the Execution Gate adds a kernel allowlist for binaries. It is built around the same never-blind principle and gives you proof before you arm:

  • an observe mode that logs what would be denied and blocks nothing, and
  • a rehearsal that runs over a window and proves zero legitimate denials before you ever switch it to enforce.

That is the same discipline as the workflow above, made into a feature: measure the blast radius, prove it is empty, then arm. An honesty monitor also raises an alert if a signed allowlist is ever staged but not actually applied in the kernel, so the gate can never silently go inert. The Execution Gate arming tools are the separate paid Active Defence layer, not part of the standard CLI. The detection-and-audit side is included; arming the prevention is the paid Active Defence layer.

Where this connects