An RPC is an exposed function, not a permission shortcut

First, build a mental model

Calling an RPC is entering a function through a public-facing door. EXECUTE decides who may enter; the execution context and downstream controls decide what the function may do.

1. SECURITY INVOKER uses the caller's privileges. SECURITY DEFINER uses the function owner's privileges and therefore requires deliberate review of authority and exposure.
2. Grant EXECUTE only to intended roles. PostgreSQL grants execute to PUBLIC for new functions by default unless default privileges are changed; make the intended exposure explicit.
3. A privileged function needs its own trusted actor, resource scope and input checks. Caller-supplied company IDs, hidden routes and 'the UI already checked' are not sufficient.
4. Constrain the search path and qualify object names in sensitive functions. Keep transaction boundaries, retry identity and direct invocation tests part of the design.

-- PostgreSQL / Supabase, illustrative notes schema.
CREATE FUNCTION public.rename_note(p_id uuid, p_title text)
RETURNS void LANGUAGE sql SECURITY INVOKER
SET search_path = '' AS $$
  UPDATE public.notes SET title = p_title WHERE id = p_id;
$$;
REVOKE ALL ON FUNCTION public.rename_note(uuid, text) FROM PUBLIC;
GRANT EXECUTE ON FUNCTION public.rename_note(uuid, text)
  TO authenticated;
-- Caller still needs table privileges and applicable RLS.

1. Entry

   The role needs EXECUTE on the particular function signature.

2. Context

   This invoker function runs with caller privileges; entering it does not manufacture table access.

3. Data boundary

   The UPDATE remains subject to its applicable privileges and row policies. The void sketch does not itself report whether a row changed.