Materialized views and foreign tables are not readable through the API

Row-level security is not supported on materialized views or foreign tables, so neither can be protected by policies. A materialized view created in public is queried through the REST endpoint like any table, and by default anon and authenticated hold SELECT on it, so a cached aggregate or a snapshot of user data is readable by anyone and nothing in your RLS setup applies. A foreign table (a postgres_fdw or other wrapper to another database or an external API) exposes the remote data the same way, along with whatever credentials the wrapper uses. These objects feel internal ('just a reporting rollup') and AI tools place them in public because that is where the migration is already working. The advisor reports them as lints 0016 and 0017.

Keep these objects out of the API. Create them in a non-exposed schema, or revoke the API roles' access, and expose the data through a security_invoker view or a checked function when clients need it:

create materialized view private.daily_signups as
  select date_trunc('day', created_at) as day, count(*) from public.profiles group by 1;

-- or, if it must stay in public
revoke all on public.daily_signups from anon, authenticated;

For a foreign table, create it in a private schema (create foreign table private.remote_orders ...) and never grant it to anon or authenticated.