The question to ask about any MCP gateway is not is this secure but what is the least privilege this agent can do its job with, and does the connection actually enforce it. Most setups fail that question, and they fail it for two different reasons. One is familiar. One is genuinely new. Separating them is the fastest way to fix the right thing.
The familiar problem
Least privilege means an identity gets only the access its task requires, nothing more. The old, well-understood failure is over-broad credentials. Someone wires the MCP server to a database using an admin account because it was the credential on hand, and now every tool the model can call inherits admin. This is the same mistake teams have made with service accounts for years. It is not new, and the fix is not new: scope the credential to the resource, drop the privileges to the minimum the task needs.
You already know how to reason about this. It is the part of MCP security that looks like every other access problem, and the existing least privilege playbook applies directly.
The genuinely new problem
Here is what MCP gateways add. The identity driving the tools is a model, and the model's behavior is shaped by inputs you do not fully control, including data it reads during a task. So even a perfectly scoped credential can be exercised in an order or combination nobody intended, because the thing deciding which tools to call is not a fixed program.
This changes what least privilege has to mean. It is no longer enough to limit what the connection can reach. You also need the access to exist only while the task runs, and you need dangerous operations to require a human, because you cannot assume the agent will only do the reasonable thing with the privileges it has.
Put differently, the static dimension of least privilege, the size of the grant, is necessary but no longer sufficient. You now also have a temporal dimension, how long the privilege is live, and a discretion dimension, which actions the agent gets to take on its own versus which require a human. A fixed program with a narrow grant only needed the first. An agent driven by a model that reads untrusted input needs all three, because the same narrow grant can be exercised in ways the task never called for.
What least privilege looks like for an agent
- The connection is scoped to the specific resources the task needs, not the whole system.
- Access is granted just in time and expires after the task, so privilege is not standing.
- Destructive or high-impact commands route for human approval rather than executing on the model's say-so.
- Every action is attributed to an identity and recorded, so you can verify the privilege was used as intended.
Enforcing it below the agent
The reason this belongs on the connection is that the agent cannot be trusted to limit itself, and the MCP server runs the tool calls so it should not be the only thing scoping them. hoop.dev is an identity-aware proxy that sits between the agent and the infrastructure. It binds each session to an authenticated identity, grants just-in-time access scoped to the resource, and routes risky commands for approval, all enforced where the agent cannot reconfigure it.
That is least privilege made real for a non-human actor: narrow scope for the familiar problem, plus time-bounding and approval for the new one. See how just-in-time scoped access is configured and the broader model in hoop.dev's runtime governance writing.
FAQ
Is least privilege for agents different from least privilege for people?
Partly. The scoping discipline is the same. What is new is that the agent's actions are driven by a model influenced by untrusted input, so least privilege must also include time-bounding and approval, not just a narrow grant.
Why not just give the agent a read-only credential and stop there?
Read-only helps, but many useful agent tasks need writes, and a broad read credential can still exfiltrate. Scope to specific resources, time-bound the access, and gate the dangerous operations.
Where should least privilege be enforced?
On the infrastructure connection, below the MCP server and the model, so the agent cannot widen its own privilege.
The gateway is open source. Read and deploy it from the hoop.dev repository on GitHub to enforce least privilege on the connections your MCP tools use.
