Managing User Write Access in Off-the-Shelf MCPs for Cybersecurity Teams

·Aug 07, 2026 04:01 PM·

Anyone involved in Cybersecurity/MCP/AI protocols? I'm working with our Cyber Security group and I was wondering how others solved the problem of using off the shelf MCPs that give end users too much write access

3 comments

· Sorted by Oldest

Eva M.
·
·
The pattern I keep seeing: the MCP runs as one broad service account, so every user inherits its full access.. a classic confused-deputy setup. What’s worked for teams I’ve talked to: propagate the caller’s identity (OAuth on-behalf-of, not a shared token), split read vs write scopes, and put a proxy/policy layer in front so you can enforce least privilege the underlying API can’t express on its own. Human approval on writes + an audit log of every tool call covers the rest. The part most people miss is lifecycle: who revokes that access once the agent’s no longer needed, and who even knows it exists? That’s exactly the problem I’m building a solution for right now..
Hotragn P.
·
·
Spot on, Eva. The 'confused deputy' risk is exactly why we're looking at dedicated MCP gateways now. Have you evaluated Lasso (open source) or MintMCP yet? They both solve the identity propagation issue by sitting as a proxy layer to enforce OAuth scopes and human-in-the-loop approvals without rewriting the underlying servers. Lasso just launched their OSS gateway recently, might be worth a spike to see if it covers the lifecycle gaps you mentioned.
Eva M.
·
·
Appreciate this, Hotragn P. I’ll spike Lasso for sure. And yeah, that “lifecycle gaps” line is the thing: I’m actually building a tool for exactly that right now. The way I see it, gateways like Lasso/MintMCP own the runtime layer - they govern what routes through them, while it’s flowing. What I’m building sits out-of-band: it reads across the whole estate (Google, Slack, IdP, cloud) and maps who and what has access, then flags the orphaned and unowned stuff; the service account spun up straight in the console, the admin grant a leaver still holds and answers “who revokes this when it’s no longer needed.” Deprovisioning + access graph, not inline enforcement. Complementary to a gateway, not a replacement. Still early, but happy to share what I find as I go. Have you seen anyone actually close that lifecycle loop, or is it manual everywhere you look?

Eva M.
·
·
The pattern I keep seeing: the MCP runs as one broad service account, so every user inherits its full access.. a classic confused-deputy setup. What’s worked for teams I’ve talked to: propagate the caller’s identity (OAuth on-behalf-of, not a shared token), split read vs write scopes, and put a proxy/policy layer in front so you can enforce least privilege the underlying API can’t express on its own. Human approval on writes + an audit log of every tool call covers the rest. The part most people miss is lifecycle: who revokes that access once the agent’s no longer needed, and who even knows it exists? That’s exactly the problem I’m building a solution for right now..
Hotragn P.
·
·
Spot on, Eva. The 'confused deputy' risk is exactly why we're looking at dedicated MCP gateways now. Have you evaluated Lasso (open source) or MintMCP yet? They both solve the identity propagation issue by sitting as a proxy layer to enforce OAuth scopes and human-in-the-loop approvals without rewriting the underlying servers. Lasso just launched their OSS gateway recently, might be worth a spike to see if it covers the lifecycle gaps you mentioned.
Eva M.
·
·
Appreciate this, Hotragn P. I’ll spike Lasso for sure. And yeah, that “lifecycle gaps” line is the thing: I’m actually building a tool for exactly that right now. The way I see it, gateways like Lasso/MintMCP own the runtime layer - they govern what routes through them, while it’s flowing. What I’m building sits out-of-band: it reads across the whole estate (Google, Slack, IdP, cloud) and maps who and what has access, then flags the orphaned and unowned stuff; the service account spun up straight in the console, the admin grant a leaver still holds and answers “who revokes this when it’s no longer needed.” Deprovisioning + access graph, not inline enforcement. Complementary to a gateway, not a replacement. Still early, but happy to share what I find as I go. Have you seen anyone actually close that lifecycle loop, or is it manual everywhere you look?