# A security review checklist for a governed MCP rollout

What to actually verify before trusting an MCP deployment with agent access, mechanism by mechanism.

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

Evidence:
- [MCP-001](https://govna.io/solutions/security-leaders#MCP-001)
- [PRF-001](https://govna.io/solutions/security-leaders#PRF-001)
- [CON-001](https://govna.io/solutions/security-leaders#CON-001)
- [GRD-001](https://govna.io/solutions/security-leaders#GRD-001)
- [AUD-001](https://govna.io/solutions/security-leaders#AUD-001)
- [TEN-001](https://govna.io/solutions/security-leaders#TEN-001)

A rollout review for agent access should not start with a feature list. It
should start with the handful of mechanisms that decide whether an agent's
access is actually bounded, and check each one on its own terms.

**Where does the connection enter, and what does it require?** Govna exposes
one Streamable HTTP endpoint whose OAuth authorization flow issues an exact,
consent-bound session grant ([MCP-001](/solutions/security-leaders#MCP-001)). Confirm there is
a single, well-defined entry point before trusting anything downstream of
it — see [MCP access governance](/glossary) for
what that entry point does and does not cover.

**What does a grant actually describe, and how is its scope decided?**
Profiles are reusable request templates for connector identities,
identity-qualified tools, and duration; every resulting grant and session
receives its own authorization and can only narrow those selections
([PRF-001](/solutions/security-leaders#PRF-001)). A reviewer should be able to point at a
grant and name exactly what it authorizes — not infer it from defaults.

**Can an upstream change quietly expand what an agent can already reach?**
Connector updates do not silently expand existing grants; changed tools
pause and new tools stay hidden until a snapshot is explicitly reviewed
([CON-001](/solutions/security-leaders#CON-001)). Ask what happens the day a connector adds a
new capability — the answer should involve a human, not a background sync.

**What happens to a risky call in flight?** Guardrails can deny, require
approval, or safely transform MCP traffic through a default-deny pipeline
that revalidates arguments before dispatch ([GRD-001](/solutions/security-leaders#GRD-001)).
Verify that "allow" is not the only reachable outcome for a borderline
request.

**Is there a record, and does it hold up under a fail-closed test?** Tool
calls fail closed when audit intent cannot be committed — a call that cannot
be receipted does not happen ([AUD-001](/solutions/security-leaders#AUD-001)). Ask what the
system does when the audit write itself fails; the answer should be "deny,"
not "proceed and log later."

**Is one organization's access actually isolated from another's?**
Tenant-owned records are isolated in the database through organization keys,
forced row-level security, and transaction-local actor context
([TEN-001](/solutions/security-leaders#TEN-001)). Isolation claimed in documentation and
isolation enforced where the data lives are different things; ask which one
you are looking at.

None of these checks is a substitute for reading the underlying proof
records yourself. Each one names the exact scope and limitation of the
control it covers — a rollout review is the act of reading those honestly,
not assuming the strongest possible interpretation of a feature name.