Unintended public API exposure due to export_all: what safeguards exist?

Accidental public API exposure due to export_all

In Erlang modules, the -export/1 clause defines the public API. Using -export_all can inadvertently expose internal helper functions, especially when combined with OTP behaviours that rely on exported callbacks. This can lead to unintended remote calls or misuse.

The community has documented that omitting functions from the export list prevents accidental exposure, but there is no built‑in role‑based control. OTP behaviours such as gen_server expect specific exported callbacks, yet they do not enforce minimal export beyond the required ones.

We need to understand what compile‑time or runtime mechanisms exist to detect or prevent accidental export of internal functions, and how to enforce stricter boundaries within OTP applications.

• Does the Erlang compiler provide a flag or warning to flag exported functions that are not referenced by any OTP behaviour or external module, helping catch accidental exports?
• Are there OTP behaviours or conventions that automatically restrict the export list to only the callbacks required by the behaviour, and can they be enforced programmatically?
• Beyond the export list, what patterns (e.g., private modules, internal modules, or process dictionary scoping) are recommended to prevent accidental public access of data or functions, and how can they be verified at compile time?