External group access in SharePoint, explained

Most sharing findings name a person or a link. A group grant names neither: a file, folder, or list item is shared directly with a group — a Microsoft 365 group or a SharePoint group — and everyone in that group gets the access at once. If the group contains external members, that reach extends outside your organisation without a single sharing link or named guest sitting on the item.

What "shared with a group" means

When you grant access, the principal on an item's access list is usually a person. It can also be a group. A group grant is one access-control entry that expands to the group's whole membership: add someone to the group tomorrow and they can open the file today. The item shows a single grant; the reach is the size of the group.

• It's item-level, not site-level. This is a group written directly onto a file or folder's permissions — distinct from the access everyone gets simply by being a member of a team site (that path is covered in inherited guest access, explained).
• The group's membership is the audience. An internal-only group keeps the access internal. A group that includes external (guest) members extends the item's reach to those guests.
• One entry, many people. Reviewing the grant means reviewing the group — who is in it, and whether all of them should reach this item.

Why it's easy to miss

• No link to enumerate. Like a direct external grant, there is no sharing link involved — a link inventory won't show it.
• The membership lives elsewhere. The item shows "shared with Group X". Whether Group X contains outsiders is a separate lookup against the group, not something visible on the file itself.
• Default site groups bury it. Every SharePoint site has its own Owners/Members/Visitors groups; a raw permission dump lists those on almost every item, hiding the group grants that actually carry meaning.

How TRACER365 surfaces it

TRACER365 emits a group grant as its own finding type — shared with a group — for files, folders, and list items granted directly to a group. Severity varies: a benign internal-only group is LOW; a group carrying external members ranks higher. To keep the finding meaningful, a site's own standard Owners/Members/Visitors groups are filtered out as tautological noise — you see the group grants someone chose to add, not the scaffolding every site ships with. The group principal is tracked over time, so an added, removed, or re-levelled group grant shows up as a change rather than sinking back into the list.

The honest limitation

There is a real edge here, and house style is to name it. TRACER365 detects that an item is shared with a group, and classifies whether that group is external-only or an internal group that may contain external members. What it does not yet do is enumerate the individual external members inside a mixed group — telling you exactly which people inside the group are the external ones. Per-member externality inside a group is a v1.x improvement, not shipped today. So for a mixed internal group, TRACER365 tells you the group has access and that it may include outsiders — not precisely which members those are.

One more boundary: on Teams private and shared channel sites (the TEAMCHANNEL site templates), item-level group grants are deliberately not evaluated. Those sites govern access through channel membership rather than group grants, so flagging group grants there would be noise. Channel-aware handling is on the roadmap — we'd rather state that here than have you assume coverage that isn't shipped.

What to do about it

1. Review the group, not just the grant: is the whole membership meant to reach this item?
2. Watch groups with external members most closely — that is where a group grant becomes external exposure, alongside your other externally shared files.
3. Re-scan on a schedule — group membership changes silently, so a grant that was internal-only last quarter can gain an external member without anyone touching the file.