Credential Network Allow-List Planner
A leaked key is only dangerous where it works. Pick the platforms that issue credentials you rely on, say whether the callers run from fixed addresses, and get a ranked plan for restricting those credentials to networks you trust, with the lockout risks and a rollout order that keeps you from locking yourself out. Everything runs in your browser.
Which platforms issue credentials you rely on?
Tick a platform, then answer three short questions about it.
Long-lived IAM user access keys, and role credentials that are copied out of the environment they were issued for.
Service account keys (JSON files) and OAuth tokens held by automation.
Personal access tokens, OAuth app tokens and deploy keys.
API tokens created by administrators, and OAuth client credentials for service apps.
App registration client secrets and certificates, refresh tokens, and service principal credentials.
Connected app consumer secrets, OAuth refresh tokens and integration user credentials.
Bot and user OAuth tokens, and legacy or app-level tokens.
API keys for model providers and AI developer platforms, often shared across teams and pasted into notebooks and CI.
Deploy tokens and cloud keys stored as pipeline secrets.
TL;DRWhat this tool is
5 points
- Tick the platforms that issue credentials you depend on (AWS, Google Cloud, GitHub, Okta, Microsoft Entra, Salesforce, Slack, AI platforms, CI/CD) and answer three questions about each.
- You get a ranked rollout plan, the mechanism each platform offers for restricting a credential to trusted networks, how sure this page is that the mechanism exists, and the lockout risk.
- Every mechanism carries a confidence label. Where the page is unsure, it says "verify in vendor docs" and does not name a setting.
- The rollout order is always the same: find the callers, test the break-glass path, run in monitor or report-only form, then enforce one scope at a time.
- Runs entirely in your browser. Nothing is uploaded and no account is touched.
Lock down the whole stack, not one door
In his retrospective on a run of breaches at companies that support developers and infrastructure, magoo describes attackers collecting many customers' long-lived credentials (GitHub personal access tokens, long-lived AWS keys, AI platform keys) in a hub-and-spoke pattern. These are his observations: that roughly 90% of the credentials leaked first belonged to apps that could have used a network allow-list, and that the stolen credentials were used from remote, unfamiliar networks.
His first direction is a full-stack network lockdown: the origins, the network or security groups, and the IAM and authentication layers all respecting the same policy, with credentials restricted for AWS, Google Cloud, GitHub, Okta, Microsoft, Salesforce and Slack. This planner turns that into a per-platform worklist. It is deliberately cautious about what each platform supports, because a plan built on a setting that does not exist is worse than no plan.
Sources
- magoo, “Black October: Lessons From the Downstream Breaches”, Starting Up Security, Oct 2026. The author's observations are attributed to him throughout this page.
- Vendor documentation for each platform. Confirm every setting there before you rely on it.
Frequently asked questions
Why restrict a credential to a network at all?
A stolen long-lived key works from anywhere unless something checks where the call comes from. In "Black October: Lessons From the Downstream Breaches", magoo (Starting Up Security, Oct 2026) reports his own observation that about 90% of the credentials leaked first belonged to apps that could have used a network allow-list, and that the stolen credentials were used from remote, unfamiliar networks. That is one practitioner's observation, not a universal figure. The practical point stands: a credential that only works from your own addresses is much less useful to someone who stole it.
Will an allow-list stop every stolen credential?
No. An attacker who lands inside an allowed network, or on a runner or laptop that is on the list, can still use the credential. An allow-list narrows where the key works; it does not replace removing long-lived keys, scoping them down and logging their use.
What if I cannot tell where my callers run?
Then discovery is the first step. Use the platform's own logs (for example AWS CloudTrail source addresses, or sign-in and audit logs elsewhere) to see where each credential is actually used from. The planner puts such platforms in "Discover callers first" rather than telling you to enforce.
How do I avoid locking myself out?
Test a break-glass path before enforcing anything, use monitor or report-only modes where the platform has them, and enforce on one low-risk scope first. Keep at least one emergency account or role that is exempt, protected with strong authentication, and alerted on.
Are the settings on this page guaranteed to exist on my plan?
No. Vendors change features and tie some to licences. Each mechanism is labelled documented, plan-dependent or verify. Treat the page as a map of what to look for, then confirm the exact setting in the vendor's current documentation.
More security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.