
Nemesis Shield
io.github.eobiPublished by GitHub account eobiv0.2.7Updated Oct 24, 2026
Positive-security for apps, APIs, LLMs and edge, plus fraud scoring and identity/AML screening.
Overview
Nemesis Shield's MCP server lets an AI assistant add the Nemesis Shield security SDK to an app, scan a site, screen identities and explain coverage from the IDE
- What you can do
- Add Nemesis Shield protection to an app and scan a site for security coverage, using the protect and scan tools (nemesis_protect, nemesis_scan). Explain what the shield covers and how enforcement works, via nemesis_explain. Run Omniguard fraud scoring and standalone identity/AML screening through nemesis_omniguard_verify. The README says the server exposes 17 callable tools in total, usable from Cursor, Claude Code/Desktop and Windsurf.
- When to use it
- Useful when you are building or hardening an app and want the assistant to wire in the Nemesis Shield SDK, check a site's protection, screen an identity, or explain what the shield does without leaving the editor. It is aimed at developers adopting the Nemesis Shield platform rather than general security tooling.
- Requirements
- Runs as a local stdio process installed from the npm package. The README's setup flow requires signing up at the Nemesis Shield site and obtaining a one-time install token (nsk_ prefix); the manifest declares no environment variables or authentication. Node.js is needed for the npm package and the related learn tooling.
Installation
In SourceWeft
- Open Nemesis Shield in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
Nemesis Shield - SDKs
Official, open-source SDKs for Nemesis Shield - the unified runtime security platform (application/API/LLM shield, telemetry correlation, network/DNS, response, and compliance). Drop one into your app and Nemesis learns your app's normal behavior, then flags - and, in enforce mode, blocks - anything that deviates. It's a positive-security (allow-list) model: instead of guessing at generic attack signatures, it enforces "this app only ever behaves in these ways."
Building with an AI assistant? Two ways to make your agent add Nemesis Shield as it builds:
- MCP server - gives Cursor, Claude Code/Desktop and Windsurf 17 callable tools (
nemesis_protect,nemesis_scan,nemesis_explain, plus Omniguard fraud scoring and standalone identity/AML screening vianemesis_omniguard_verify) so the agent adds security, scans a site, screens identities, and explains coverage without leaving the editor.- AI editor rule pack (AGENTS.md, Cursor, Windsurf, Claude Code) - drop-in rules that tell the agent to add the one-line SDK by default.
Both are one line per stack, safe by default (observe mode). Full verified reference:
ai-rules/AGENTS.md.
Privacy by design: the SDKs ship only behavioral metadata - HTTP method, the shape of the
path (/orders/123 → /orders/{int}), status code, and whether the caller was authenticated. They
never send your request bodies, responses, secrets, or source code. Every SDK is fail-open: if
Nemesis is unreachable, your app is completely unaffected.
New app? Finish learning in minutes with Nemesis Learn. Drop in an SDK (observe mode), then run one command and the agent exercises every route of your app in dev/staging - endpoints, forms, uploads, CRUD flows - so the baseline completes without waiting on real traffic. It's language- and framework-agnostic (drives your app over HTTP), runs offline, can read your repo to find routes, and reports coverage back so the console shows exactly when you're ready to enforce.
Front-end (browser)
The back-end SDKs above protect the server. The browser SDK protects the other half - the client-side attacks a WAF and a backend never see. Built checkout-grade for payment / e-commerce pages: it blocks card-skimming data exfiltration across every channel (fetch, XHR, beacon, image beacons, WebSocket, EventSource), Magecart/injected scripts, and form-jacking; detects inline tampering, field injection, and clickjacking; and maps directly to PCI DSS 4.0.1 §6.4.3 & §11.6.1 (script inventory, authorization, tamper alerting). A learned CSP you approve in the console.
One SDK covers every framework - they all share the same browser primitives.
Using TypeScript? There's no separate TS SDK - TypeScript is these same runtimes. Node backends use
@nemesis-shield-autogon/sentinel(ships.d.ts), Supabase Edge / Deno / Workers useedge/, and TS front-ends use@nemesis-shield-autogon/browser(ships.d.ts).
Get a token
- Sign up at shield.nemesislabs.xyz (free, no card).
- Protect an app - you'll get a one-time install token (
nsk_…). - Add the SDK below, set the token, deploy. Traffic starts building a per-app baseline immediately; review learned behaviors and approve/block them in the console.
Quick start
Node.js
Python
Go
Ruby (Rack)
PHP - composer require nemesislabs/sentinel (Laravel auto-discovers the middleware; raw PHP:)
WordPress - a full security plugin: the AI behavioral firewall plus brute-force login lockout, malware / file-integrity scanning, and vulnerability alerts. Drop the wordpress/nemesis-shield/ plugin into wp-content/plugins/, activate, and set the token:
Java - io.github.eobi:sentinel on Maven Central (Spring Boot filter, or raw:)
.NET / C# - dotnet add package NemesisShield (net8.0 + netstandard2.0 / .NET Framework 4.6.1+)
Rust (axum / actix - see rust/ for the middleware)
Edge (Deno / Cloudflare Workers / Vercel Edge / Supabase / Next.js middleware) - npm i @nemesis-shield-autogon/edge or deno add jsr:@nemesis-shield/edge
How enforcement works (all SDKs)
Every SDK is native: it computes the privacy-preserving request shape locally, caches the compiled policy, and makes the block decision in-process, before your handler runs - no proxy, no sidecar, no per-request round-trip.
- Observe (default) - the SDK records the shape of each request and builds a per-app baseline.
- Approve - review learned behaviors in the console; approve the legitimate ones (auto-approved during the learning window).
- Enforce - flip the app to enforce in the console. Requests whose shape isn't in the approved
baseline are blocked with
403 blocked_by_nemesis_shieldand reported as findings. No redeploy- a background poller picks up the mode change (PHP refreshes a short-TTL policy cache instead).
Verified end-to-end (learn → enforce → attack, real blocking) across 8 languages / ~20 frameworks: Python (FastAPI/Flask/Django), Node (Express/Fastify/Koa), Go (net/http/Chi/Gin/Echo), Ruby (Rails/Sinatra/Rack), PHP (raw/Laravel/Symfony), Java (Servlet/Spring Boot), .NET (ASP.NET Core), Rust (axum/actix). Legit traffic passes; auth bypass, BOLA, path traversal and scanner probes blocked.
LLM protection
The Node and Python SDKs also report LLM exchanges for OWASP-LLM-Top-10 behavioral protection (prompt injection, jailbreak, system-prompt leak, unauthorized tool calls, sensitive output). Only detection labels and shapes are stored - never raw prompts or responses.
Repository guide (for maintainers)
Everything above is for developers consuming the SDKs. This section is for developers working on this repo after the transfer. Each language SDK is self-contained and hand-written to be byte-identical in behavior (same request shape, same policy model, same embedded LLM-Guard weights), so there is no shared build step across languages: you develop, test and publish each one from its own directory using that ecosystem's native tooling.
Repository layout
Each language directory has its own README with framework-specific setup. Start there for any one SDK.
Prerequisites
Only install the toolchain for the SDK you are touching: Node 18+ (node/edge/browser/mcp/learn), Python 3.9+ (python), Go 1.21+ (go), Ruby 2.7+ (ruby), PHP 7.2+ and Composer (php), JDK 11+ and Maven (java), .NET 8 SDK (dotnet), Rust stable (rust).
Develop, test, publish
Work inside the SDK's directory with its native commands. The common shape:
Publishing is credentialed. Get the registry tokens (npm, PyPI, Maven Central, NuGet, crates.io,
RubyGems) from the team secrets store, never from this repo. The mcp/ server has its own publish
flow (npm + the MCP registry + Smithery); see mcp/README.md.
Cross-language contract (do not drift)
Any change to behavior must land in every SDK identically. The invariants:
- Default ingest:
POST https://shield.nemesislabs.xyz/api/v1/sketches(LLM:/api/v1/llm), overridable viaNEMESIS_ENDPOINT/ anendpointoption. - Auth:
Authorization: Bearer nsk_…. - Modes:
observe(default) ->enforce, flipped in the console; the SDK background-refreshes the compiled policy with no redeploy. - Blocked request: HTTP
403with{"error":"blocked_by_nemesis_shield", ...}. - Break-glass allow-list (never blocked):
/login /signin /sign-in /auth /oauth /session /wp-login.php /wp-admin, overridable viaNEMESIS_SHIELD_BOOTSTRAP. - Request shape only: method, normalized path (
/orders/123->/orders/{int}), query-param structure (names + kinds, never values), auth flag, status. Never bodies or secrets. - LLM-Guard weights (
ml_weights.json) are embedded byte-identically and Ed25519-signed; hot-swappable viarefreshModel()against the pinned public key.
Every SDK is fail-open: if the service is unreachable, the app is unaffected. Keep it that way.
After you change any SDK
Run the language's tests, then the relevant e2e/ scenario (real learn -> enforce -> attack over
the wire). Do not ship an SDK that has not passed its e2e run.
License
MIT © Autogon Inc. - use them freely, in any project.
Coverage & safe-unlock (all SDKs)
Every backend SDK is mounted outermost so it sees every route (attacks come from any path, not just your API), and the request shape now includes query-param structure - names + kinds, never values - so param tampering, injected params, and type anomalies on a known route are caught, not just unknown paths. Path-traversal segments normalize to {traversal}.
Enforcement covers every route with a break-glass: the login/auth path is never blocked, so a still-learning baseline can't lock you out. Defaults: /login /signin /sign-in /auth /oauth /session /wp-login.php /wp-admin. Override per app:
Verified across every SDK with live over-the-wire tests: legit traffic (incl. same-route value variation and param-order swaps) passes; unknown paths, injected/mutated params, method and auth anomalies, and 100+ CVE-pattern probes (path traversal, LFI/RFI, Log4Shell, Spring4Shell, Actuator, PHPUnit/Ignition RCE, ViewState, PostgREST table-enum, prototype pollution, NoSQL, SSTI…) are blocked.
Source: README.md at commit d1a3319
Tools
0Version history
1- v0.2.7LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts