Policy and access issues

Start with the decision reason

A denied request does not necessarily mean the configurable write policy is wrong. Current membership, client authorization, connection state, team access, personal credentials, reviewed tools, resource scope, and inspection can independently stop the request.

Locate the exact request in the appropriate activity view and read its reason before changing settings. Identify the requesting account, connection, tool, resource, and time. Use the same context for your follow-up check so a different identity or environment does not hide the original problem.

Request unexpectedly denied

When a request is denied and you expected it to be allowed:

1. Open the request in the audit log and check the policy decision details.
2. Look at which policy rule triggered the denial.
3. Verify the requesting user is a member of the organization and has not been revoked.
4. Check if the user is assigned to a team that has access to the connection.
5. Verify the specific tool exists in the connection's reviewed tool list.

Approval stuck in queue

If an approval request is not being processed:

1. Check the Approvals page in the admin workspace.
2. Verify that someone with admin access is available to review.
3. Check if the approval has expired — expired requests need to be re-submitted.
4. After approval, retry the exact request before expiry; approval does not automatically execute it. Check execution outcomes before retrying a potentially completed write.

Tools not appearing

If your MCP client does not show expected tools from a connection:

1. Confirm the connection is enabled (not in draft or disabled state).
2. Check that the tool schema has been reviewed and activated.
3. Verify you are using the correct MCP endpoint for your workspace.
4. Check team assignments — the connection may be scoped to a team you are not in.

An allow setting still produces a denial

The configurable write decision runs within the mandatory access boundary. It cannot enable a disabled connection, restore a revoked member, approve an unknown resource, or make an unreviewed tool executable. Team denials can also impose a stricter result.

Production writes are denied by the current execution boundary even if the write setting says Allow reviewed writes or Require another administrator. Use a supported sandbox write to test the configurable decision. If TypeSafe content evaluation is enabled, check whether it further restricted the request or response.

An approved request still does not execute

Approval is bound to the exact request and does not resume the original call automatically. The requester must retry while the grant is valid, and the current authorization context must still satisfy the checks.

1. Confirm the reviewer was a different active administrator and granted this request.
2. Compare the tool, resource, and argument digest with the approved request.
3. Check expiry and whether the policy, tool, membership, or other bound context changed.
4. Inspect the execution outcome before deciding whether to submit a new request; an uncertain dispatched write needs an upstream outcome check.

Verify a correction without broadening access

Resolve the failed condition at its source, then repeat a small relevant request. For a team problem, correct authoritative membership or connection scope. For credentials, complete the affected person’s provider authorization. For a reviewed-resource problem, use an actually permitted resource.

Confirm both the expected permitted case and the intended restriction after the change. Do not switch the organization to a broader write decision simply to troubleshoot an unrelated sign-in or installation failure.