Before publishing an IAM lab, inspect the whole project for sensitive information—not just the screenshot you intend to share.
Credentials, tokens, personal details, and internal information can appear in configuration files, logs, browser tabs, filenames, and earlier commits.
Review these seven categories before making the repository public. A clean README is not evidence that the other files are safe, and deleting a leaked secret from the latest version does not make that secret safe to keep using.
1. Remove credentials and recover access safely if they leaked
Look for passwords, API keys, client secrets, private keys, recovery codes, and credentials stored in scripts or environment files.
If a real secret has already been exposed, deleting it from the current file is not enough. Revoke or rotate it through the appropriate process.
GitHub's sensitive-data guidance makes that distinction and explains why repository history, forks, and other copies complicate cleanup.
Do not publish a working credential merely because the account belongs to a lab.
2. Remove live tokens and session material
Authentication traces can contain access tokens, refresh tokens, cookies, or other session information.
A trace may look like an educational collection of headers while still containing material that could grant access. Do not paste it into a public decoder or repository to make the project easier to inspect.
Use deliberately synthetic examples or carefully prepared non-sensitive summaries. Explain the fields that matter without including a usable credential.
The difference between understanding tokens and exposing them is an important part of learning identity safely.
3. Replace real-user information with fictional identities
Inspect more than the central panel of a screenshot.
Check:
- Identity details: Names, email addresses, phone numbers, profile images, and account identifiers.
- Screen edges: Browser tabs, notification banners, sidebars, and background windows.
- Files: Names and paths that disclose a person or organization.
- Repeated appearances: The same identity in logs, diagrams, exports, or other screenshots.
Using fictional people from the beginning is safer than trying to redact every occurrence afterward.
Keep only what the reader needs to understand the test. A public demonstration can show an account's role in an access decision without exposing a real person's details.
If the material came from work, fictionalizing a visible name does not itself grant permission to publish the underlying record. Check authorization and remove material you are not permitted to share.
4. Remove employer and customer material
Do not publish internal tickets, diagrams, configurations, procedures, or customer details without authorization.
Replacing a company name does not automatically make an internal artifact appropriate for public use. The design or surrounding information may still be confidential.
For a personal portfolio, rebuild the general concept with fictional data and independently created material. Label it as a lab rather than presenting it as a redacted customer engagement.
Respecting that boundary is evidence of judgment, not a weakness in the portfolio.
5. Remove unnecessary infrastructure exposure
Review hostnames, public addresses, tenant identifiers, internal paths, device names, and access URLs.
Not every identifier is a secret. The question is whether publishing it is necessary and appropriate for the explanation. Remove unnecessary details that reveal how to reach or map your environment.
A diagram can show “test identity provider” and “sample application” without including every live endpoint.
Keep the technical relationship clear while limiting information that does not help the reader evaluate your work.
6. Remove raw exports and hidden supporting files
Check archives, backups, editor files, notebooks, logs, and generated reports before adding them to the repository.
A sanitized summary can accidentally sit beside the original unredacted export. Review the actual files included in the publication, not only the ones linked from the README.
Use an explicit allowlist of intended public artifacts when practical. A small, deliberate publication set is easier to inspect than an entire working directory copied wholesale.
7. Remove sensitive content from the publication history
Inspect commits and branches, not just the latest version.
Changing a repository to private or deleting a current file does not recall copies already obtained by others. Follow the platform's documented cleanup process when exposure has occurred, and address the credential risk first.
After the review, open the public-facing project while signed out and inspect what a stranger can actually see.
The Six-Figure IAM Career Playbook includes practical labs and portfolio guidance for a career move. The $9 guide is meant to help you show relevant capability. A safe publication should demonstrate that capability without giving away access, personal information, or someone else's confidential work.