Open a file's sharing panel and it looks clean — no links, no guests. And yet an external person can open it. That's inherited guest access: the file never got shared, but something above it did. It is the single most under-audited exposure in SharePoint, and the reason naive sharing reports are simultaneously overwhelming and incomplete.
How inheritance works — in one paragraph
Every item in SharePoint inherits permissions from its parent unless someone breaks the chain: files inherit from folders, folders from libraries, libraries from sites. Grant a guest access to a folder, and every file inside it — including files added years later — is reachable by that guest. The individual files show no sharing of their own, because they have none: the access lives on the parent.
Why it's the audit's hardest problem
- Item-level checks miss it. "Does this file have a sharing link or a guest permission?" answers no. The exposure is real anyway.
- Raw dumps drown it. A permissions walk that expands inheritance lists the guest on every descendant item — one folder share becomes hundreds of identical rows. Reviewers stop reading; the one row that matters (the grant itself) looks exactly like the noise.
- Group membership adds a second indirection. A guest inside a Microsoft 365 group has access to everything the group's site holds — the "share" is a membership, not a permission on any item.
- Broken inheritance hides pockets. Items with unique permissions stop inheriting cleanups from above: fix the parent, and the broken-off child keeps its old access.
How TRACER365 audits it
TRACER365 resolves the effective permission chain for every item and emits inherited guest access as its own HIGH-severity finding type — the file a guest can reach, tied to the parent grant that causes it. Then the cascade de-duplication does the part no raw report does: all descendant findings with the same cause collapse under the single parent finding. You review the folder grant once; the hundreds of children are attached to it, not scattered through your list. In our testing, roughly 91% of raw findings collapsed as duplicates — most of them exactly this pattern.
- Guests reaching sites through Microsoft 365 group membership are surfaced the same way — membership-based access is treated as the exposure it is.
- Broken inheritance is flagged as its own governance finding, so the pockets that stopped inheriting your fixes are visible.
- The finding resolves itself when the chain is broken or the parent grant is removed — verified by a later scan, recorded in the history.
One honest limitation: a guest whose access arrives through a group nested inside another Microsoft 365 group is not yet enumerated at site level — a known edge on the roadmap. We'd rather tell you that here than have you discover it in an audit.
What to do about it
- Inventory inherited exposure — not just direct external grants (the complete how-to).
- Review causes, not symptoms: fix the folder grant, and its hundreds of inherited rows go with it.
- Re-scan on a schedule — inheritance means new files join existing exposures silently.