Create and manage policies

Before changing a policy

Use an active administrator account and identify the request behavior you want to change. The current policy controls support the workspace write decision and stricter team restrictions. Reviewed tool resources, personal provider access, and connection team assignment remain separate controls.

Record the current decision and choose a small test request for the intended result. If your goal is to allow a particular resource, first inspect the tool’s reviewed resource boundary; changing the global write decision does not add resources or make an unreviewed tool executable.

Create a new policy

Change the supported write decision from the admin workspace. The current editor is not an arbitrary per-tool or resource-pattern rule builder.

1. Go to Policies in the admin workspace sidebar.
2. Open the configurable write policy, or use Add policy to apply the available block-writes preset.
3. Review the policy scope shown in the detail dialog.
4. Set Write decision to Allow reviewed writes, Require another administrator, or Deny all writes.
5. Use team and connection controls separately when narrowing access for a group.
6. Click Publish policy. Publishing creates a new version and invalidates earlier exact approvals.

Common policy patterns

Here are policies that most organizations should consider:

1. Require another administrator for supported reviewed writes; reads still require identity, resource, and credential checks.
2. Choose Deny all writes for a read-only rollout. Production writes remain blocked regardless of the selected write decision.
3. Assign connections to teams to limit which group can use an installation.
4. Review the resource boundary of each tool. A name or schema alone does not authorize an arbitrary resource.

Publish a policy change

Open a configurable policy and publish the write decision. Required protections are displayed as non-configurable and cannot be disabled. After any policy change, re-run the relevant request; earlier exact approvals are invalidated.

Choose the write decision deliberately

Use the option that matches your rollout, then test its consequences with a supported sandbox write. Production writes remain denied regardless of this selection.

• Allow reviewed writes lets an otherwise permitted supported write proceed without a new independent approval requirement from this setting.
• Require another administrator returns an approval-required result and leaves the action unexecuted until the requester retries with a valid exact grant.
• Deny all writes blocks writes through this policy decision while leaving reviewed reads subject to their normal checks.

Validate the published version

Publishing creates a new policy version and invalidates earlier exact approvals. A request approved under the previous context must be reviewed again; do not use the earlier approval to assess the new rule.

1. Confirm the saved decision is visible in the policy detail.
2. Run a reviewed read to verify that the intended read path still works.
3. Run the relevant supported sandbox write and inspect whether it is allowed, denied, or approval-required.
4. Check an identity subject to a stricter team policy to confirm that the workspace setting did not weaken that restriction.

Correct a policy that blocks the wrong workflow

Reopen the configurable policy, choose the intended supported decision, and publish another version. Do not disable a required protection or broaden team membership merely to make one failing request pass.

If the failure remains, inspect the decision reason. Membership, client revocation, connection state, credentials, tool review, resource scope, and content evaluation can all stop a request independently of the write setting. Follow the policy troubleshooting guide to identify the actual blocker.