Current Problem

When an Organization Admin enables a Data Security Policy via Atlassian Guard (e.g., "Block anonymous access" or "Restrict data export"), the policy correctly enforces these restrictions across the organization. However, the local configuration settings within the specific products (such as Jira or Confluence) remain visible and sometimes appear "editable" to product admins.

For example, if a Guard policy blocks anonymous access for the entire organization, a Confluence Space Admin can still see the toggle for "Anonymous Access" in Space Permissions. This creates significant confusion and concern for admins who may think the global policy is not working or who may try to change settings that are already being overridden by Guard.

Suggested Solution

When a Data Security Policy from Atlassian Guard is active and covering a specific product or classification level, the corresponding local settings within Jira and Confluence should be updated to reflect this state.

1. Visual Feedback: Local settings (like the "Anonymous Access" checkbox in Confluence or "Export" buttons) should be grayed out or hidden.
2. Consistency: Ensure that if a policy blocks an action, the UI does not lead a user to believe that action is still possible.