In Exposure Management, Stealth Should Mean Restraint

A scan mode called “stealth” can sound theatrical. The useful version is much less exciting: do less, say what was skipped, and make escalation deliberate.

May’s RedBlue work forced me to define the term in code rather than in marketing language. If a mode is meant to reduce impact, the scheduler and scanners must change their behaviour. A badge in the interface is not enough.

Question

How should a low-impact exposure workflow behave so an operator can distinguish genuine restraint from an ordinary scan with a quieter label?

Method

I traced the feature across three commits: the runtime flag and timeline event, the engine change that skipped loud scanners, and the later one-click rescan and escalation path. I checked whether the choice reached execution, evidence, and operator controls. The dated metadata is in the sanitised evidence record.

I did not compare network packet captures or claim that the mode is undetectable. “Stealth” here describes bounded platform behaviour, not invisibility to a target.

Evidence

The first change carried the mode into the scan record and reasoning timeline. That made the operator’s choice visible after launch instead of disappearing inside a request.

The second changed execution. The autonomous engine used the mode to skip loud scanners. This is the decisive difference between presentation and policy: the engine had fewer actions available.

The rescan work then created a controlled way to move in the other direction. An operator could repeat a target with a stronger mode instead of silently widening the original run. The parent-child relationship preserved why the later activity existed.

Finding

The design is useful because restraint becomes inspectable. A low-impact run should record what it attempted, what it withheld, and which later decision authorised escalation. The absence of a result must not be confused with the absence of exposure.

That principle reaches beyond one scan mode. Safety controls should change capability, not only language. When a workflow needs more intrusive checks, the expansion should be a new, explicit decision with its own scope and evidence trail.

Limitations

The commits show the intended control path. They do not quantify traffic reduction or prove that every scanner obeyed the mode in every historical deployment. The private code diff is not available for independent public review.

No label substitutes for written authorisation. Even passive or low-impact actions can be inappropriate outside an agreed scope. The platform can enforce configured boundaries, but the operator remains responsible for the legitimacy of those boundaries.