synthesis · the system converging

Overview: the whole system converging

The overview closes the journey by putting it all in one picture: the layers, the pipeline that writes the verdict and the path a command travels from the agent to exit 2, before executing.

In 30 seconds

A polite prompt instruction does not contain an AI agent. Nemesis intercepts the action before it happens (pretool hook, write-time), scans the content and the command, and denies with exit 2 if hostile. In parallel, a daemon watches the filesystem and moves confirmed malware to quarantine. On Linux, an eBPF kernel layer holds exec and network as a backstop. Protection is not a count of detectors: it is the sum of layers, the so-called coefficient.

The three layers

Defense in depth means independent layers: if one fails or is under maintenance, the next still contains. There are three.

Layers 1 and 2 share the `scan_content` engine; layer 3 (eBPF) is an independent kernel backstop.

Why it matters

Layers 1 and 2 use the same content engine, so the security verdict is identical for identical bytes, whether at write time (pretool) or on the filesystem (daemon). This is declared and verified in the code itself: the single source of content rules is the embedded denylist-defender.json, applied by the regex layer and shared by both layers.

How it correlates: the command path

The flow that ties the ten groups together is this. The agent requests an action. The pretool translates it (the tool name becomes an intent, pre_run_command / pre_write_code), passes the content through the engine, and the engine returns a severity. If it is a block, the process exits with exit 2, and the IDE reads that as "denied". If a hostile file escaped to disk, the daemon finds it and moves it to quarantine. On Linux, if someone tries to execute a destructive binary, eBPF denies it in the kernel with -EPERM, even if the pretool is disconnected.

Nemesis flow: the agent attempts an action; layer 1 (pretool) blocks the hostile one with exit 2; layer 2 (daemon) quarantines what escaped; layer 3 (eBPF, kernel) is the safety net; everything is logged locally. — The full command path: from the agent action to the verdict, with the three layers and the 100% local log.

The three layers side by side: when they act, where, what they do and what they catch. Independent layers; protection is their sum. — The three layers side by side: when, where, what they do and what they catch.

How Nemesis applies it

The orchestrator is the scan_content function. It runs the stages in order and delegates the final decision to compute_severity.

📄 .nemesis/nemesis-defender/src/lib.rs:226-298 · orquestração do pipeline

pub fn scan_content(path: &Path, content: &[u8]) -> DefenderResult {
    if is_path_excluded(path) { /* early return Clean */ }
    let language = detect_language(path);
    let mut all_violations = Vec::new();
    // Layer 1: byte (BiDi/PUA/homoglyph/zero-width) · 4 sub-scans
    // Layer 2: entropia (Shannon)
    // Layer 3: regex (denylist-defender.json embutida)
    // Layer 4: manifesto · 4.5 ide_config · 4.6 exfil_chain
    // Layer 5: AST (tree-sitter)  · Layer 6: decoder recursivo (máx 3)
    all_violations.retain(|v| !allowlist_loader::is_allowlisted(&v.evidence));
    let severity = compute_severity(&all_violations);
    DefenderResult { severity, violations: all_violations, scan_depth, path, language }
}

The crate architecture is a Rust workspace with four members: nemesis-defender (engine + daemon + CLI), ebpf-kernel (Linux), nemesis-doctor (diagnostics) and ast-linters. The root package nemesis is at version 8.2.0 and produces the hook binaries.

📄 .nemesis/Cargo.toml:1-15 · workspace + pacote nemesis v8.2.0

Decisions and limits

The order commented in scanner/mod.rs (six layers) differs from the real execution in lib.rs: in practice the byte layer has four sub-scans and ide_config and exfil_chain also come in before the AST. The code is followed and the difference is explained in group 5. The daemon is made security-only: quality is solved by blocking the write (reversible), never by deleting (irreversible), detail in group 9.

And on macOS there is no kernel layer: with the pretool off, nothing contains; on Linux, eBPF covers it. No protection is assumed where it does not exist.

Self-check

▸Can the pretool and daemon layers diverge on the security verdict?

Not for the same content: both call scan_content, whose security rule source is single (denylist-defender.json via the regex layer). The only legitimate divergence is the quality layer, exclusive to the pretool at write time.

▸What is the "protection coefficient" and why is it not the count of visitors?

It is the sum of the independent layers (pretool, daemon, eBPF) and each one's taxonomies (embedded denylist, scanner heuristics, AST visitors, command denylists, egress allowlist). A visitor is just a detection method; counting visitors undercounts the real protection by an order of magnitude.

▸With the pretool off on Linux, is there any protection left?