Ran into this during a security review for a client and wanted to share it with the architect community, since it's the kind of thing that quietly fails least-privilege audits.
The ask was simple: a service account needs to run a read-only Tooling API query against InstalledSubscriberPackage, just to report which managed packages/versions are installed. No install, no uninstall, just read.
Turns out the only permission that grants access to that object is "Download AppExchange Packages" — which also grants install and uninstall rights for AppExchange packages org-wide. There's no granular read-only alternative. Confirmed this directly with Salesforce Support (Case 474178877): that permission is currently the only path to query InstalledSubscriberPackage.
For anyone doing security reviews on integration users, this is worth knowing: if you see "Download AppExchange Packages" assigned to a service account, don't assume it's just for reporting — it's also an install/uninstall grant. Best mitigation right now:
- Assign via a dedicated Permission Set scoped to only that service account, never on a profile
- Base the account on Minimum Access - API Only Integrations
- Document it as a known least-privilege exception, since it isn't a true fix
Filed an idea to get a proper read-only permission added:
https://ideas.salesforce.com/s/idea/a0BHp000017JmFfMAK/granular-readonly-permission-to-query-installedsubscriberpackage
If you've hit this same wall on a client integration or audit, an upvote helps get it prioritized. Curious if others have found a cleaner workaround than permission-set scoping.