The idea: We now have a ton of official MCP servers for tools like Notion, Linear, Sentry, etc.—but it’s still a nightmare to use these securely. They’re susceptible to prompt injections, indirect prompt injections, confused deputy attacks, and more.
It’s a tricky problem—some MCPs, like the official Sentry MCP, are well-designed with constrained inputs and minimal mutating tools. Others, like the official Linear MCP, have looser input constraints and a wide range of mutating tools. So now, a user has to think about securing just Sentry, just Linear, and the combined attack surface of Linear + Sentry workflows. And then all that effort goes out the window when you add a new MCP—like GitHub—which massively increases the attack surface again.
To solve this, we built a lightweight proxy that runs locally at the MCP layer. It powers expressive guardrails that decide whether MCP tool calls should be allowed or blocked.
We used Python metaprogramming to define our DSL, which allows you to express guardrails as a one-to-many mapping from policy to rules. These rules support fine-grained scanning of malicious inputs/outputs, tool call sequences, and behavioral patterns.
This is where the Tramlines DSL shines. Since it’s based on Python metaprogramming, you can write rules for just Linear, just Sentry, and then compose those into higher-order rules for combined workflows like Linear + Sentry. This prevents the usual guardrail explosion problem as you scale coverage.
The DSL’s expressiveness also helps tailor how aggressive your policies are. For low-stakes workflows, drop in one of our built-in detectors—like hidden Unicode detection, prompt injection patterns, or basic PII detection. For high-stakes workflows, define custom rules that scan for contiguous or non-contiguous tool sequences, monitor latency between tool calls, or use heuristics from external sources to enrich logic.
Case in point: One of the first MCP servers we evaluated was the official stdio Heroku MCP—a security nightmare due to its massive set of mutating tools. Here’s an exploit we found and the guardrails we wrote to mitigate it - https://www.tramlines.io/blog/heroku-mcp-exploit After we reported it, Heroku acknowledged and nerfed their remote MCP tool spec to drastically reduce the blast radius—removing tools that manage logs, deployments, etc. and leaving only those for managing instances.
With Tramlines, our goal is to give users the guardrail assurances they need to confidently use powerful MCPs—without having to rely on nerfed toolsets out of fear.