docs(security): state privileged view authority

Author: seonghobae

AGENTS.md

@@ -56,12 +56,18 @@ add CODEOWNERS-based merge gates until multiple independent maintainers exist.
   visibility. Every callable routine in that closure must also pin its routine-level
   `search_path = pg_catalog, pg_temp`; absent or different name-resolution authority
   is rejected before tenant binding or outbox data SQL, rather than trusting caller
-  temporary-schema state or unqualified user-schema objects. PostgreSQL permits a
-  role administrator to grant the administered role to a new principal even when
-  the administrator's own membership is `INHERIT FALSE, SET FALSE`; the new
-  principal can then use the granted role's selectable path after the definer
-  returns. `SECURITY DEFINER` similarly executes with its owner's privileges, so a
-  safe outer owner does not make a privileged nested definer safe. Direct runtime
+  temporary-schema state or unqualified user-schema objects. Caller-selectable
+  ordinary views that directly depend on the lifecycle outbox are also outside the
+  runtime envelope when they are not `security_invoker=true` and their owner is a
+  superuser or `BYPASSRLS` principal with outbox read authority. PostgreSQL otherwise
+  applies the view owner's permissions and RLS policies to the underlying relation,
+  so such a view can expose cross-tenant rows even when the runtime caller itself is
+  `NOBYPASSRLS`; reject that authority before tenant binding or outbox data SQL.
+  PostgreSQL permits a role administrator to grant the administered role to a new
+  principal even when the administrator's own membership is `INHERIT FALSE, SET
+  FALSE`; the new principal can then use the granted role's selectable path after the
+  definer returns. `SECURITY DEFINER` similarly executes with its owner's privileges,
+  so a safe outer owner does not make a privileged nested definer safe. Direct runtime
   `CREATEDB` and `CREATEROLE` are database/role administration capabilities outside
   an application identity; callable `CREATEROLE` is rejected because it is
   executable within the definer boundary, while `CREATEDB` remains covered when
@@ -80,17 +86,18 @@ add CODEOWNERS-based merge gates until multiple independent maintainers exist.
   parser-normalized `USING`/`WITH CHECK` predicates and allowed catalog dependencies,
   and the complete effective/session-selectable authority envelope before tenant
   binding or outbox data SQL. A migration success record is point-in-time evidence
-  and does not authorize later same-name policy, ACL, membership, routine, or
+  and does not authorize later same-name policy, ACL, membership, routine, view, or
   role-authority drift. The normal runtime role needs only non-grantable `SELECT`
   and `INSERT` on the outbox. Replay serialization must use transaction-scoped
   advisory locking on the validated tenant/event identity rather than `SELECT ...
   FOR UPDATE`, so serialization never requires ambient row-mutation authority. Do
   not authenticate runtime connections as a database creator, role administrator,
   replication identity, relation maintainer, DML delegator, privileged definer
-  gateway, or other administrator and rely on `SET ROLE` or `SET SESSION
-  AUTHORIZATION` as a downgrade; administrative, replication, maintenance,
-  grant-capable, membership-delegating, executable-privileged, and owner-capable
-  login sessions are outside the application isolation guarantee.
+  gateway, privileged-view gateway, or other administrator and rely on `SET ROLE` or
+  `SET SESSION AUTHORIZATION` as a downgrade; administrative, replication,
+  maintenance, grant-capable, membership-delegating, executable-privileged,
+  view-mediated-RLS-bypass, and owner-capable login sessions are outside the
+  application isolation guarantee.
 - Migrations must restore forced RLS within the same atomic SQL statement that
   relaxes owner enforcement, preserve legacy rows under `standalone`, remain
   idempotent, and keep the packaged and Docker initialization schemas