A security review checklist for a governed MCP rollout

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). Confirm there is a single, well-defined entry point before trusting anything downstream of it — see MCP access governance 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). 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). 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). 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). 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). 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.