Show HN: Armour – A secure stdio MCP proxy, written in Go | Hacker News Reader

Show HN: Armour – A secure stdio MCP proxy, written in Go

github.com

23 pointsdevel126 comments

At my last company, we connected Claude Code and Cursor to almost all our internal services via MCP. It made the team incredibly fast, but we hit a wall: permissions.

If you give an agent "Read Only" access, it can’t actually fix anything. If you give it "Write" access, it’s only a matter of time before a hallucination or a bad prompt results in a deleted database or a nuked production bucket. We had a few "close calls" that convinced us that simply reducing IAM permissions makes agents useless.

I built Armour (https://github.com/fuushyn/armour) to solve this. It’s a stdio proxy for MCP servers that lets you stay "secure by default" without stripping the agent's capabilities.

How it works: Instead of connecting your IDE directly to an MCP server, you point it to Armour. It acts as a middleware layer where you can:

Register all tools in one place: A single proxy for all your internal MCPs.

Argument-level blocking: This is the core feature. You can allow an agent to use a tool like github, but block specific arguments like delete.

The goal is to move away from the "all-or-nothing" permission model. You should be able to trust an agent with a shell without worrying it will run rm -rf /.

Repo - https://github.com/fuushyn/armour

Open articleView on HN

If you’re using MCP/tool-using coding agents internally, how are you handling “blast radius”? Are you relying on IAM scoping, confirmation prompts, sandboxing, policy proxies, or something else?

We kept hitting cases where read-only made agents useless, but write access was too risky. We ended up building a small stdio MCP proxy that lets us block dangerous operations at the argument level

Looks promising! Will try this out in my workflow.

this seems super interesting - would totally give it a try this week.

wohoo!

Great execution on this - the argument-level blocking is the key insight. The all-or-nothing permission model is exactly why MCP adoption stalls in production.

We've been working on a similar problem at https://keypost.ai, coming at it from the policy enforcement angle - rate limits, cost caps, and access control rules that sit in-path. The challenge we keep hitting is rule composition: when you have multiple constraints (e.g., "can use github.delete but only on branches matching feature-*, and only 3x per hour"), the config can get unwieldy fast.

Curious how you're handling rule definitions in Armour - is it purely argument pattern matching, or are you thinking about stateful rules (like rate limits or quotas)?

Really glad to see more people building in this space. The MCP security story needs a lot more attention.

Reply on news.ycombinator.com