Risk, drift and incidents

Governance that only ever answers allow or block misses the middle: an agent doing nothing forbidden, in a pattern that should worry somebody.

Memnox scores that, and opens an incident when the score or the pattern crosses a line. Both are deterministic, no model scores your agents.

Risk level vs risk score

Two different things, and confusing them causes arguments.

Risk level (low → critical) is a property of the action: classified from the verb and the environment. database.drop in production is critical whoever asks for it, on their first day or their thousandth.

Risk score (0 to 100) is a property of this action by this agent right now, measured against what that agent normally does.

What the score is built from

A rolling 14-day baseline per agent: which actions it performs and how often, which environments it touches, its block ratio, and which hours of the day it is active in.

Against that baseline, each of these adds weight:

Factor

The action's own risk level

A critical action starts high

Novel action

This agent has never done this before

First production

This agent's first touch of production

Block streak

Consecutive refusals, something is trying repeatedly

Burst rate

Far above its own normal rate

Tainted session

It read untrusted content earlier in this session

Off hours

Outside its own active-hour profile, not outside yours

That last distinction matters. A batch agent that has always run at 03:00 is not suspicious at 03:00. "Off hours" is measured against the agent's own history, not against office hours.

The four detectors

An incident opens on one of exactly four triggers. Each maps to one rule, and there is no fifth "the model thought this looked odd".

Trigger

unrecovered_execution

An action ran, failed verification, and the rollback also failed

break_glass_override

A human pushed an action past a pending approval

repeated_blocks

One agent hit 5 blocks inside 30 minutes, boundary probing

critical_risk_score

A scored action landed at or above 90

unrecovered_execution is the most serious thing this product reports. It is the case where nobody knows what state the system is in.

Incidents do not multiply

An agent hammering the same rule would otherwise open an incident per event. While an incident with the same (agent, trigger) pair is unresolved, new evidence attaches to the existing one for 24 hours instead of opening another.

Each incident keeps up to 50 evidence events, enough to investigate, bounded so one loop cannot fill a table.

The lifecycle

open  →  acknowledged  →  resolved

Acknowledging says someone has seen this. Resolving requires a resolution note and records who wrote it. lastSeenAt keeps an incident that recurs visibly hot even after it was acknowledged.

Console → Incidents, one critical incident expanded with its evidence list

screenshot slot, save as public/screens/…png and set src

Every incident cites the exact audit events behind it. The summary is one sentence a human can act on, not a chart.

Explaining a score

bash

memnox explain <eventId>

Lists the top contributing factors for that event, each with the weight it added. Because scoring is deterministic, the explanation is the calculation, not a narrative produced afterwards to justify it.

The console shows the same breakdown on the audit event, and on the incident that a high score opened.

Notification, with a cooldown

Scores at or above 80 notify. The same agent does not notify again for an hour.

A monitoring system that pages you thirty times for one incident is a monitoring system you turn off, so the cooldown is part of the design rather than a setting somebody has to discover.

Responding to an incident

From the alert to the policy that prevents the repeat.

Incidents in the console

Where they appear, and who they reach.