HN Explorer

Show HN: Armour – A secure stdio MCP proxy, written in Go (github.com)

23 points by devel12 ↗ HN
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

8 comments

[ 3.5 ms ] story [ 23.1 ms ] thread
devel12
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?
mayank_sethi
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
[deleted]
(comment deleted)
kaushikasp
this seems super interesting - would totally give it a try this week.
mehulagrawal
Looks promising! Will try this out in my workflow.
kxbnb
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.