diff --git a/src/current/_includes/v25.4/misc/session-vars.md b/src/current/_includes/v25.4/misc/session-vars.md
index faa02c08700..afa9892ef04 100644
--- a/src/current/_includes/v25.4/misc/session-vars.md
+++ b/src/current/_includes/v25.4/misc/session-vars.md
@@ -109,7 +109,7 @@ The following session variables are exposed only for backwards compatibility wit
 | <a id="integer-datetimes"></a> `integer_datetimes` | `on` | No | Yes |
 | <a id="max-identifier-length"></a> `max_identifier_length` | `128` | No | Yes |
 | <a id="max-index-keys"></a> `max_index_keys` | `32` | No | Yes |
-| <a id="row-security"></a> `row_security` | `off` | No | Yes |
+| <a id="row-security"></a> `row_security` | `on` | Yes | Yes |
 | <a id="standard-conforming-strings"></a> `standard_conforming_strings` | `on` | No | Yes |
 | <a id="server-encoding"></a> `server_encoding` | `UTF8` | Yes | Yes |
 | <a id="synchronize-seqscans"></a> `synchronize_seqscans` | `on` | No | Yes |
diff --git a/src/current/v25.4/row-level-security.md b/src/current/v25.4/row-level-security.md
index ba9545566b0..2bb9241ba85 100644
--- a/src/current/v25.4/row-level-security.md
+++ b/src/current/v25.4/row-level-security.md
@@ -128,6 +128,26 @@ For examples, refer to:
 - [`ALTER TABLE ... ENABLE ROW LEVEL SECURITY`]({% link {{ page.version.version }}/alter-table.md %}#enable-row-level-security).
 - [`ALTER TABLE ... FORCE ROW LEVEL SECURITY`]({% link {{ page.version.version }}/alter-table.md %}#force-row-level-security).
 
+### Detect when row-level security is applied to a query
+
+The [`row_security`]({% link {{ page.version.version }}/set-vars.md %}#row-security) [session variable]({% link {{ page.version.version }}/session-variables.md %}#row-security) controls whether queries in the current session should silently honor RLS policies or error when those policies would filter out rows. 
+
+The variable defaults to `on`, which applies policies as normal. Setting it to `off` lets non-admin users detect when an RLS policy would alter their results by returning an error instead of silently filtering rows. [Admin users and table owners]({% link {{ page.version.version }}/alter-table.md %}#force-row-level-security) remain exempt from RLS regardless of this setting. Table owners will still be subject to RLS if [`ALTER TABLE ... FORCE ROW LEVEL SECURITY`]({% link {{ page.version.version }}/alter-table.md %}#force-row-level-security) is in effect.
+
+The following example shows how this session setting works:
+
+{% include_cached copy-clipboard.html %}
+~~~ sql
+-- Enable RLS error detection for the current session.
+SET row_security = off;
+
+-- This query now errors if an applicable policy would filter rows.
+SELECT * FROM sensitive_table;
+
+-- Restore the default behavior.
+RESET row_security;
+~~~
+
 ### RLS for data security (fine-grained access control)
 
 In a fine-grained access control scenario, you will want to restrict access to specific rows within a table based on user [roles]({% link {{ page.version.version }}/security-reference/authorization.md %}#roles), attributes, or relationships defined within the data itself. This goes beyond table-level [`GRANT`]({% link {{ page.version.version }}/grant.md %}) permissions. Common examples include restricting access to salary information, personal data, or region-specific records.