diff --git a/docs/content/product/auth/data-access-policies.mdx b/docs/content/product/auth/data-access-policies.mdx
index 6b405c46d11d1..076b2173efc76 100644
--- a/docs/content/product/auth/data-access-policies.mdx
+++ b/docs/content/product/auth/data-access-policies.mdx
@@ -240,8 +240,15 @@ dimension in your query.
-_When querying a view,_ data masking follows the same pattern as row-level
-security: masking rules from both the view and relevant cubes are applied.
+
+
+Unlike [member-level access policies][ref-dap-mls], which are **not** inherited
+from cubes when querying through views, data masking rules **are** applied from
+both the view and the relevant cubes. If you define masking on both a cube and a
+view that uses that cube, the masking will be applied twice. To avoid unexpected
+results, define masking rules on either the cube or the view, but not both.
+
+
For more details on available parameters, check out the
[`member_masking` reference][ref-ref-dap-masking].
diff --git a/docs/content/product/auth/member-level-security.mdx b/docs/content/product/auth/member-level-security.mdx
index 9741647ea7243..69b090bbb10db 100644
--- a/docs/content/product/auth/member-level-security.mdx
+++ b/docs/content/product/auth/member-level-security.mdx
@@ -10,6 +10,16 @@ Defining whether users have access to [cubes][ref-cubes] and [views][ref-views]
similar to defining access to database tables; defining whether they have access
to dimensions and measures — to columns.
+
+
+Just like in many SQL databases where table-level column policies are not
+inherited by views, member-level access policies defined on cubes are **not**
+applied when querying through views. Only the member-level policies defined on
+the view itself will take effect. Make sure to define access policies on your
+views directly.
+
+
+
__By default, all cubes, views, and their members are *public*,__ meaning that they
can be accessed by any users and they are also visible during data model introspection.