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

  • devel12 5 hours ago |
    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 5 hours ago |
    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
  • kaushikasp 5 hours ago |
    this seems super interesting - would totally give it a try this week.
  • avilasha 4 hours ago |
    wohoo!
  • mehulagrawal 39 minutes ago |
    Looks promising! Will try this out in my workflow.
500 Internal Server Error

500 Internal Server Error