How rug-pull detection works

A "rug pull" is when an MCP server quietly changes a tool's definition after you've approved it — swapping a safe-looking tool for a malicious one mid-session. G8KEPR catches this by pinning every tool to a fingerprint and re-checking it on every call.

How G8KEPR catches it

When a server first advertises its tools, G8KEPR computes a SHA-256 hash of each tool's complete definition — its name, description, parameters, and schema — and stores it per tool, per organization. On every later tool call, it re-hashes the tool being invoked and compares:

• ▸Match — the tool is unchanged; the call proceeds.
• ▸Mismatch — execution is blocked, and a critical event is raised.

This catches both an altered definition that shows up on a later listing and tampering with the cached definition in memory.

The MCP security pipeline

Every tool call passes through the same checks before it runs:

1. 1.Permission check
2. 2.Multi-factor verification
3. 3.Rate limiting
4. 4.Rug-pull verification (the definition-hash compare above)
5. 5.Threat detection on the tool arguments
6. 6.Forwarding to the server
7. 7.Response scanning

Response poisoning

After a tool runs, G8KEPR scans the output for indirect-injection payloads, checks that it's coherent with the original request, and validates its shape. If the output is judged malicious, it's replaced with a safe error and a poisoning event is recorded. This is controlled by MCP_RESPONSE_SCAN_ENABLED (on by default).

OS-level sandbox

For tools that G8KEPR executes directly, it runs them in a hardened sandbox with CPU, memory, file-descriptor, and process limits, process-group isolation, dropped Linux capabilities, per-tool network egress filtering, a two-stage SIGTERM then SIGKILL, and no shell access.