Remove shared links
Revoke links in bulk
Scan the libraries you choose, review every sharing link found, then revoke them. This is the answer to an audit finding that anonymous links exist on content that should never have left the building. It is not reversible, so it sits behind a count-bearing confirmation and a write-ahead log.
What it does
- Every link in scope, with its type, scope and who it reaches, before any of it is revoked.
- How many links you are about to destroy, stated in the confirmation.
- What was actually revoked, per link, in a report kept for 90 days.
How it runs
- Sign in and choose what to scan. Sites or libraries.
- Narrow it down. Filter by link scope, link type, name, or to expired links only, before the scan. These filters are the only way to narrow the run: revoking every link in a tenant is rarely what anyone wants.
- Review the findings. Per link. There is no per-row selection: the removal acts on every link the scan found.
- Confirm, then it runs. The confirmation carries the count. A write-ahead log records each revocation before it happens. Cancel offers Finish the current item, Stop now, or Keep running. Nothing is left half-written: an item is either done or not started.
How it works
The scan reads every file and folder in the chosen libraries. Name and item-type filters are applied first; each item that passes then has its permissions read, and the sharing links that match the link scope, link type and expired-only filters are kept. Only links made on the item itself are listed, so a link that belongs to a parent folder is never matched on the items below it. People and groups granted access directly, rather than through a link, are never listed or touched by this tool.
Revoke acts on every link the scan listed, so the filters, set before the scan, are how the set is narrowed. For each link, its address, type, scope, roles, recipients, expiry and whether it had a password are written to a run log on this computer and flushed to disk before the link is revoked. Revoking deletes the link itself: everyone who reached the item through it loses that access at once, and the link cannot be brought back. The run log is the only record of what it was; a link made again from that detail is a new link.
If a revoke fails, the item's permissions are read again. A link that has already gone is recorded as already gone, not as a failure; otherwise the error is recorded and the run moves on to the next link. A link on an item that could not be addressed as a file is counted as failed with that reason, never left out of the count.
A Stop, a lost sign-in, or the run log failing to write ends the run before the next link, and links already revoked stay revoked and are in the report. A browser session sign-in cannot read sharing links, so on that sign-in each library says so instead of reporting none; if the sign-in is refused on item after item, link reads stop and the report says why. The report goes into Report History and the run into the tool's History.
What you need
- Write access to the libraries in scope.
- A Graph token. A cookie-only sign-in cannot drive this.
What it will not do
- A revoked link cannot be restored. Anyone relying on it loses access the moment it goes, with no notification from SharePoint.
- Filter first. Report shared links, on the Reports menu, is the read-only version and the sensible first step.
- Removing a link does not change permissions granted any other way.