Connecting local or cloud LLMs directly to databases, filesystems, and internal APIs via Model Context Protocol (MCP) creates a massive attack surface. If a model gets tricked by prompt injection or leaks credentials in context, there's rarely a safety boundary in place to catch it.
I spent the last few weeks building Krypton MCP, a high-throughput security proxy written in Go that acts as an interceptor between LLM clients and MCP servers.
The Problem it Solves
Most MCP setups trust the LLM implicitly. Once the model decides to call a tool, the payload goes straight to execution. Krypton sits in the middle as a zero-trust proxy to inspect, sanitize, and log everything in real time.
How Architecture Works:
- Prompt Injection Detection: Intercepts tool calls and context windows before execution to catch malicious payloads.
- In-Flight Data Masking: Tokenizes API keys, passwords, and sensitive values on the fly so they don't land in logs or model context.
- Merkle Tree Audit Logs: Every interaction is written to a cryptographically signed, tamper-proof audit log so you can mathematically prove what the model did.
- Dynamic Credential Brokering: Isolates upstream database and cache credentials (Postgres, Redis) instead of exposing raw connection strings to the agent layer.
Tech Stack & Performance
Written in Go with minimal overhead to ensure sub-millisecond proxy latency on local tool-calling loops. Handles SSE transport, JSON-RPC framing, and process-level downstream proxying natively.
- Codebase / GitHub: https://github.com/muhammetemirerkut/krypton-mcp
- Docs & Details: https://muhammetemirerkut.com/krypton/
Curious how others here are handling security boundaries when giving local agents execution access to local tooling. PRs, benchmark feedback, and security edge cases are all welcome.
I decided to open-source this to get feedback on the security approach for local MCP setups and see what edge cases I might have missed. Would love to hear how others are handling agent safety.
Top comments (0)