Your first week

The mistake is to configure everything on day one. Memnox is monitor-first for a reason: the first job is to find out what your organization actually does, and you cannot write a rule about that before you have seen it.

Day 1. Install, and change nothing

Engineers

bash

npx memnox setup

Restart your editor. That is the whole day's work on this side.

Everyone else

Sign in, finish onboarding, and connect two systems, one where the conversation happens, one where the work happens. See Quickstart: your organization.

Day 2. Read what came in

Open Activity. You are checking three things:

events are arriving from both sources;
each one links back to its original;
authors are resolving to people, not to unrecognised handles.

bash

memnox status     # on the engineering side
memnox audit

The line to look at is "Observed: N would have been stopped if enforcing". That number is the whole point of this phase.

Day 3. Read what would have been blocked

bash

memnox audit | grep BLOCK

Every one of those lines is a conversation:

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 it

Something you did not know was happening

This is the day Memnox earned its cost

Narrow the rules that fire wrongly now, while nothing is enforced and nobody is blocked. See Writing policies.

Day 4. Run extraction, review the queue

Run extraction once and work the review queue with somebody who was in the relevant conversations.

Expect a mixed batch. Approve what is genuinely a decision, reject the rest briskly, rejection is signal, not failure. See The review queue.

Day 5. Enforce one thing

Not everything. One rule, the one everybody already agrees with, usually production database protection or force-pushes to main.

Copy the policy file, make that one edit in the copy, and simulate the copy against what is currently in force:

bash

cp memnox.policies.yaml candidate.yaml
# edit candidate.yaml
memnox policy simulate -f candidate.yaml

simulate replays your real audit history through both rule sets and prints every decision that would differ. Simulating the live file against itself reports nothing, which is why the copy matters.

If the differences are only the lines you expected:

bash

memnox setup --enforce

Then tell the team, in the channel they actually read, what is now enforced and who to ask when it fires. A rule nobody was told about is a support ticket.

The end of week one

You should have:

events arriving from two systems, with people resolved;
a policy file whose blocks you have all read;
one rule enforced, and everyone told;
a handful of approved decisions with real approvers;
somebody named as the person who reads the review queue weekly.

That last one is the difference between a tool that gets adopted and one that gets forgotten.

Week two and beyond

From observing to enforcing

Widening enforcement one rule at a time.

Connect more systems

Each source makes the graph meaningfully better than the last.