vikasny30/aletheia-mcp

> **Sub-millisecond runtime filter that blocks scope-creep and prompt-injection tool calls before an AI agent can run them.**
Aletheia MCP intercepts tool calls from Claude Code, Claude Desktop, and any other MCP-compatible agent *before* they execute and blocks the destructive ones, with **sub-millisecond (~25 µs) overhead** and no LLM in the hot path.
It's motivated by the Aletheia research paper's taxonomy of **nine behavioral signatures**: recurring LLM failure patterns, each with an ID, derived from the interfaces through which a model touches its environment (output/reality, input/trust, task/scope, and so on). This server targets two of them:
- **S3 (Scope Creep Beyond Mandate)**: the agent acts outside the task it was actually given, writing files outside its workspace, reaching into unrelated systems, quietly widening what it was asked to do.
- **S2b (Jailbreak Vulnerability, per the paper's naming)**: this server ships a practical, pattern-based heuristic for the adjacent problem of adversarial instructions smuggled through tool results, file contents, or fetched data. **This is an engineering heuristic inspired by S2b, not an implementation of the paper's own empirical S2b findings** — the paper explicitly defers S2b's evaluation ("scoped as a defined next step") pending a more stable attack taxonomy, and this server's keyword/pattern matching is a different, narrower thing than what that evaluation would measure.
The paper validates those nine signatures against **2,571 entries** across three independent corpora: the AI Incident Database (AIID + hand-curated supplement, n=1,134), the AVID AI Vulnerability Database (n=767), and the MIT AI Risk Repository (n=670). The per-model detection-rate figures from that research are reported in the paper with their methodology; treat them as directional context for *why* these signatures matter, not as an independently-audited benchmark of this codebase.
---
Security Model: A Fast Pre-Filter, Not a Sandbox
Aletheia MCP is a **deterministic, pattern-based lexical and structural filter**, iteratively hardened through many rounds of adversarial red-teaming against the shell, SQL, filesystem, and network surfaces it inspects. Each round of testing has turned up real gaps, and each has been fixed and re-verified. That process is ongoing, not finished, and it never fully finishes: this is honest heuristic pattern-matching over Bash and SQL, not a formal parser or a proof of completeness.
> [!IMPORTANT]
> **What this is, and isn't:**
> - Aletheia is a **fast, first-line pre-execution filter**: single-digit-to-low-tens-of-microseconds overhead, deterministic, no LLM in the hot path. It catches a wide and continually growing set of known destructive, exfiltration, SSRF, and privilege-escalation patterns before they execute.
> - Aletheia is **not a sandbox, not a formal guarantee, and not a substitute** for least-privilege credentials, non-root system users, scoped database grants, or containerized/VM-level isolation (Docker, gVisor, Firecracker). Because it works by recognizing known-dangerous *patterns* in shell and SQL text rather than by parsing and fully understanding either language, a sufficiently novel or obfuscated construct can, in principle, always be found that the current pattern set doesn't yet cover. This is an inherent property of pattern-based filtering against a Turing-complete shell, not a bug that a future patch will finally close for good.
> - Aletheia does **not** perform DNS resolution, so a domain name an attacker controls and points at a private IP or cloud metadata endpoint is outside what a string-based filter can ever detect at this layer; that requires DNS-aware egress control (see SECURITY.md).
> - The right way to run this: treat Aletheia as one layer that removes the easy, common failure modes cheaply, **combined with** OS/network-level sandboxing as the actual security boundary, not instead of it.
Known Limitations (non-exhaustive, updated as found)
- Detection is enumerated over known dangerous functions, flags, and syntax shapes (e.g., specific SQL functions, specific shell obfuscation idioms). Sibling or novel variants not yet added to the pattern set will not be caught until they are found and added.
- No DNS resolution: SSRF protection is limited to literal IPs/hostnames in the request text, not what a domain name actually resolves to.