One MCP connection is not one permission model

A quick way to connect an agent to a tool is to reuse a connection that already works — the same one a script or teammate uses. Agents that rely on the same standing credential operate within that credential’s scope unless another authorization layer narrows it for each use.

That collapse is easy to miss because nothing about it looks wrong at setup time. The connection was scoped once, thoughtfully, for its first use. The problem shows up later, when a second agent, then a third, gets pointed at the same connection because it’s already there. Nobody re-evaluates the scope for the new use case, because there wasn’t a moment that forced a re-evaluation — just a URL and a credential that already worked.

The deeper issue is that “one connection” and “one permission model” sound like the same thing but aren’t. A permission model is supposed to answer “who can do what, and why.” A shared connection, by itself, describes what can be done through that connection; it does not establish which caller may use each part of that scope. A separate authorization layer can make that distinction. Without one, an agent that needs read access to one project may inherit the credential’s broader reach. In that architecture, removing one agent’s access may require rotating a credential shared by other agents, which makes revocation disruptive.

None of this is a knock on any particular tool or protocol — it’s a property of sharing, not of MCP itself. Govna’s alternative is to treat each session’s access as its own decision, with a reusable profile serving only as a template that is re-authorized and may narrow for that session (PRF-001).