Most teams think security reviews slow down development.
In reality, the opposite is often true.
The most expensive security review isn't the one performed before production. It's the one performed after an incident.
As AI agents and MCP deployments become more common, security teams are being asked to review something very different from traditional applications.
They're no longer reviewing only APIs.
They're reviewing:
- tools
- permissions
- approval workflows
- credentials
- side effects
- audit trails
And that's where many teams get surprised.
The Problem Isn't Authentication
Most organizations spend a lot of time discussing authentication.
Can the agent access the tool?
Can the user authenticate?
Is the API protected?
Those questions matter.
But they often miss the bigger risk:
What happens when the tool is used?
A tool that reads an order and a tool that refunds an order may both require authentication.
Only one can lose money.
Only one creates business consequences.
That's why production MCP deployments need side-effect analysis, not just access control.
The Cost Curve Is Brutal
A permission issue discovered during design might take ten minutes to fix.
The same issue discovered after launch can trigger:
- incident reviews
- engineering work
- emergency releases
- customer communication
- compliance reporting
The technical fix is usually the easy part.
The organizational cost is where things get expensive.
What Security Teams Actually Care About
When security teams review MCP deployments, they usually ask questions like:
- What tools exist?
- What can those tools do?
- Which actions change state?
- Which actions affect customers?
- Which actions affect money?
- Which actions require approval?
Engineering teams often see functionality.
Security teams see consequences.
Good reviews help both groups speak the same language.
Governance Is Not Bureaucracy
Governance gets a bad reputation because it sounds like paperwork.
In practice, governance is simply deciding:
- which tools should exist
- who can use them
- which actions need approval
- how activity is monitored
- how incidents are investigated
When these decisions are made before launch, deployments move faster.
When they're made after launch, every release becomes a negotiation.
What This Means For Production MCP
If you're deploying MCP in production:
- Classify every tool by risk level.
- Separate read-only tools from destructive actions.
- Require approvals for financial and administrative operations.
- Enable audit logging from day one.
- Store credentials in a secure vault, not in code or prompts.
The organizations that move fastest aren't the ones skipping reviews.
They're the ones doing reviews early.
Because fixing security problems before production is dramatically cheaper than fixing them after customers are affected.
Full article:
https://www.mcpforge.tech/blog/the-cheapest-security-review-is-the-one-you-do-before-production
Top comments (3)
Catching this early is cheaper, agreed. Where I'd disagree is the classify-by-risk and side-effect-analysis step. On a real server it tends to be over-engineering that still misses the actual problems, and worse, it hands you a false-safe label.
Take a read-only SQL MCP. Side-effect analysis looks at it, files it under read-only, low risk, move on. But it can pull some data it shouldn't see. How would analysis know that? This MCP requires careful design and review. Not only access, but also, connection pooling, rate-limiting and who knows what else. This doesn't generalize well IMO.
But in reality, people don't bother and just plug-in MCP/skills they find in the interned - so yeah, maybe in this case, tools like MCPForge helps.
Yeah, that's a good point.
I definitely wouldn't treat "read-only" as automatically low risk.
A read-only SQL MCP is a great example. It might not change anything, but it could still expose customer data, financial records, internal documents, or just allow someone to pull far more data than intended.
I guess my main point is that teams often focus on authentication first and forget to ask what a tool can actually do once access is granted.
For me, side-effect analysis is more of a starting point than a final risk rating.
A read-only tool that can access sensitive data is still something I'd want reviewed carefully.
And I completely agree on the third-party MCP problem. A lot of people are starting to install MCPs the same way they install browser extensions, without really understanding the permissions, credentials, or data access behind them.
That's actually one of the reasons I've been thinking so much about verification and security reviews lately.
Out of curiosity, are you using any third-party MCPs in production today, or mostly servers built in-house?
If I speak just for myself and my own small projects (I have some apps hosted in their prod-like infra), then I moved away from third-party MCPs at all. It got way too easy to just build your own MCP or cli + skill for any connectivity I need. My Claude Code can connect to my prod infra using the code I know and control. Security is on me.
If I speak for the company I work at, they build tons of internal MCPs and Skill - all of that severely over-engineered. So even there I try to use tools I created if possible.
We also have some MCPs for customers - this is where there is no work-around. Customers don't know how these servers are built and what they do, so they have to use them as blackboxes.