From observing to enforcing

Every governance tool that gets removed was removed for the same reason: it blocked something legitimate, loudly, at a bad moment, and nobody could explain why fast enough.

This is the sequence that avoids that.

Where you start

memnox setup leaves everything on and nothing enforced. A guard that fires writes an audit line and the action proceeds.

memnox status
# Observed  : 9 would have been stopped if enforcing

That number is your entire signal. When it is made up of things you genuinely want stopped, you are ready.

Step 1. Read every observed block

memnox audit | grep BLOCK

For each, decide which of three it is:

Do this while nothing is enforced. Editing a rule after it has blocked a colleague is a much worse conversation.

Step 2. Simulate against real history

memnox policy simulate -f candidate.yaml

This replays your actual audit history through the candidate rule set and reports every decision that would differ.

candidate.yaml is the edited copy; --against is what it is compared with, and defaults to the memnox.policies.yaml currently in force. Simulating the live file against itself reports nothing.

Read the permissive warnings first. The command warns loudly wherever an action becomes more permissive, and that is almost always an accident: a widened wildcard, a removed environment, a match field somebody deleted.

Step 3. Monitor mode on one rule

mode: monitor rolls a single rule out without enforcing it, while the rest of the file enforces normally.

  - name: candidate-rule
    match: { actions: ["deploy.*"] }
    decision:
      effect: block
      mode: monitor           # record what it would have done

Use it for the rule you are least sure about. The audit event records the verdict it withheld, so you get a week of evidence at no cost to anybody's day.

Step 4. Enforce the uncontroversial rule

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

memnox setup --enforce

Then announce it: what is enforced, what happens when it fires, and who to ask. In the channel people read, not in a document.

Step 5. Widen, one rule per week

Resist the urge to enforce 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;
• a team that learns the rules rather than working around them.

Step 6. Turn approvals on

require_approval 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. Watch approval latency weekly:

memnox approvals health

Rising latency means the audience is wrong, not that the rule is wrong. 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 human who is asleep:

      windows:
        - { days: [1,2,3,4,5], startHour: 17, endHour: 9 }

Step 7. Switch the default

The real hardening step. Until now, anything no rule matched was allowed.

memnox serve --default-effect block

Now anything unnamed is refused. Only do this when your policy coverage is good enough that you can name what your agents legitimately do, and expect to write several allow rules immediately afterwards.

When something does break

memnox explain <eventId>     # exactly which rule, and its reason
memnox approvals override <id> --reason "…"   # break-glass, audited as critical

Break-glass exists for this. Using it is not a failure; using it silently is.