The Most Expensive Security Review Is the One You Skip

kamolc4 — Thu, 18 Jun 2026 16:16:18 +0000

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

Stop Asking How Many MCP Servers You Need

kamolc4 — Wed, 17 Jun 2026 22:58:14 +0000

Most teams approaching MCP ask the wrong question:

Should we run one MCP server or ten?

The real question is:

Where are your trust boundaries?

After looking at dozens of MCP deployments, I've noticed that server count is rarely the actual problem.

The problem is governance.

When AI agents gain access to tools, an MCP server stops being just an integration layer. It becomes a capability boundary.

A single MCP server might expose:

customer data
billing operations
infrastructure controls
support workflows

From a developer perspective, that feels convenient.

From a security perspective, it's a nightmare.

The Common Mistake

Many teams organize MCP servers around technical convenience:

one server per API
one server per agent
one giant "tools" server

This works during experimentation.

It starts breaking down once:

multiple teams are involved
approvals are required
audit logs matter
production systems are connected

At that point, the important question becomes:

Who owns these tools?

Who approves access?

What credentials do they use?

What happens if an agent makes a mistake?

The Pattern That Makes Sense

The model I've seen work best is:

Split MCP servers by business domain.

For example:

Engineering MCP

GitHub
CI/CD
deployment status

Support MCP

customer lookup
ticket history
draft responses

Billing MCP

invoices
subscriptions
refund requests

Then separate dangerous actions from read-only tools.

Read access scales differently from write access.

A tool that reads an invoice and a tool that issues a refund should rarely live in the same trust boundary.

What Changes In Production

As MCP deployments grow, architecture decisions become security decisions.

The conversation shifts from:

"How do we generate tools?"

to:

"How do we control them?"

That's where concepts like:

tool permissions
approval workflows
audit logs
credential isolation
side-effect detection

become more important than tool generation itself.

The hardest production problems aren't technical.

They're governance problems.

My Rule Of Thumb

For most teams:

Prototype → 1 MCP server
Internal pilot → 1–3 MCP servers
Production → split by domain and risk

Not because more servers are inherently better.

Clear boundaries are easier to understand, audit, secure, and operate.

The best MCP architecture isn't the one with the fewest servers.

It's the one where every server has:

a clear purpose
a clear owner
a clear permission model
a clear audit trail

That's what scales.