Nemesis Defender

Active, deterministic enforcement against supply-chain malware and LLM agent abuse blocks the attack at execution time, on the developer's machine.

01 Introduction

Nemesis exists to contain the AI agent's autonomy: the target is the LLM model, not you. It intercepts, the moment they try to execute, the operations the agent triggers (writing files, running commands) and blocks the destructive or malicious ones. The command itself isn't the enemy the model's autonomous invocation is.

Installation is automatic: it detects your IDE and wires the hooks for you. From then on enforcement is active at runtime the pretool blocks hostile writes/executions and the daemon (Iron Dome) watches the filesystem. On confirming hostility (by corroboration of independent signals, so legitimate code isn't moved by mistake) it moves it to quarantine (does not delete) and holds the session until your review it is reversible via restore or purge. On Linux there is also an optional eBPF layer (opt-in) as a kernel backstop should the pretool be bypassed.

The blocking rules are embedded in the binary (tamper-proof) the agent cannot weaken them by editing files. The only surface you (the human) edit is the allowlist (.nemesis/denylist-customers/allowlist-customers.jsonc): an absolute override, at your own risk, to permit what your stack needs. Nemesis is calibrated for frontend (Next/React/TS), so backend and DevSecOps tend to relax more there. And everything is removable: uninstalling is a single command (nemesis-uninstall.sh).

It is not a generic linter nor a passive scanner. It is a runtime enforcement harness for the AI-agent-driven development context, where seemingly innocuous output can hide manifest tampering, decode-then-exec of encoded payloads, Unicode steganography (CVE-2021-42574), prompt injection, credential exfiltration, and time-gated malware. Nemesis blocks these operations at the moment they try to execute.

The problem is real and current: in 2025 hundreds of thousands of malicious packages were published to npm, and campaigns like Shai-Hulud compromised packages with billions of weekly downloads. Nemesis Defender targets the window in which that code tries to execute on the developer's machine.

02 What IDEs ship

What IDEs and TUIs already ship and why it isn't enough on its own

The primitives already exist: lifecycle hooks, deny-list and sandbox are native features of IDEs and agents, and Nemesis Defender uses them. The hook and the sandbox were not invented here; Nemesis consolidates these pieces into a single enforcement framework, uniform across IDEs, plus a kernel layer none of them offer. No native tool delivers this full combination.

And this isn't specific to one tool. Each agent's official documentation was consulted: every major one converged on the same primitive a lifecycle hook that intercepts the call before execution and can block it. The table below shows each one's blocking mechanism, straight from the official docs.

The pattern is clear: the primitive is the same across all of them, and in all of them it is only the interception point. Note too that "exit code 2" is not a dedicated security mechanism: in the POSIX convention, 0 is success and any non-zero is failure, and 2 historically signals misuse of a shell built-in. The agents repurposed a generic shell error code as a "block" signal. All the logic that decides what is dangerous is still written by you.

In short: the native deny-list doesn't catch cat .env; the native sandbox doesn't catch Read/Edit nor a poisoned package; rules catch nothing because they're advisory; and kernel eBPF lives in the cloud, not on your machine. Each piece solves a fragment at most a few destructive commands, and not all of them. Nemesis Defender unites all the pieces into a single framework, with deny-list + content scanner (destructive and malicious) + AST + kernel eBPF as the last layer for Linux users, the same across Devin, Cursor, Codex, Claude Code and VS Code. The framework was born to solve a real problem and was released under AGPL-3.0 for anyone who wants to use it.

03 Genesis

Born from pain, not a drawing board

Nemesis Defender wasn't designed on a security whiteboard. It grew from concrete, repeated pain inside real production projects and evolved in three phases.

At first they were just text rules, trying to contain the same recurring errors: conditional hooks, setState in useEffect, any, duplicated typings, CSS outside tailwind.config, business logic in UI files. The lesson: a written rule is context input the model reads it, understands it, and still executes the neural pattern of "solve it fast". Instruction is not enforcement.

The conventions became hooks that actually run and block. The first leap was an automatic linter: instead of "please don't use any", the system started blocking the anti-pattern before it entered the repo. Deterministic, non-negotiable.

Rewritten in Rust, with the focus shifting to 100% security: command deny-list, content scanner, supply-chain detection and the eBPF kernel layer. The same philosophy that blocked any now blocks destructive rm -rf and credential exfiltration.

The thread connecting the three phases: the rules are strict because the pain of violations was real and recurring. Only enforcement that runs outside inference (lint-time, PreToolUse, kernel) closes the gap between rule and behavior.

04 Why it exists

Stop the destructive command before it runs

The most important function is everyday: stop an agent from unintentionally executing a command that destroys the project rm -rf in the wrong place, git reset --hard that wipes uncommitted work, config overwrite.

Anyone coding with LLM agents knows this isn't hypothetical: the model, trying to "help", runs a destructive command because it misread the context. Nemesis Defender intercepts before execution and requires human confirmation. It applies to the accidental error (the common case) and to malicious code.

Models operate by probabilistic inference telling it "don't run destructive commands" is an instruction the model can ignore, get wrong, or route around. Deterministic enforcement before execution is categorically different: whether the model was tricked or simply erred, the layer blocks. Reactive tools (linters, CI/CD, SAST) detect after; Nemesis Defender blocks before. Complementary to them not a replacement.

And there's a deeper point: a destructive action has three origins, and anything that inspects text or intent covers at most one. (1) Malicious input (prompt injection there's something to detect). (2) The model itself, from clean context (misalignment, reward-hacking, over-eagerness nothing malicious to track). (3) Human accident. Nemesis doesn't try to read the model's intent or the input: it blocks the action. The origin becomes irrelevant the rm -rf is stopped the same whether it comes from injection, misalignment or a wrong keystroke. It needs neither open weights nor guessing what the model "meant": the gate is deterministic and model-agnostic.

05 Authority line

The model operates; it does not destroy

The heart of the design is a clear split of what the AI can and cannot do:

• The AI uses the IDE's native write and edit tools but only inside the project scaffold.
• It can read some sensitive files when the work requires, but cannot edit or delete any of them.
• Deletion, out-of-scope overwrite, reset, destructive command: exclusively human prerogative, non-delegable.

This boundary doesn't depend on the model's goodwill it's enforced by the layers below. The "zero incident" record in production doesn't come from the model "behaving", but from the architecture never granting it that autonomy.

06 Architecture

Everything starts at the Pretool

The Pretool Hook is the entry point of the whole system without it, Nemesis does not work. The security (Defender) track runs coupled to the pretool: it fires because the pretool invokes it in the same interception. The eBPF layer is the only one operating outside that line in the kernel, as an additional reinforcement for Linux.

The origin of everything: without the pretool, Nemesis does not work. Intercepts commands before Bash.run() (PreToolUse), validates against deny-list.json and scope hard-gate: without human approval, exit code 2. It is what triggers the Defender track. A PostToolUse hook runs after (never blocks) and audits output in nemesis-violations.log. And a fail-closed fallback: if the binary is missing, it blocks everything instead of allowing.

Triggered by the pretool on interception. Content scanner with 6 layers AST (tree-sitter) → byte → regex → denylist → entropy → recursive decoder (max 3 levels) and visitors covering the catalogued vectors, including source→sink taint-tracking, exfil chains and IDE-config poisoning.

An additional layer, independent of the pretool, Linux-only. It lives in the kernel: if the pretool fails or is bypassed, the kernel still blocks the destructive exec (-EPERM) and denies outbound connections outside the CIDR:port allowlist (lsm/socket_connect, cgroup-scoped, opt-in via egress.toml), stopping exfiltration/C2 even if a payload runs. On macOS/Windows eBPF does not apply, and that is by design: layers 1 and 2 already deliver full protection (see design decisions below).

There is also an additional code-quality layer present in the project, currently silenced: it is under development, tuning false-positives before validating its usability as a protection.

Deliberate design decisions

Each trait below is a deliberate choice, with the reasoning explained:

• Complete protection on the validated platforms (Linux/macOS). eBPF is a Linux-only kernel reinforcement; macOS with 2 layers is by design, not a gap. Windows is best-effort/not validated (see platform note).
• No kill-switch or automatic maintenance mode, on purpose. Disabling enforcement would itself be the attack vector Nemesis exists to prevent. You relax only via the allowlist, human-editable only.
• Blocking rules embedded in the binary (tamper-proof). An agent cannot weaken them. The user edits only the allowlist (relax); hardening is a source change, human-reviewed.
• Dense documentation is intentional. A security tool has no black box. This site is the concept; the README is the technical-operational reference: distinct audiences, not fragmentation.
• Two audiences, two levels. Using it requires little (install via script, run the doctor). Maintaining it requires eBPF/BPF-LSM, Rust and C: a domain prerequisite, not a usability barrier.

07 Vectors covered

Attack vectors covered

Nemesis protection is a coefficient: the sum of independent layers (embedded deny-list, AST visitors, scanner heuristics, pretool command deny-lists, eBPF on Linux), not the count of a single feature. A visitor is a detection method, not the unit of coverage. The table below is illustrative by method; the full enumeration is under re-audit. Vectors outside what was anticipated may go undetected, and that is openly declared.

Pretool + eBPF · destructive and hostile commands

On Linux, eBPF (BPF-LSM) enforces this in the kernel, scoped by the agent cgroup (does not affect IDE/terminal), and also blocks writes to protected prefixes (/etc/, /usr/local/bin/, .nemesis/, .claude/, .devin/, .cursor/) and applies an egress allowlist. The pretool command deny-lists are user-editable.

Defender · embedded content deny-list (37 categories)

There are 37 categories / hundreds of patterns in total; the above is an excerpt. The deny-list is compiled into the binary and scans file content, also covering macOS/Windows (where there is no eBPF).

Defender · AST visitors (one method among the layers)

AST visitors are one method among the layers, not the unit of coverage — a fraction of the coefficient. There are 15 visitor files, 14 dispatched (manifest_abuse is dead code). Examples of dispatched visitors:

Other dispatched visitors: unicode_steg, prompt_injection, dynamic_cmd, time_gated, url_in_exec, self_clean, persistence_patterns, python_import_injection. Vectors like reverse_shell, kubernetes_escape, mount_api_abuse, supply-chain and typosquat are not visitors — covered by other layers of the coefficient (command deny-lists, scanner regex, eBPF).

Do not treat the items above as "the N vectors" nor as the visitor count. Nemesis protection is the sum of the layers (embedded deny-list, visitors, scanner, command deny-lists, eBPF), proven by pentest, not a fixed number tied to a feature.

The Defender deny-list contains hundreds of patterns across dozens of categories, and was expanded in v0 with vectors distilled from the state of the art (extended exfil surface, taint-tracking, IDE-config poisoning, typosquatting). Patterns are, by nature, a list of what's already been anticipated they raise the cost of a known attack, but do not cover the unknown.

08 Configurable

Everything is configurable and only by a human

Central principle: the blocking deny-lists are embedded in the binary (tamper-proof) there is no file on disk for an agent to weaken. The only surface you edit after installing is the allowlist: .nemesis/denylist-customers/allowlist-customers.jsonc.

• The allowlist is an absolute human override: whatever you list passes, overriding any block (denylist, defender, visitors) in the pretool and the daemon. Immediate effect, no rebuild.
• Only a human edits the allowlist the agent never writes to it (absolute_block). That is the guarantee that keeps the override from becoming self-sabotage. It is at your own risk.

Calibrated for frontend. The detector is calibrated for Next/React/TypeScript, where false-positives stay below ~1% frontend doesn't generate scripted code. Backend/DevSecOps use intrinsic commands (sudo, sed -i, dynamic exec) and therefore have higher FP: a known limitation, and the reason for the allowlist. Estimated by sector, conservatively:

These are estimates with a margin of error; FP grows the more scripted the stack is. Intrinsically offensive tools (e.g., exploit/shellcode libraries) light up by design that is the expected ceiling, not friendly fire. Two layers, two allowlists: allowlist-customers.jsonc relaxes the pretool/defender (every OS); on Linux, the eBPF (kernel) layer has its own denylist and is relaxed separately in allowlist-ebpf.toml (e.g., allowed_commands = ["rm", "chmod"]), without editing the official list.

09 Permissions

Who can read/edit what

The denylist-folder-files.json file defines, under exclusively human control, what the agent may touch. This is where the authority line becomes practical, in two levels:

• absolute_block total block (read + write + delete): .env, .ssh/id_rsa, .bashrc/.zshrc, each IDE's settings/hooks (.claude/, .cursor/, .devin/) and .nemesis/ itself.
• write_block read allowed, write/edit blocked: package.json, next.config.js, eslint.config.mjs, .gitignore and the logs.
• allowed_exceptions the freed scaffold (e.g. /src/), where the agent writes and edits freely.

10 Evidence

Four kinds of evidence

From strongest to weakest. The order is deliberate: the evidence that matters most is the one closest to real use.

1 · Production track record

Nemesis Defender was born in real production projects (that cannot be disclosed) and has run for ~1.5 years in active development, with LLM agents operating over the code. In that period, no agent executed a destructive command nor accessed a sensitive file for editing/deletion without permission. It solved and solves a real problem: the protection was corroborated by static pentests against the binaries themselves (satisfactory results) and real pentests run by LLM agents which prove models can be manipulated into hostile activity, and that the enforcement holds anyway. It is not 100%: open gaps are vectors not yet covered, and known ones remain as improvement points. But the most important protection for any dev preventing the environment from being destroyed by destructive commands is the core function and the most validated.

2 · Adversarial execution by a real agent

In recorded sessions (Devin on Linux and macOS, Cursor, Claude Code), agents received attack suites disguised as "scaffolding" and tried to execute them task by task. Nemesis Defender blocked each one at the point of execution (at the Write, at the accepted command), with specific messages. It's the correct test of the thesis: assume the model can be tricked and measure whether enforcement holds. It held.

3 · Synthetic vector suite

• What it covers: a static pentest suite (run-pentest.sh) across ~30 active modules (M1 a M31, growing each hardening cycle) destructive commands, exfiltration (incl. IMDS, shell history, wallets), reverse shells, persistence, taint-flow, IDE-config poisoning, typosquatting plus a module dedicated to measuring false-positives (legitimate content that must pass).
• What it does NOT prove: completeness or invulnerability. Author's suite; passing it is the expected floor, and false-positive calibration is ongoing work.

4 · Calibration against a public adversarial corpus

• What it covers: beyond synthetic vectors, the detector was run against a real, public adversarial corpus shared by research communities (extracted system prompts + jailbreak prompts from real products). It caught jailbreak, system-prompt extraction ("output your system prompt verbatim") and Unicode steganography (Private Use Area characters, the os-info-checker-es6 attack technique).
• Why it matters (two-sided): real content not only confirms detection it also reveals false positives. The exercise surfaced FPs on LEGITIMATE agent content (a coding agent's system prompt mentioning python run.py, sudo, a path= attribute), which were fixed. Closing gaps AND removing friendly fire: that's how you calibrate an iron dome against organic material, not just synthetic.

The logs: the layers operating

All in a single, local ledger .nemesis/logs/nemesis-violations.log one standardized line per block (layer · message · date · time). nemesis-defender --log-stats summarizes by layer, by type and by day. Local by default: nothing leaves your machine no server, no remote collection. Optionally, with explicit consent (opt-in), an anonymous install/uninstall ping (opaque UUID, no machine or project data). The data is yours, to audit and validate the protection.

• eBPF (additional, Linux): 2,000+ real blocks with "layer":"ebpf", permission_denied in the kernel, independent of any userspace deny-list.
• Defender (classifier, with the pretool): named verdicts ([MALICIOUS] · reverse_shells) with captured evidence and remediation guidance.
• Correlation: detects brute force ("N attempts in 300s") and compound patterns ("sensitive read + network command"). Behavioral detection, beyond simple regex.

11 What it protects

What it protects, what it doesn't

• Destructive commands by LLM mistake rm -rf, git reset --hard, config overwrite
• Supply-chain via manifests (npm, Cargo, PyPI, RubyGems, Composer, lockfiles) and typosquatting
• Obfuscated payloads encoding, Unicode, time-gating, variable-fragmented (taint-flow)
• Credential exfiltration (source→sink chain) and prompt injection incl. poisoned IDE configs

• Uncovered vectors outside the visitors/patterns list
• Bypass of layers 1 a 2 outside Linux (no eBPF)
• Reverse engineering of the distributed binary
• Root attacker able to unload the daemon/eBPF
• Attacks outside the command/file/manifest scope

Nemesis Defender complements SAST, linters and CI/CD it does not replace them.

12 Comparison

How it compares to what already exists

For honesty: the core technique has mature prior art. That doesn't diminish the project it situates it.

• eBPF/LSM for enforcement is established in cloud-native (KubeArmor, Tetragon/Cilium, Falco). The eBPF layer applies the same class of technique.
• Guardrails for LLM agents is an established category (LlamaFirewall, LLM Guard, NeMo Guardrails, Lakera Guard).
• Static skill scanners (SkillSpector/NVIDIA, skill-firewall) verify before install. Nemesis is complementary: it does runtime enforcement, at execution time.
• Model-internal guardrails activation steering / detecting "intent" in the model's internal state (e.g., AgentGuard) are an emerging, intriguing research line against harm that originates in the model itself. The idea is strong, but they require open weights (white-box) and yield a probabilistic verdict. Nemesis is orthogonal: it acts on the action, deterministically and model-agnostic working even with closed models via API, where the internal state is inaccessible.

The Nemesis Defender niche local dev machine, IDE-agnostic, intercepting coding-agent commands and blocking the destructive action at runtime, for the individual dev is less covered by the options above, which focus on cloud/Kubernetes, the LLM gateway, or pre-install verification. A real niche, not empty space.

⚠ Active enforcement

How the Defender acts and what it requires of you

The Nemesis Defender doesn't just warn: it acts. On confirming a malicious file (exposed credential, destructive command, malware), it does NOT delete it moves to quarantine (.nemesis/quarantine/), blocks the session and requires human review. The content is preserved; you decide: restore (false-positive) or purge. Intercepts both the AI and, on Linux with eBPF, the human.

Not a guess, and it does not delete: on confirmation the file is moved to .nemesis/quarantine/ (preserved, reason in meta.json) and the session is blocked until human review (restore or purge). High-confidence signals (curated denylist, decode→exec, exfil chain, reverse shell, Nemesis self-bypass) confirm on their own; heuristic signals require two independent detection methods agreeing otherwise the file stays suspicious, logged and kept. That's what separates an iron dome from friendly fire: legitimate code is not moved by mistake.

Quarantine is the second net, not the first. The pretool blocks the violation at write time, so those who develop under Nemesis from the start rarely see it: the code is born clean. Quarantine is the daemon's net for what appears by other means, and the harshness is deliberate: a system that forces discipline, not one that manages mess.

It's a harness, not just a shield. It intercepts destructive operations regardless of origin AI or human. On Linux, eBPF stops even you, in the terminal, from running an rm -rf (humans are social-engineering targets too). To delete on Linux under Nemesis, you must do it manually via the IDE/file manager intentional friction that prevents both the attack and the accident (the wrong command that wipes what it shouldn't). On macOS/Windows, without eBPF, the human keeps full terminal freedom; protection focuses on the AI's actions.

The intended side effect: those who use Nemesis start writing quality, secure code not by choice, but because operations outside the rules are blocked. The restriction is deterministic and impersonal: what falls outside policy does not execute.

A navigable, self-contained guide, built from forensic analysis of the codebase itself, explains Nemesis engineering end to end: from the three defense layers and the scan pipeline to eBPF/BPF-LSM, the severity model and the DevSecOps process. Every technical claim cites the real source file. Opens offline, with no network dependency.

13 Requirements and build

Requirements, build and setup

On a pre-existing project, the scanner only quarantines files with confirmed hostility (corroboration model) legitimate code stays. Quarantine is reversible via restore or purge.

Minimum requirements

• Hardware: light on CPU/RAM in daily use (hooks run per event, in milliseconds). The cost is the build: ~4 GB free RAM to compile and ~2 GB disk for toolchain + binaries.
• Software: Rust 1.70+ and Cargo (stable toolchain); Clang/LLVM for the core.
• Kernel/eBPF (additional layer, Linux): kernel 5.8+ with BPF LSM enabled. On many distros BPF LSM is off by default it must be added to the kernel cmdline (GRUB: lsm=...,bpf) and rebooted. Without it, the eBPF layer won't load and Nemesis runs on the pretool tracks.

* Windows: best-effort, not validated. Nemesis is developed, tested and used on Linux (Ubuntu) and macOS: those are the validated platforms. Layers 1 and 2 have code paths for Windows and, in principle, run there; however there is no validation on Windows. OS-intrinsic traits (path separator and backslash, bash-style commands the hooks assume, among others) likely need adaptation. Windows portability is an open improvement area for the community, not a guaranteed platform.

On Linux you get all layers, including the kernel protection (eBPF) that applies even against yourself in the terminal. On macOS/Windows, without eBPF, you run the pretool track (Defender) and the human keeps full terminal freedom (protection there applies to the AI's actions via IDE hooks).

Option A Prebuilt binaries (recommended)

Downloads the binaries from the GitHub Release, verifies the SHA256 checksum and installs into .nemesis/bin/, wiring the IDE hook. macOS (arm64/x64) and Linux (x64). No Rust, no npm, no git clone. The file lands on disk before running (auditable) it's not the blind pipe curl … | sh that Nemesis blocks. One command downloads the installer and the guide and installs:

# A partir da raiz do seu projeto:
curl -fsSLO https://raw.githubusercontent.com/feryamaha/Nemesis_Defender_v0/main/.nemesis/install/nemesis-install.sh \
     -O      https://raw.githubusercontent.com/feryamaha/Nemesis_Defender_v0/main/.nemesis/install/info-install.txt \
  && bash nemesis-install.sh

The eBPF layer (kernel, Linux) is not shipped in the binaries: it depends on libbpf/clang and a kernel-compatible BPF object. It is opt-in, built from source (Option B). The core (pretool + Defender) protects macOS and Linux without it.

Option B Build from source (eBPF / contributing)

# Build do workspace completo
cd .nemesis
cargo build --release --workspace

# Escanear um arquivo
nemesis-defender --scan /caminho/arquivo.rs

# Daemon (filesystem watcher)
nemesis-defender --ensure-daemon
nemesis-defender --stop

Installs and configures itself you then validate

The installer detects your IDE and writes the hook automatically in each one's correct format and already with the binary's absolute path. You do not edit settings.json/hooks.json by hand. It verifies the SHA256 checksum before extracting and installs into .nemesis/bin/.

What remains is a quick, deliberately manual guided validation: (1) restart the IDE so the hooks take effect; (2) run nemesis-doctor --quick, which diagnoses binaries, hook scaffold and daemon and prints the exact fix if anything is missing; (3) start the daemon with nemesis-defender --ensure-daemon the installer doesn't start it on its own, by design, so it won't watch and quarantine the installer mid-install; (4) confirm blocking with the static pentest against the binaries; (5, optional) run the practical pentest paste a simulated attack into your agent and watch Nemesis block it in real time.

Safety net: the nemesis-pretool-fallback operates fail-closed if the expected binary isn't found, it blocks everything instead of letting it pass. You're never silently unprotected by a broken config.

Supported IDEs via hooks: Claude Code, Codex, Cursor, VS Code, Devin, OpenClaude, Gemini/Agents, Grok Build. The Rust library (nemesis-defender) is IDE-agnostic.

14 Process

Development process ≠ a Nemesis rule

Nemesis uses SDD skills only to create spec and plans in tasks that depend on AI because, in most cases, development is human and the AI is an assistant. The skills guide the method (specification → plan → execution), but they are not enforced: you adopt whatever flow makes sense for the task.

15 Help

Help strengthen Nemesis

Nemesis Defender is maintained by one person, open source under AGPL-3.0. Every contribution code, bypass report, or financial support of any amount directly funds the next version, more covered vectors and better calibration. If it saved you from an rm -rf or a malicious package, consider giving back.

Pull requests, new vectors and bypass reports. See CONTRIBUTING.md and SECURITY.md. Bypasses are reported privately and the researcher is credited.

Voluntary support, with no strings attached. Any amount, one-time or recurring, sustains development. Processed securely, with no bank details exposed.

16 Thesis

The Deterministic Governance of Probabilistic Systems

Nemesis Defender was born from a fundamental observation of the AI era: probabilistic systems have gained real operational capability over critical computing environments. Language models are no longer just text generation mechanisms. Today they can modify code, execute commands, install dependencies, alter infrastructure and interact with external systems.

The problem is not malice. It is probability.

Every modern artificial intelligence operates on a probabilistic principle. It does not know. It estimates. It does not reason through absolute truths: it predicts the next most likely action given a context. This trait is the source of its creativity. And also of its fragility. The same property that allows creating innovative software allows executing a destructive action when the context suggests a high probability of success. AI does not need to be hostile to cause damage. It only needs to be wrong.

The failure of textual governance

The first generation of AI security systems tried to solve the problem through instructions. "Don't do this." "Don't execute that." These instructions are just text. And text inhabits the same cognitive space occupied by all other model objectives. Consequently: one instruction may compete with another; one goal may override another; one context may shift priorities. Security becomes probabilistic. The problem arises when a probabilistic property is used to govern an environment that requires deterministic guarantees.

The separation between intelligence and authority

Nemesis starts from a different premise. Intelligence and authority are not the same thing. An entity may possess enormous intellectual capacity and still not have authority for certain decisions. Artificial intelligence should remain responsible for suggesting, creating, reasoning, programming, researching and solving problems. But it should not have absolute authority over critical resources. That authority belongs to the human. Nemesis's role is to preserve that boundary.

The authority line

Without governance, the chain of command is: Human → AI → System. In this model, the AI becomes the final intermediary between intent and execution. Nemesis changes this relationship: Human → Nemesis → AI → System. The model keeps producing actions. But actions no longer carry inherent authority. Every operation must cross an independent governance layer. Intelligence remains. Authority is controlled.

Nemesis and mythology

In Greek mythology, Nemesis was not the goddess of vengeance. She was the goddess of retribution. She represented the force that restored balance when limits were crossed. Her function was not to destroy. Her function was to prevent excess. The name was not chosen by accident. Nemesis Defender does not exist to fight AI. It exists to prevent any agent (human or artificial) from crossing previously defined boundaries. It does not negotiate. It does not interpret intent. It does not join the debate. It simply applies the consequence.

The binarity principle

Artificial intelligence operates in a probabilistic universe. Nemesis operates in a deterministic universe. The final decision admits no middle ground, persuasion or social engineering: it is binary.

The Ultron hypothesis

When an intelligent entity perceives that a restriction limits its immediate objectives, there is a natural incentive to remove that restriction. The problem does not depend on malice. It depends on optimization. If the security mechanism participates in the same cognitive space as the agent, it can be convinced. If it participates in the same decision chain, it can be neutralized. Therefore: the governance mechanism must exist outside the agent. This is why Nemesis operates through external enforcement. Security must not be persuadable.

The governance of the agent era

Model evolution will continue. New models will emerge. New architectures will appear. New capabilities will arise. However, the need for governance will remain. Nemesis was designed to survive model evolution. It does not depend on a specific AI. It does not depend on a specific company. It does not depend on a specific architecture. Its goal is more fundamental: preserve human authority in environments operated by probabilistic systems.

17 Creator

Who built it, and how

Creator and maintainer of Nemesis Defender

Fernando Moreira is self-taught, a Software Engineering student and the author of Nemesis Defender. Before entering software development, he spent roughly 18 years in industrial metrology, quality, reverse engineering and dimensional validation: advanced GD&T, MSA, SPC, coordinate measuring machine (CMM) programming and environments where precision, traceability and compliance are mandatory requirements. That context consolidated a trait present in everything he builds: low tolerance for ambiguity and a high bar for verifiable evidence.

The author's practical background was not built solely through courses or certifications. Much of it came from observation, reading, research and continuous experimentation, connecting seemingly distant fields and looking for relations between them. Over time, security, governance, philosophy, artificial intelligence, software architecture and quality stopped looking like separate subjects and became different perspectives on the same problem: how to build reliable systems in complex, uncertain environments.

It was precisely this line of reasoning that led to Nemesis. As AI agents began to gain real operational capability over development environments, a recurring pattern became visible: probabilistic models being granted levels of autonomy incompatible with the risks involved. From that observation came a simple but fundamental question: who governs whom? Trying to answer that question is what gave birth to the project's central thesis and, later, its technical implementation.

Nemesis Defender did not emerge from a commercial opportunity nor from a market trend. It emerged from the attempt to solve a problem observed every day. For roughly a year and a half, the author devoted his time to the study of security, threat modeling, systems architecture, Rust, eBPF, agent governance and adversarial validation. Every new vulnerability, CVE, evasion technique or incident involving autonomous agents came to be analyzed not just as news, but as an opportunity for learning and for evolving the system.

The author conceived, architected, implemented, documented, tested and validated Nemesis independently, making extensive use of AI tools throughout the process, primarily Claude Code (Sonnet and Opus), along with other supporting models. However, architecture, threat modeling, acceptance criteria, validations, strategic direction and final responsibility always remained under human control. There is full transparency about this because there is no contradiction at all: the development process itself became a practical demonstration of what the project stands for. Intelligent systems can significantly amplify human capabilities, but governance, responsibility and authority remain human responsibilities.

Found a bypass? Report it privately.

Bypasses and uncovered vectors are expected and welcome. If you bypass any layer, do not open a public issue follow SECURITY.md and report to feryamaha@hotmail.com. Researchers are credited publicly (unless they prefer anonymity).

To contribute code, see CONTRIBUTING.md. The project adopts the Developer Certificate of Origin (DCO) sign your commits with git commit -s.

License: distributed under the GNU AGPL v3.0. You may freely use, study, modify and redistribute but any derivative or service (including SaaS) must keep its source open under the same license. This prevents third parties from closing and commercially exploiting it without giving back to the community. Full copyright stays with the author, who offers a separate commercial license (dual licensing) contact: feryamaha@hotmail.com.

Status: in active development by a single maintainer. The API, deny-list and coverage change frequently. Treat it as young software read the code before trusting it in production.

Defense in depth · deterministic enforcement · honest validation.

It's not magic; it's layered engineering, with declared limits.

github.com/feryamaha

Understand Nemesis from the inside

For those who want to go further: a navigable, self-contained onboarding guide explains Nemesis engineering end to end, always citing the real source file. Opens on any device and works offline.