diff --git a/docs/admin_docs/security/security.mdx b/docs/admin_docs/security/security.mdx
index dac7ae6ad75..4b12e7b0e3f 100644
--- a/docs/admin_docs/security/security.mdx
+++ b/docs/admin_docs/security/security.mdx
@@ -619,6 +619,28 @@ SELECT * FROM (
   queries run against tables that have associated datasets with RLS filters will then have
   the appropriate predicates injected automatically.
 
+#### RLS Indicator in the Dataset List and Explore
+
+When a dataset has one or more RLS filters that apply to it, Superset shows a lock
+icon badge next to the dataset name in the **Datasets** list and next to the dataset
+selector in **Explore**. Hovering over the badge shows a tooltip listing each
+applicable filter's name, filter type (Regular or Base), group key (if any), assigned
+subjects (labeled "Roles" in the tooltip, but may include users and groups too), and
+clause.
+
+This badge also surfaces filters that are inherited from the physical tables
+referenced by a virtual (SQL-based) dataset, as described above. Inherited filters
+are marked "from underlying table" in the tooltip, and a summary note is shown
+whenever any of the listed filters are inherited rather than assigned directly to
+the dataset. Inherited-filter detection depends on Superset's SQL parser being able
+to identify the referenced tables and match them to a physical dataset by name,
+schema, and database, so it's best-effort: unparseable or unmatched references won't
+surface a filter on the badge even if one would apply at query time.
+
+The badge is a visibility aid only — it does not change which filters are applied to
+a query. Use the RLS REST API described below if you need to confirm exactly which
+filters affect a dataset.
+
 #### Checking RLS Filters via the API
 
 You can use the RLS REST API to audit which filters are configured and which datasets