From watching it to letting it run

The point of this sequence is not that Memnox refuses more over time. It is that you supervise less over time, and each step is a decision you make with a real day of work in front of you.

It also avoids the reason governance tools get removed: refusing something legitimate, loudly, at a bad moment, with nobody able to explain why fast enough.

Nothing in this sequence needs an account.

Where you start

memnox setup leaves a machine in observe, and it stays there until you say otherwise. Every seam is in the path and every rule is matched, but nothing is refused: the verdict is recorded and the action proceeds.

bash

memnox status
memnox doctor --wiring

status says the machine is watching rather than stopping, and its today row counts what enforce would have asked and denied, which is the number this whole page is about.

That is the question worth asking first, and it is not "what is risky here". It is whether Memnox is gating anything at all, because a verdict nobody is obliged to ask for is advice. The reading is on Coverage and containment.

Step 1. Read what would have been refused

bash

memnox timeline --only deny --since 7d

Every line is a conversation, and it is one of three things:

The line looks like

Something you genuinely want stopped

Good. It stays

Something routine that should not be flagged

The rule is too broad. Narrow the match: add a target, a directory or a branch

Something you did not know was happening

This is the day Memnox earned its cost

Do this while nothing is enforced. Editing a rule after it has refused a colleague is a much worse conversation. See Writing policies.

Step 2. Roll one rule out at a time

mode = "observe" on a single rule rolls it out without enforcing it, while the rest of the file enforces normally.

toml

[[policies]]
name = "candidate-rule"
[policies.match]
actions = [ "deploy.*" ]
[policies.decision]
effect = "deny"
mode = "observe"

Use it for the rule you are least sure about. The recorded event carries the verdict it would have applied, so you get a week of evidence at no cost to anybody's day.

Step 3. Check the file before you commit it

bash

memnox policy check                       # every rule file this machine loads
memnox policy test 'git push --force origin main'

policy check exits non-zero when something will not parse, so CI can run it, and it reads each file on its own so one repository's broken file never blanks another's. policy test answers what one action would get, without running it.

Step 4. Enforce the uncontroversial rule

Pick the one everybody already agrees with. Production database protection. Force-pushes to main. Credential files.

bash

memnox config set mode enforce

memnox protect --enforce is the same setting. A rule still carrying mode = "observe" from step 2 keeps observing after the switch, so mark every rule you are not yet sure of before you flip it.

Then announce it: what is enforced, what happens when it fires, and who to ask. In the channel people read, not in a document. A rule nobody was told about is a support ticket.

Step 5. Widen, one rule per week

Resist enforcing the whole file at once. One rule a week gives you a small blast radius when a rule turns out to be wrong, a clear cause when something breaks, and a team that learns the rules rather than working around them.

Step 6. Turn approvals on

ask is where most of the long-term value is, and it is also where rollouts stall. Two things decide whether it works.

Route to people who will actually look.

bash

memnox approvals

Each line carries how long it has been waiting. Rising numbers are the earliest sign that a rule is routed to the wrong group: the rule is not wrong, the audience is. Fix the approvers list before somebody fixes it for you by deleting the rule.

Scope with time windows so overnight automation does not sit waiting for a person who is asleep:

toml

[policies.match]
windows = [ { days = [ 1, 2, 3, 4, 5 ], startHour = 17, endHour = 9 } ]

When something does break

bash

memnox why            # the last thing that did not simply proceed, and its rule
memnox trace <id>     # that one action end to end
memnox rewind         # the working tree, back to before the agent touched it

why reads back from the recorded row rather than re-evaluating against today's rules, so the answer is what was decided and not what would be decided now. That distinction is what makes it worth trusting during an incident.

Writing policies

Narrowing a rule that fires too widely.

Approvals and delegation

The loop, and how to keep it from stalling.