Security Architecture Diagrams (Code-Synced)

Visual reference for how Mutant's runtime security pipeline, policy decisions, and probe gates fit together, kept in sync with current code behavior.

1. End-to-End Runtime Security Flow#

2. Policy Decision Flow#

The response is a pure function of the execution mode from argv: ResolveTamperResponse(secureMode) in security/response_policy.go. There is no override, and the profile diamond the earlier version of this diagram carried is gone -- ResolveProtectionProfile() returns the constant standard, so the minimal and paranoid branches are unreachable at runtime. They remain in ProtectionProfileFromCode only so a V3 release trailer can be read back. The delay response (DefaultTamperDelayMs = 250) is reachable through ApplyTamperResponse but no mode selects it. See CONFIGURATION_POLICY.md.

3. Anti-Tamper Probe Gates#

Both gates this diagram used to test are compile-time constants: antiTamperProbeEnabled is true and isProcessProtectionEnabled() returns true. Their false arms exist only for tests, which replace them directly. The confidence threshold is the sole remaining decision on the enforcement path. See ANTITAMPER_PROBE_ENABLEMENT_LLD.md.

4. Runner vs Builtin Probe Scope#

5. VM Integrity Scheduling#

6. Polymorphic Engine Reality Snapshot#

Note:

1. Mutation controls and seed are wired through CLI.
2. Advanced transform activation is intentionally constrained in current configuration.

7. Remote Scan Gate Model#

remoteScanConfigState (security/processscan_config.go) ships as Enabled: false, Mode: observe, and the only way to change it is SetRemoteScanConfigForTesting. Remote process scanning therefore never runs in a shipped binary. The Enabled: true arms are drawn because the code is exercised by tests, not because an operator can reach them; there is no flag for it yet. See CONFIGURATION_POLICY.md.

8. Memory Hardening Snapshot#