Enforce user permissions / RLS in scheduled (email) reports

What is the problem or goal you're trying to solve or accomplish?

The customer expects scheduled/email reports to respect the same permissions and RLS that apply in the dashboard UI. Today, reports execute under a single server-side execution identity rather than the intended user's scope, so recipients can receive content beyond their intended access — including external recipients seeing data they shouldn't. The goal is for admins to (a) control which account a report is executed as, and (b) restrict who reports can be sent to, so reports can't leak data outside their intended audience.

How are you solving it currently?

No native mechanism exists. The customer restricts the risk manually — building audience-specific reports on already-scoped dashboards/datasets and limiting recipients — but there is no enforcement preventing a report from rendering with broader access than a recipient should have.

What is your recommended solution?

Reports should honor the same permissions/RLS as the UI. This is being addressed upstream via an approved improvement (SIP-209, https://github.com/apache/superset/issues/39642), which introduces a per-report "Run As" field to control the execution identity (and prevents non-admins from escalating access), plus admin controls to limit recipients to existing users and to allowed email domains. No committed timeline yet.