Decision software holds discussions, proposals, votes, membership, and subgroup relationships. Some of that information may be publicly readable by design. Other parts depend on a group's privacy and permissions. A title count can find candidate sites, but the security review has to inspect the group boundary.
The ZoomEye observations used sub_type=all, page 1, and pagesize 1. On 2026-11-02, app="Loomio" returned 0 and title="Loomio" returned 30. Both probes succeeded. The zero is a missing fingerprint match. The 30 titles are candidates, not a confirmed count of exposed private groups.
Privacy and action permissions are separate
Loomio documentation distinguishes group privacy from group permissions. A secret group does not appear in the public directory. For a non-secret group, administrators can allow non-members to start discussions. That non-member becomes a guest of that discussion without gaining access to other private discussions or group membership.
The permissions tab controls which ordinary members can invite people, send announcements, create subgroups, start discussions, manage tags, compose proposals, create polls, and manage templates. Permissions for non-members exist separately and depend on the group's privacy setting.
This is a useful review matrix. Do not ask only whether the group is public or secret. Ask which actions a guest can take, which actions a member can take, which subgroup inherits access, and what an administrator can moderate.
An API key follows its user
Loomio's API documentation says group operations use the memberships and permissions of the API-key user. A request for a group the key's user cannot access returns a permission error.
That makes service-account design important. A shared administrator API key can reach every group the administrator can reach. A key for a bot should belong to a dedicated user with only the memberships needed for its workflow. Record the key owner and remove the membership when the integration no longer needs it.
Recent release notes describe changes in API authorization and instance-administrator behavior. Version differences matter. Verify the release in use before assuming that a current permission fix or endpoint behavior applies to an older deployment.
Review the public entry path
Reduce the 30 title candidates with safe HTTP metadata. Distinguish a public group page, a login page, a documentation mirror, and an unrelated title. Do not attempt to join a group, vote, or retrieve private discussions.
For a confirmed deployment, inventory public groups, secret groups, subgroup structure, guest participation, member permissions, announcements, and API users. Check that a group showing a discussion to a guest does not expose the rest of its private discussions through a direct URL or API response.
Test permission changes with an authorized test identity. Remove a user from a group and confirm that an existing user API key no longer reaches the group's private topics and membership data. Review administrator moderation settings as high-impact configuration because they can change member-authored content.
The 30-title set is small. The security value comes from reading it as an invitation to inspect group boundaries, not as an exposure verdict. A publicly visible discussion can be legitimate. A private discussion, vote, membership record, or administrative setting reachable outside the group's permission model is not.