MCP gateways: what they mean for your access reviews

Your quarterly access reviews list every human who can reach the production database. They do not list the agent that now reaches it through an MCP gateway, because nobody onboarded that agent the way they onboard a person. That omission is where MCP gateways and access reviews overlap, and it is worth being precise about it.

Access reviews exist to answer one question on a schedule: does every identity that can reach a system still need that access. An MCP gateway introduces a new kind of identity, a model calling tools, that reaches the same systems. If your access reviews only see human accounts, the agent's standing access never comes up, and standing access nobody reviews is exactly the thing reviews are supposed to catch.

Where the overlap actually is

An MCP gateway exposes tools to a model. Those tools connect to databases, clusters, and internal APIs. The connection has an identity and a scope, whether or not anyone reviewed it. So the overlap is not abstract. The agent's reach is a line item your access reviews should contain, and today it usually is not.

The practical risk is twofold. First, the agent often inherits a broad service credential because that was easiest to wire up, so it can do far more than its job requires. Second, that grant tends to be permanent, sitting there between reviews, available to anything that can drive the MCP server.

Practical guidance

1. Treat the agent connection as a reviewable identity. It belongs in the same inventory as human access, with an owner and a documented scope.
2. Scope the connection to the specific resources the agent's task needs, not the whole database or cluster. A review is only meaningful if there is a tight grant to confirm.
3. Grant access just in time rather than standing. If access is created for a task and expires after, the review surface shrinks to what is actually live.
4. Make every agent action attributable to an identity, so a reviewer can see not just what the agent could do but what it did.

The architecture that makes reviews easy

A review is only as good as the access model underneath it. If access is standing, broad, and unattributed, the review is a spreadsheet exercise. If access is scoped, time-bound, and recorded, the review nearly writes itself. That second model is what hoop.dev is built to provide.

hoop.dev sits as an identity-aware proxy between the agent and the infrastructure the MCP tools reach. It binds each connection to an authenticated identity, grants just-in-time access instead of permanent credentials, and records every session at the command level. So the agent shows up in your access reviews as a first-class identity with a scope you can confirm and a history you can read, rather than a credential nobody remembers issuing.

There is a second benefit that matters once you run reviews at any scale. When access is just-in-time, most of the time there is nothing to review, because no grant is live. The review stops being a list of every credential that might be in use and becomes a much shorter question: which scopes were exercised, by which identities, and were any of them wrong. The recorded sessions answer that directly, so the review moves from guessing about standing access to reading what actually happened.

That also fixes the orphaned-credential problem that haunts agent setups. A service account wired into an MCP server six months ago, by an engineer who has since left, is exactly the kind of standing access a review is supposed to flag and exactly the kind it usually misses. If the agent has no standing credential, there is no orphan to find. The access existed for a task and is already gone.

For the human side of this, see how just-in-time access changes the way teams get started with scoped access, and the broader model in hoop.dev's writing on runtime access governance.

FAQ

Do agents connected through MCP gateways belong in access reviews?

Yes. They are non-human identities that reach reviewable systems. Leaving them out means your access reviews no longer cover everything that can touch the data.

What makes an agent's access hard to review?

Broad standing credentials. If the agent holds a permanent, wide grant, there is no tight scope to confirm and no expiry to rely on. Scoped, just-in-time access fixes both.

Does hoop.dev replace the access review process?

No. It gives the process something clean to review: attributed identities, narrow scopes, and time-bound grants, with a session record behind each one.

The gateway and agent that enforce this are open source. Clone the hoop.dev repository on GitHub and put your MCP-connected agents under a scope your next access review can actually verify.