On day one, do four things: find the owner, find out what it can access, classify the risk, and pick one of keep, fix or retire. Do not delete first. Many unknown things turn out to support something a team relies on, and removing it blindly creates an outage you will be blamed for.
Step 1: find who it belongs to
Check where it came from before you ask around. Repository history shows who added it. The source host's audit log shows who installed an app or created a hook, within its retention window of 180 days. Cloud and identity consoles show who authorized an app. Then ask the team lead nearest to those names, and ask in a neutral way: "We found this, can you tell us what it does?"
If nobody claims it after a reasonable time, record that fact. An ownerless item is a finding on its own.
Step 2: find out what it can reach
Write down, in plain words:
- What data it can read or write.
- What credentials or tokens it holds.
- What network access it has.
- What it is connected to, such as repositories, chat or cloud accounts.
For a third-party app, its granted scopes tell you much of this. For a service, look at its runtime identity and its secrets. For an AI tool, ask what is sent to it. See how to find which AI services our code calls.
Step 3: classify the risk
| Access found | Urgency |
|---|---|
| Reads or writes production or regulated data | Same day |
| Holds credentials with write access | Same day |
| Reads source code only | Within the week |
| No sensitive access found | Add to the next review |
If you find exposed credentials, rotate them first. Rotation is reversible in most cases and stops the clock on a leak.
Step 4: keep, fix or retire
- Keep: add it to the approved list with an owner, version rule and review date. See what fields belong on an approved software list.
- Fix: keep it running but reduce access, pin versions, move secrets to a manager, and add monitoring.
- Retire: announce a date, switch it off in a reversible way first, such as disabling a hook or suspending a service, then delete after a quiet period.
Disable before you delete. A week of silence is useful evidence that nobody needed it.
Step 5: write it down
Record what you found, when, who owned it, what you decided and why. A short note is enough. Next time a similar item appears, the note shows how your team decides. If the case suggests an incident, such as unexpected access to sensitive data, bring in your incident process instead of treating it as housekeeping.
Then look for siblings
An unknown item rarely arrives alone. If it came from one team, check that team's other repositories. If it came from one tool, search for other places the same tool is used. See a one hour shadow dependency sweep runbook.
Quick check
Should we tell the person who set it up?
Yes, and kindly. Most unknown items were added to solve a real problem. Their answer shows you the need behind it.
When is it an incident?
When there is evidence of unexpected access to sensitive data or credentials in use by someone who should not have them. Escalate to your incident process then.
Safeguard offers asset discovery, policies and gates, and a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
