NESHER is a classification library — it assesses risk, it does not enforce it at the OS or network level. A determined caller can always ignore a BLOCKED result and execute anyway. NESHER's security model assumes:

1. The agent runtime calling NESHER is trusted
2. The human or system that configured NESHER is trusted
3. NESHER's job is to make irreversible actions visible and escapable, not to be an impenetrable wall

If your threat model requires hard enforcement that cannot be bypassed in userland, NESHER is a signal layer in a broader defense-in-depth stack, not a standalone solution.

• Network enforcement — NESHER does not intercept HTTP requests or block syscalls
• Sandboxing — NESHER does not run agent code in an isolated environment
• Authentication — NESHER does not verify who is calling it
• Replay protection — NESHER does not track whether an action was previously approved

Because match() functions are pure pattern matchers against an ActionInput object, a caller can theoretically craft an action description that evades classification (e.g., renaming delete to remove_permanently).

Mitigations:

• The heuristic fallback catches write-like action names not in any pattern
• Custom patterns let you add org-specific vocabulary
• High-security deployments should treat NESHER as one layer and add runtime enforcement at the execution layer

To report a security vulnerability, email security@reshimu.ai.

Please include:

• Description of the vulnerability
• Steps to reproduce
• Impact assessment
• Suggested fix if available

We will respond within 48 hours.

NESHER has zero runtime dependencies. There are no supply-chain vectors in production usage. Dev dependencies (TypeScript, Vitest, tsup) are scoped to devDependencies and are not included in the published package.