# One MCP connection is not one permission model

Why a shared connector credential is not, by itself, a caller-specific permission model.

Author: Govna
Published: 2026-08-22
Updated: 2026-08-23

Evidence:
- [PRF-001](https://govna.io/solutions/security-leaders#PRF-001)

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](/solutions/security-leaders#PRF-001)).