MCP governance: a practical rollout checklist

Define the scope of governance

MCP makes capabilities available through a common protocol. Governance determines who may use them, which changes need review, and what evidence operators need afterward. Those controls can span the client, gateway, server, and upstream provider.

A gateway gives teams one place to apply shared controls, but only for requests it receives. Inventory direct connections and alternative credentials too. Do not mistake a successful gateway test for control over every way a user or agent can reach the same data.

Inventory access and assign owners

Begin with one concrete use case. Record the client, requester, connection, upstream account, environment, tools, and data involved. Name the person responsible for granting access, reviewing changes, and resolving failures.

• Clients and requesters: identify people, automation identities, and how access is revoked.
• Connections: record the upstream account, credential owner, scopes, and environment.
• Tools: distinguish reads from writes and identify sensitive data, bulk operations, and external effects.
• Alternative paths: list direct provider credentials and connections that bypass the gateway.
• Operations: assign reviewers, incident owners, and a process for reconciling uncertain writes.

Configure policy and review tools separately

In Durin, requests must pass identity, membership, team, connection, credential, reviewed-tool, resource, and inspection checks. Default allow does not override a failed check. Administrators can deny all tool access and independently allow reviewed writes, require another administrator, or deny writes.

Team policy can narrow organization policy. The same controls apply in sandbox and production. The current editor is not an arbitrary per-tool or data-class rule builder, so map your desired operating rules to the controls that are actually available.

Unreviewed tools remain blocked until tool review is complete. An exact write approval cannot substitute for that review, make an unavailable connection ready, or grant missing provider permissions.

Test one connection before expanding

Choose a reviewed connection with a supported sandbox fixture. Begin with a low-sensitivity read and inspect the requester, decision, and result. Test a refused request as well, such as a resource outside the allowed scope.

For the write exercise, configure the approval requirement and involve a different active administrator. Confirm that the initial request and the approval itself do not execute the action. Retry the exact call before expiry, then check the execution result.

Test revocation, changed arguments, expired grants, and tool-definition changes. Use a controlled fixture to exercise an ambiguous write result and confirm that it is not automatically repeated. Expand the rollout using the same checks.

Keep useful evidence with a clear retention policy

Record enough context to explain the requester, connection, tool, policy decision, approval where required, and execution outcome. Authorization to run and confirmed completion are different facts. Assign someone to reconcile uncertain writes with the upstream system.

Decision records do not require retaining every prompt or response. Durin defaults conversation capture to metadata only. Administrators can enable redacted capture with a retention period of 1–30 days; that setting is separate from audit, account, and billing retention.

Use the trust materials to review control scope and supporting evidence. Certifications, independent assessments, and contractual commitments require their own evidence; a working demo does not establish them.

Use these questions at each rollout review

Revisit the checklist when a client, connection, credential, tool, or policy changes. Governance is an operating process as well as a gateway configuration.

• Can we identify the requester and the owner of every enabled connection?
• Have we tested both permitted and denied access to the intended resources?
• Are tool review and per-action approval treated as separate decisions?
• Does the configured write policy match the team’s requirements?
• Can we demonstrate expiry, exact retry, revocation, and uncertain-outcome handling?
• Do we know which access paths bypass the gateway?
• Are evidence access, retention, and incident ownership documented?