CTRLRun: execution safety for consequential GitHub MCP actions

[arpanghoshal]

I've been building CTRLRun, an open-source execution safety layer for AI agents, and GitHub MCP feels like a good example of why I built it.

Once an agent can merge PRs, push files, modify repositories, or trigger other write actions, I think the question goes beyond:

"Is this tool allowed?"

It becomes:

• Was this exact action approved?
• Did this effect already happen?
• Is it safe to retry?
• Can we prove what actually executed?

CTRLRun can sit in front of an MCP server as a gateway without requiring changes to the agent or the MCP server.

It focuses on things like:

• exact approval binding
• duplicate-effect protection
• ambiguous execution handling
• execution receipts
• runtime policy enforcement

I'd really like feedback from people using GitHub MCP:

Which GitHub write actions would you put behind controls like this first?

Also, if anyone is interested in MCP security, agent runtime safety, or contributing to this problem space, contributions and ideas are very welcome.

https://github.com/CTRLRun/ctrlrun

[samvallad33]

This is a strong writeup and the four questions you lead with, whether the action was approved, whether it already happened, whether it is safe to retry, and whether we can prove what executed, are exactly the right questions to ask at the MCP layer. I wanted to reply because I have been shipping answers to those same four questions in an open source project called Vestige, which is a local memory and authority kernel where actions carry signed receipts, destructive effects are bound to one time permits, and a duplicate attempt finds its own prior receipt instead of executing twice.

Two details from building it might be useful to your design. First, the approval binding works best when the approval is tied to the exact tool input and not to a broader intention, because loosely scoped approvals are where drift sneaks in. Second, there is a memory component worth considering alongside the gateway, since knowing what was already attempted and rejected is what lets the system catch repetition and contradiction, not just unauthorized writes. Vestige is free, runs entirely on your machine, and the receipt format is documented, so I would be glad to compare notes on how the permit and receipt model maps onto what you are proposing for CTRRun.

Genuinely glad someone opened this thread on this repo, because execution safety is the conversation the MCP ecosystem needs to be having right now.