Start with read-only access

What this recipe establishes

This recipe gives a small group a reviewed read path, verifies the access boundary, and produces activity evidence before broader rollout. It is appropriate for a first installation or for introducing a new provider to an existing workspace.

• An administrator can complete connection setup and inspect policies.
• At least one intended member has the required team membership and provider account.
• A reviewed read tool and an allowed, low-risk resource are available.
• A second administrator is available only if you also plan to test the sandbox approval exercise.

Why start read-only

Read-only access exercises identity, policy, and audit checks without changing upstream data. Test write approval with the sandbox fixture; the current production execution boundary denies writes even when the policy says allow or approval.

Set up the pattern

Configure connections and policies for a read-only start.

1. Add your first connection and enable it.
2. In Policies, choose Deny all writes for the configurable write decision.
3. Review the tools and resources actually allowed to each member; a read-like name is not sufficient.
4. Have team members connect their MCP clients and run read-only requests.
5. Review the audit log to confirm everything works as expected.
6. In the sandbox, choose Require another administrator and test an exact approval and retry with a second administrator.

Choose a bounded first read

Pick a specific resource that the provider account is already allowed to read. For example, read one reviewed repository resource rather than asking an agent to explore every repository it can find. The purpose of the first request is to verify identity, scope, and the result.

Check the active tool definition and its allowed resource boundary before running it. Do not infer permission from a tool name or from the fact that an administrator could read the same data. The member’s personal authorization is part of the test.

Check a permitted and a restricted identity

A successful rollout needs evidence that the intended access works and that the intended restriction still holds. Use controlled test identities and expected boundaries; do not probe unrelated company data.

1. Run the chosen read as a member with the required team and provider access.
2. Find the matching activity and confirm the connection, tool, resource, decision, and provider outcome.
3. Repeat the access check with an identity that is deliberately outside the assigned team, if team scoping is part of the setup.
4. Confirm the restricted identity cannot use the scoped connection and that broadening the write setting is unnecessary.

Expand only the verified part of the rollout

Once the read path works, add another intended member or another reviewed read and repeat the same evidence check. This makes it easier to distinguish a membership problem from a new provider or resource problem.

Keep the write-approval exercise in the sandbox and document it separately. Passing that exercise shows the exact approval and retry flow; it does not enable production writes or establish every provider’s behavior.