# Do you need an MCP gateway? Often, no

> Do you need an MCP gateway? Four tests that say no, one that says not yet, and the three events that change the answer. Written by a vendor, on purpose.

**TL;DR** Most teams asking this question do not need a gateway yet, and buying one early buys administration rather than safety. The honest threshold is not a headcount. It is the first time you cannot answer who may reach what, cannot remove access centrally, or cannot say which account an agent touched. Until one of those hurts, the built-in connectors are the right tool.

## Do you need an MCP gateway, honestly

We sell one, so treat the rest of this accordingly. It is still worth writing,
because the fastest way to make a category look untrustworthy is for every
vendor in it to answer this question yes.

Most teams asking whether they need an MCP gateway do not need one yet. Buying
early does not buy safety. It buys an administration surface: roles to define,
restrictions to maintain, and a seat count to justify, in exchange for
controlling a risk that has not shown up.

What follows is four situations where the answer is no, one where it is not yet,
and the three events that genuinely change it.

## No, if the accounts are genuinely personal

The clearest case. If each person is connecting their own account to their own
assistant, and that account already carries exactly the access their job gives
them, a gateway adds a checkpoint in front of a door they are already entitled
to open.

An agent acting for a person inside that person's own permissions is not a new
risk category. It is the same access, used faster. The thing worth watching
there is blast radius on destructive actions, and that is better handled by the
client's own approval prompts than by a procurement cycle.

## No, if you are still finding out whether this is useful

A great many teams are two weeks into discovering whether agents help at all.
Buying governance at that point answers a question nobody has asked yet, and it
slows down the experiment that would have told you whether to care.

Find out the cheap way. Use the connectors already in the client, give it a
month, and see what people actually reach for. If the answer turns out to be
"not much", you have saved a budget line. If it turns out to be "constantly, and
against the customer database", you have learned something specific enough to
act on.

## No, if the honest problem is shared credentials

This one comes up disguised as a gateway question and is not one.

If a single service account is pasted into several people's clients right now,
that is worth fixing this week, and a gateway is only one of the ways to fix it.
Individual accounts with the right permissions fix it too, often faster and for
nothing.

The reason it matters more than it looks: once several people act through one
identity, no logging downstream can tell them apart. Buying an audit trail that
records the same shared account for everybody is buying a record of nothing. Fix
the identity first, then decide whether you still have a governance problem.

## No, if one trusted operator runs everything

A single team with a handful of systems and one person who sets things up does
not need a control plane to know who has what. They know. Writing it down in a
shared document is a legitimate answer at that size and it costs nothing.

We wrote the longer version of this case in
[running your own MCP servers](/blog/running-your-own-mcp-servers/), including
the point where the self-hosted answer stops working. The summary: the cost of
self-hosting is not compute, it is the per-person work of issuing credentials,
removing them, and answering questions afterwards. That work scales with people
multiplied by systems, while the server count scales only with systems.

## Not yet, if you can still answer the three questions from memory

Here is the test that actually decides it, and it is not a headcount.

Ask yourself three things. Who may reach the system you would least like an
agent to write to. How you would remove one person's access to it by tomorrow
morning. And what an agent did with it last Tuesday.

If you can answer all three from memory, you do not need a gateway. You need to
write the answers down somewhere other than your memory, and check again in a
quarter. The moment any one of those answers becomes "I would have to ask
around", the situation has changed and so has the answer.

## The three events that change it

They arrive in a predictable order.

**A second team.** Access stops being self-evident once the people using a
system are not all in one room. This is usually the first real signal, and it
tends to be mistaken for a headcount threshold when it is actually a boundary
count.

**A departure.** The first time somebody leaves and you have to work out what
they still hold, you find out whether your setup has a revocation story. If the
answer involves finding URLs that were pasted into clients, you have learned
that the address was the credential all along.

**A question from outside the team.** Security, compliance or a customer asks
what an agent did. Per-person setups produce per-person histories, which is a
different artifact from an organization's audit trail, and the difference only
becomes visible when somebody asks.

## If one of those has happened

Then the question stops being whether and becomes which, and the useful axis is
narrower than the feature grids suggest: what varies from one person to the
next, and what the log can answer afterwards.

For what it is worth, Elaichi's answer is one organization-wide endpoint where
the grant varies rather than the URL, so removing a member revokes every live
grant in the same transaction as the membership change. Role and restriction
changes are slower and we say so: about two minutes. The
[MCP gateway comparison](/blog/mcp-gateway-comparison/) puts that alongside four
other approaches, with sources, including the places where somebody else is the
better fit.

And if none of the three events has happened to you, close this tab. The
built-in connectors are doing their job, and we would rather you come back when
something has actually changed than buy a control plane for a problem you are
not having.

## FAQ

### Do you need an MCP gateway for a small team?

Usually not. If the people involved are few, the accounts they connect are genuinely their own, and nobody outside the team is asking what the agents touched, the connectors built into Claude and ChatGPT are the right tool. A gateway bought before those conditions break adds administration without removing a risk you actually have.

### What changes the answer?

Three events, in roughly this order. A second team starts using the same systems, so access stops being self-evident. Somebody leaves and you have to work out what they still hold. And somebody outside the team asks what an agent did on a specific day. Any one of those turns a per-person setup into a per-person problem.

### Is shared credentials a reason to buy a gateway?

It is a reason to stop sharing credentials, which a gateway is one way to achieve and not the only one. If a single service account is pasted into several people's clients today, fixing that is urgent regardless of what you buy, because no audit trail downstream can tell those people apart once they share one identity.

## Read next

- [MCP gateway comparison: what each one governs](/blog/mcp-gateway-comparison/) — An MCP gateway comparison across five ways to give a company governed AI access, what each one actually controls, and the question that separates them: what varies from one person to the next.
- [Running your own MCP servers, or not](/blog/running-your-own-mcp-servers/) — Running your own MCP servers is cheap for one team and expensive for a company. The line is not the servers, it is credentials, revocation and the audit trail.
- [Four questions an agent audit log must answer](/blog/audit-log-questions/) — After an agent changes something nobody meant to change, an agent audit log has four questions to answer: which account, which actor, which rule was in force, and what else was tried.