Over the past few months we’ve been adding MCP servers at a pace that’s hard to justify.
GitHub.
Slack.
Jira.
Postgres.
AWS.
Internal documentation.
Custom tools.
And in most cases the architecture looks something like this:
Claude Code
├── GitHub MCP
├── Slack MCP
├── Jira MCP
├── Postgres MCP
└── AWS MCP
It works.
It’s also a bit scary.
Because as agents start interacting with real systems, an inevitable question emerges:
Who decides what tools an agent can use?
The traditional answer was:
“The prompt.”
But the ecosystem is starting to converge on a different idea:
Prompting is not security. Architecture is security.
And that’s giving rise to a completely new category: MCP Gateways.
What is an MCP Gateway?
An MCP Gateway sits between the agent and the MCP servers.
Instead of Claude Code, Cursor, or Copilot talking directly to each tool, all calls go through the gateway first.
The architecture now looks like this:
Claude Code
│
▼
MCP Gateway
│
┌────┼─────┐
▼ ▼ ▼
GitHub Slack Postgres
The gateway becomes a control plane for all the tools available to agents.
Every call.
Every permission.
Every credential.
Every policy.
Everything goes through it.
Why do we need this?
Because a personal laptop and an organization don’t have the same needs.
In an individual project it probably doesn’t matter much if Claude has full access to GitHub.
In a company it’s a different story.
Imagine:
- dozens of developers,
- hundreds of repositories,
- multiple agents,
- production infrastructure,
- sensitive data,
- compliance requirements.
Giving direct access to everything stops being reasonable very quickly.
1. Access Control per Tool
The simplest case.
Let’s say you want to allow:
github.list_issues
github.create_pr
But you want to block:
github.delete_repository
github.change_admin_settings
With a gateway you can define exactly which tools to expose.
For example:
allow:
- github.list_issues
- github.create_pr
deny:
- github.delete_repository
- github.change_admin_settings
The important part:
the model never sees the forbidden tools.
It can’t invoke them by accident.
It can’t hallucinate them.
They simply don’t exist.
2. User-Based Permissions
Not all users need the same capabilities.
For example:
Engineering Team
GitHub
Jira
Documentation
Platform
AWS
Kubernetes
GitHub
Terraform
Finance
Slack
Salesforce
Analytics
The same agent can expose completely different tools depending on who’s using it.
This starts to look a lot like traditional IAM.
Just applied to agents.
3. Complete Audit Trail
One of the most attractive features for enterprise environments.
Every invocation is logged.
For example:
09:12
User: greg
Agent: Claude Code
Tool: github.create_pr
09:15
User: greg
Agent: Claude Code
Tool: jira.create_ticket
09:17
BLOCKED
Tool: aws.delete_cluster
Reason: security policy
This answers fundamental questions:
- Who executed this action?
- Which agent performed it?
- What tools did it use?
- What was blocked?
- When did it happen?
For security and compliance teams, this is huge.
4. Centralized Credential Management
Today many developers do something like this:
15 MCP servers
×
20 developers
=
300 credentials
It doesn’t scale.
A gateway allows you to centralize credentials.
The flow becomes:
Agent
↓
Gateway
↓
Backend
The agent never needs direct access to sensitive secrets.
The gateway handles authentication and credentials are kept centralized.
5. Execution Policies
Not all operations carry the same level of risk.
For example:
Automatically Allowed
Read documentation
Check issues
Search logs
Requires Human Approval
Modify production
Write to database
Run migrations
Always Blocked
DROP TABLE
terraform destroy
aws delete-cluster
This allows you to introduce progressive levels of autonomy.
Agents can work fast where risk is low and request approval when potential impact increases.
Some Interesting Projects
The ecosystem is still very young, but interesting implementations are already emerging:
Microsoft MCP Gateway
Oriented toward Kubernetes environments and enterprise deployments.
Permit MCP Gateway
Focused on authentication, authorization, and auditing.
Lasso MCP Gateway
Open source gateway with strong focus on security.
Pomerium MCP Gateway
Identity-based access and centralized policies.
They all point to the same problem:
how to govern a growing ecosystem of agents and tools.
The Real Story
Most discussions about agents still center on models.
GPT.
Claude.
Gemini.
But large organizations are already starting to worry about something else:
How do we control hundreds of agents accessing hundreds of systems?
Because the problem stops being intelligence.
It becomes governance.
And that’s where completely new categories emerge:
- Agent IAM
- MCP Gateways
- Policy Engines
- Agent Observability
- Agent Security
The intuition is quite simple.
If humans need:
- authentication,
- authorization,
- audit trails,
- policies,
agents probably do too.
And it’s quite possible that in a few years we’ll consider it normal to have an IAM for agents just as we consider it normal to have one for people today.
The next great infrastructure platform might not be for humans.
It might be for agents.