Search your internal wiki for "password" right now. Most companies that do this for the first time find something they did not expect: a database credential pasted into a setup guide three years ago, an API key in a runbook written during an outage, a shared login for a vendor tool sitting in a page titled "useful links."
Nobody put it there to be careless. Someone was writing down how to do something, under time pressure or simply trying to be helpful to the next person, and a credential was the fastest way to make the instructions actually work. It has been there since, searchable by anyone with read access, outside every control you built for secrets that live in code.
This post is about the credentials that live in prose instead of in your secrets manager. For whoever has access to the company wiki, which is usually everyone.
Why this is a different problem than secrets in code
Secret scanning on your repositories is now common, and for good reason: it catches a specific, well-understood pattern in a specific, well-understood location. A wiki page is neither. It is unstructured text, often exported from a different tool, frequently outside the scope of any scanner your security team configured, and read by a much larger audience than your codebase, because wikis exist specifically to be broadly readable.
That audience is the real issue. A credential in a private repository is visible to your engineering team. A credential on an internal wiki is often visible to the entire company, because internal documentation tools default to open rather than scoped, and restricting a space after the fact is friction nobody wants to introduce into a tool meant to encourage sharing.
Where it actually accumulates
Runbooks written during an incident. Under pressure, at speed, the priority is "does this work when the next person reads it at 3am," and a hardcoded connection string with the real password is a working instruction in a way a placeholder is not.
Onboarding guides. "Here is how to access the staging database" is exactly the kind of page that gets a real credential embedded, because the alternative, directing someone to a secrets manager they do not have access to yet, is friction for a document whose entire purpose is removing friction for a new person.
Meeting notes and decision records. A credential shared in a call, transcribed into notes because someone was taking minutes, now sits in a searchable archive with no access review of its own.
Vendor and integration setup pages. A third-party tool's API key, documented once when the integration was built, referenced by page title for years afterward by anyone who needs to touch that integration, because the page is easier to find than asking who owns the actual credential.
Exported chat threads and pasted screenshots. A screenshot of a terminal showing a successful login, pasted into a page to illustrate a working example, that happens to include the token used to authenticate.
Why standard secret scanning misses it
Scanners built for source code look for patterns in files with known extensions, in repositories they have been configured against. A wiki is usually none of these: it is HTML or a proprietary export format, served by a SaaS product your security tooling was never pointed at, and updated by people who are not engineers and were never asked to think about credential hygiene as part of writing documentation.
Some secret-scanning platforms now offer integrations for common wiki and documentation tools specifically because this gap is common enough to be worth building for. If yours does, turn it on. If it does not, this becomes a manual or scripted problem rather than an automated one, which is exactly why it tends not to get done.
What to actually do
Search for it directly, on a schedule. Most documentation platforms have an API. A scheduled job that searches for common secret patterns, the shape of an API key, a connection string, "password:" followed by something that is not a placeholder, and reports matches to a human, closes most of the gap without needing a dedicated product.
Treat any found credential as compromised, and rotate. The same rule as a secret found in git history: the exposure already happened, for however long the page existed, to however many people could read it. Deleting the page's content does not undo that.
Fix the underlying habit, not just the instance. Every runbook and setup guide should reference where to obtain a credential, not the credential itself: a secrets manager path, a named person to ask, a self-service request flow. This is more friction for the person writing the page and it is the only version that does not recreate the problem the next time someone documents a process.
Scope sensitive spaces properly. Not every internal document needs to be readable by the entire company. A wiki space specifically for infrastructure and access documentation, restricted to the people who actually need it, reduces both the audience for anything that slips through and the temptation to paste a working example because "everyone here already has access anyway."
Include documentation platforms in your data inventory. They hold operational knowledge about your systems, and increasingly they hold the keys to those systems too, whether or not anyone officially decided that should be true.
Check yours
# Search your wiki's own interface, or its API if you have one, for:
password
api_key OR apikey
secret
token
connection string patterns: "://" combined with "@"
Do this today, read every result rather than sampling, and rotate anything that turns out to be live. Most companies that run this search for the first time are surprised by what they find, and the surprise is reliably in the "we had no idea this was here" direction rather than "we already knew about all of these."
The concession
Perfectly disciplined documentation, referencing every credential by pointer rather than by value, adds real friction to the exact activity you want to encourage: people writing down how things work so the knowledge survives them leaving. A team that makes this too strict will simply document less, which has its own cost.
The proportionate response is the search, run regularly, rather than a policy nobody can enforce in the moment someone is writing under pressure. Catch it after the fact, cheaply and repeatedly, rather than trying to prevent every instance of the underlying human behaviour, which is not going to change no matter how the policy is worded.
The implication
Your secrets management programme almost certainly covers code, and it very likely has never been pointed at the tool where your team writes down, in plain language, how to access the systems that programme is meant to protect.
Run the search this week. The gap between "we have secret scanning" and "we have secret scanning everywhere a secret could plausibly be typed" is usually exactly this wide, and it is usually invisible until someone looks.
