A Complete Guide to Credential Exposure: Causes & Prevention

One leaked key can open a cloud account, a production database or a customer support system. In 2025 alone, developers pushed 28.65 million new hardcoded secrets to public GitHub, a 34% jump in a single year (GitGuardian). This guide covers the credential types that matter, how they leak in 2026, and the steps that actually lower the risk.

✨ What is credential exposure?

Credential exposure is the unauthorized disclosure of anything that proves identity or grants access. That includes usernames and passwords, API keys, cloud access keys, OAuth and session tokens, SSH and private keys, database connection strings and CI/CD tokens.

Credentials come in two kinds. Human credentials belong to people and usually sit behind a login page. Machine credentials, also called non-human identities, belong to services, scripts, pipelines and AI agents. Machine credentials now far outnumber human ones, and they rarely have MFA in front of them.

Exposure is not the same as compromise, but the gap between the two keeps shrinking. A key pushed to a public repository or pasted into a shared Slack channel can be picked up by automated scanners or curious insiders long before anyone notices it is there.

Why credential exposure still matters in 2026

Stolen credentials remain the main way attackers move inside a company, even when they get in some other way.

• Credentials power most of the attack. In the 2026 Verizon DBIR, exploited vulnerabilities led initial access at 31%, and credential abuse fell to 13% as a first step. Across the full breach, though, credential abuse sits on top at 39%, and stolen credentials appear in 36% of all breaches (Flare).
• Leaks turn into ransomware fast. Half of ransomware victims who had a prior credential leak were hit within 95 days of that leak, often because infostealer logs were sold to access brokers (Help Net Security).
• Secrets in code keep growing. GitGuardian counted 28.65 million new hardcoded secrets on public GitHub in 2025. Keys for AI services grew 81% year over year, and researchers found 24,008 unique secrets in MCP configuration files, 2,117 of them still valid (AppSec Santa summary of GitGuardian data).
• Leaked keys stay live for years. More than 64% of credentials confirmed valid in 2022 still worked when retested in January 2026 (AppSec Santa).

The 2024 Snowflake campaign shows how this plays out. Attackers used credentials stolen by infostealer malware, some dating back to 2020, to reach about 165 customer environments. The accounts had no MFA, the passwords had never been rotated, and about 80% of the accounts used had prior credential exposure (SecurityWeek).

✨ Types of exposed credentials

The credentials below are the ones that show up most often in leaks. For a longer list of sensitive data types, see the Strac sensitive data catalog.

1. Cloud credentials

Cloud keys give direct access to infrastructure, so they are the first thing attackers search for. Cloud data loss prevention matters most here.

• AWS: access key IDs and secret access keys give access to services like EC2, S3 and RDS. AWS's own documentation uses the sample key ID AKIAIOSFODNN7EXAMPLE. Real keys follow the same AKIA pattern, which makes them easy for scanners to find.
• Google Cloud: service account JSON key files, OAuth client secrets and API keys. A service account key file contains a full private key, so one leaked file is enough to act as that service.
• Azure: client secrets, certificates and storage account keys tied to a tenant ID and client ID. A leaked client secret can give access to virtual machines, storage and Azure SQL.

2. Tokens and authorization headers

• OAuth access and refresh tokens: these give third-party apps limited access to accounts. Refresh tokens are the bigger risk because they can mint new access tokens for weeks or months.
• JSON Web Tokens (JWTs): signed tokens that carry identity claims. They are only encoded, not encrypted, so anyone who sees one can read it and replay it until it expires.
• Session cookies: infostealer malware grabs browser cookies so attackers can skip the password and MFA prompt entirely. This is one of the biggest changes since this guide was first written.

3. Cryptographic, SSH and RSA keys

Symmetric keys, such as AES keys, use one key to encrypt and decrypt, so the key itself must stay secret. Asymmetric keys, such as RSA and ECDSA, come in public and private pairs, and only the private half needs protecting. SSH private keys work like an ID badge for servers. A private key that lands in a repo, a ticket or a shared drive gives anyone who finds it the same access as its owner. Older algorithms like DES should no longer be used at all.

4. Database connection strings

A connection string bundles the username, password, host, port and database name into one line, for example postgresql://user:password@host:5432/dbname. That makes it convenient for developers and dangerous when it ends up in a log file, a Jira ticket or a Postgres dump shared for debugging.

5. Webhook URLs

Many webhook URLs carry a secret token inside the URL itself. Anyone with a Slack incoming webhook URL, for example, can post messages into that channel. Treat webhook URLs as secrets, not as plain links.

6. CI/CD tokens

Tokens for GitHub Actions, GitLab CI, Jenkins and CircleCI can build and deploy code, so a stolen one can push malicious code straight to production. CI systems also hold many other secrets as environment variables, which makes them a prime target.

7. AI service keys and MCP credentials

This category barely existed two years ago. API keys for OpenAI, Anthropic and other model providers are now one of the fastest-growing types of leaked secret. MCP (Model Context Protocol) servers add another layer: their config files often hold tokens for GitHub, Slack, databases and cloud accounts in plain text. Prompts sent to ChatGPT or Claude can also carry pasted keys. See MCP DLP for how to control what flows through MCP tool calls.

8. Passwords

Passwords are still the most common credential. Current NIST guidance favors long passphrases (at least 15 characters when a password is the only factor), checks against lists of breached passwords, and a password manager, rather than complex rules and forced changes.

9. Lower-risk identifiers

Some values look like secrets but carry less risk. They still deserve care.

• Publishable keys: payment providers issue keys meant for browsers, such as Stripe keys that start with pk_. They are safe to expose, but their secret counterparts (sk_) are not.
• Idempotency keys: these stop an API request from running twice. They are not secret on their own.
• UUIDs: a UUID for a public blog post or product page is harmless in a URL. A UUID that acts as the only lock on a private document or user account, such as an unguessable share link, works like a password and should be treated as one.

What causes credential exposure?

Most leaks are not clever attacks. They are secrets left in places people use every day.

1. Secrets in source code and config files

Developers hardcode keys to get something working and forget to take them out. Private repos are not safe either: GitGuardian found internal repositories are about six times more likely to contain hardcoded secrets than public ones (Superblocks summary). AI coding assistants make it worse. Commits written with AI help leaked secrets at about double the normal rate, 3.2% against a 1.5% baseline (GitGuardian data via Vibe Graveyard).

2. Secrets pasted into SaaS tools

Engineers share keys to unblock each other, support agents paste customer logins into tickets, and nobody cleans up afterwards. Common places to find live credentials include:

• Slack channels and DMs
• Jira tickets and Notion pages
• Zendesk and Intercom support conversations
• Gmail and Office 365 email
• Files in Google Drive, OneDrive and Box
• CRM records in Salesforce and HubSpot
• Application logs that print full request headers

These messages stay searchable for years, so one compromised Slack or Google account can expose every key ever shared there.

3. Secrets sent to AI tools and agents

People paste config files, stack traces and .env files into ChatGPT, Claude and other generative AI tools to get help debugging. AI agents connected through MCP can read and pass along tokens they find. Once a key leaves your environment in a prompt, you lose control of where it is stored.

4. Infostealer malware on endpoints

Infostealers pull saved passwords, session cookies and local files from browsers and laptops, often from personal or contractor devices used for work. The Snowflake campaign above ran almost entirely on infostealer logs. Plain-text keys sitting in .env files, shell history and notes apps on a Mac or Linux machine are easy pickings.

5. Password reuse and credential stuffing

When one site is breached, attackers try the same email and password everywhere else. The LinkedIn breach is a classic example: passwords stolen in 2012 resurfaced for sale in 2016, when more than 100 million account credentials were offered online and used against other services (Fortune).

6. Weak and default passwords

Default and guessable passwords still turn up in serious incidents. The 2017 Equifax breach started with an unpatched Apache Struts flaw. During the fallout, reporters also found that an Equifax employee portal in Argentina used "admin" as both its username and password (CNBC).

7. Poor storage of credentials

Storing passwords in plain text, using weak hashing, or logging secrets by accident all leave credentials readable to anyone who gets inside. In 2019, Facebook admitted that hundreds of millions of user passwords had been stored in plain text and were searchable by thousands of employees (KrebsOnSecurity).

8. Long-lived and over-privileged credentials

A key that never expires and can do everything turns a small leak into a full breach. Many machine credentials are created once, given broad permissions, and never rotated because nobody is sure what will break.

9. Third-party and OAuth integrations

Every app your team connects to Google Workspace, Microsoft 365 or Slack holds a token into your data. The 2026 DBIR found a third party involved in 48% of breaches (NHI Mgmt Group summary). Old integrations and AI apps nobody approved are common blind spots.

How to prevent credential exposure

Prevention comes down to three things: make credentials harder to steal, make stolen ones less useful, and find leaked ones before attackers do. Use the steps below alongside a DLP security checklist.

1. Use phishing-resistant MFA

MFA is still the single best defense against stolen passwords, but not all MFA is equal. The final NIST SP 800-63B-4 guidance lists SMS and phone-call codes as its only "restricted" authenticator, and it requires services at AAL2 to offer a phishing-resistant option (MojoAuth summary of NIST 800-63B-4).

• Move users to passkeys or FIDO2 security keys where you can.
• Use authenticator apps as a fallback, and SMS only as a last resort.
• Require MFA on every admin, cloud root and SaaS account, not just the main identity provider.
• Check it continuously. Strac Comply runs daily tests that flag users without 2-Step Verification in Google Workspace, Slack members without two-factor, and AWS root accounts with no MFA device.

2. Follow current password guidance

NIST no longer recommends forced password changes on a schedule. Rotate a password only when there is a sign it was exposed (Optro summary of NIST 800-63B Rev 4).

• Allow and encourage long passphrases.
• Block passwords that appear in known breach lists.
• Give every employee a company password manager.
• Store user passwords only as salted hashes using a modern algorithm such as Argon2 or bcrypt.

3. Keep secrets out of code

• Store secrets in a secrets manager such as AWS Secrets Manager, HashiCorp Vault or your cloud provider's equivalent.
• Turn on secret scanning and push protection in GitHub or GitLab so a key is blocked before it lands. Strac Comply checks that GitHub secret scanning is enabled on every repository.
• Add pre-commit hooks so developers catch keys on their own machine.
• Review code written with AI assistants with the same care as any other code.

4. Make credentials short-lived and narrow

• Replace long-lived cloud keys with short-lived tokens, for example OIDC federation for CI/CD pipelines instead of stored AWS keys.
• Give each key the smallest set of permissions it needs.
• Rotate machine keys on a set schedule. Strac Comply flags AWS IAM access keys older than 90 days, a control that maps to SOC 2, ISO 27001 and PCI DSS (see how it works).
• Keep an inventory of machine credentials and their owners, including keys used by AI agents and MCP servers.

5. Scan the places people paste secrets

You cannot stop every person from pasting a key into Slack. You can find it within seconds and redact it. Scan your SaaS apps, email, ticketing tools and file storage for API keys, tokens, private keys and connection strings, and remove old ones that have been sitting there for years. Do the same for prompts sent to AI tools through a browser DLP extension for Chrome or Edge.

6. Protect endpoints from infostealers

• Run endpoint protection that detects infostealer families.
• Do not let contractors sign in to company systems from personal devices.
• Turn off browser password saving for work accounts and use the company password manager instead.
• Scan laptops for secrets stored in plain-text files with endpoint DLP.

7. Limit where credentials can be used

A stolen password is less useful if it only works from known networks or managed devices. Use IP allowlists, device checks and conditional access for databases, data warehouses and admin consoles. The Snowflake victims had none of these in place.

8. Share credentials safely when you must

Sometimes a person really does need to hand a key to a vendor or a teammate. Never send it in chat or email. Use an encrypted link that expires, such as Strac's free secure send tool, and rotate the key once the job is done.

9. Have a plan for when a secret leaks

1. Revoke or rotate the credential right away. Deleting the message or commit is not enough.
2. Check access logs for any use of the key since it was exposed.
3. Search for other copies of the same secret across code, chat and tickets.
4. Record what happened and why, then fix the process that let it leak.

10. Do not rely on CAPTCHA alone

CAPTCHA once slowed down credential stuffing, but modern bots and solving services get past most of them. Pair it with rate limiting, breached-password checks at login, and alerts for logins from new devices or locations.

11. Train people and review access

Run regular security awareness training, review who has access to what every quarter, and remove access as soon as someone changes roles or leaves. Insiders, including contractors and partners, can expose credentials by accident or on purpose, so give everyone the least access they need.

🎥 How Strac helps prevent credential exposure

Strac finds secrets and other sensitive data wherever your team works, removes them before they spread, and gives you the evidence auditors ask for.

• Finds secrets in your SaaS apps. Strac scans Slack, Jira, Notion, Zendesk, Intercom, Gmail, Office 365, Google Drive, Salesforce and more for API keys, cloud keys, tokens, private keys and connection strings, alongside PII, PHI and card data. See all integrations.
• Redacts in real time. When someone pastes a key into a channel or ticket, Strac can redact it, block it, or alert the security team, so the secret never sits in search history.
• Cleans up the past. Data discovery and classification and DSPM scans find old secrets in files, buckets and messages that have been sitting there for years.
• Keeps secrets out of AI tools. Strac inspects prompts and uploads to ChatGPT, Claude and other generative AI apps through its browser extension, and blocks secrets in MCP tool calls with MCP DLP.
• Covers laptops. Endpoint DLP for macOS, Windows and Linux finds keys saved in plain-text files before an infostealer does.
• Masks data at the source. Data masking and tokenization keep real values out of logs, test databases and support tools.
• Turns controls into audit evidence. Strac Comply tests your stack every day for things like MFA enforcement, old IAM access keys and GitHub secret scanning, and maps each result to SOC 2, ISO 27001, PCI DSS and HIPAA controls. Frameworks like SOC 2 CC6.7 and ISO 27001 A.8.12 call for data leakage prevention by name, so Strac DLP counts directly toward them.

Strac connects without code and starts scanning in minutes. Book a demo to see it on your own Slack, Google Workspace or AI tools, or start a free Strac Comply trial.

Bottom line

Credential exposure is no longer mostly about weak passwords. In 2026, the bigger risk is the steady pile of keys, tokens and connection strings sitting in code, Slack threads, support tickets, AI prompts and laptops, many of them still valid years later.

You will not stop every leak, so plan for them. Put phishing-resistant MFA in front of every account, swap long-lived keys for short-lived ones, keep secrets in a vault instead of in code, and scan the tools where people paste things so a leaked key is caught in minutes, not months. When a secret does get out, revoke it first and ask questions later.

Strac handles the finding and redacting across your SaaS apps, AI tools and endpoints, and Strac Comply proves to auditors that those controls are running every day.

🌶️ Spicy FAQs on Credential Exposure

What is the difference between credential exposure and a data breach?

Exposure means a credential is somewhere it should not be. A breach means someone used it, or other weaknesses, to access data. Exposure is the warning sign. Catching it early is how you stop the breach.

Should we still make people change passwords every 90 days?

Not for user passwords. NIST now advises changing a password only when there is evidence it was exposed. Machine credentials are different: rotate them on a schedule, or better, replace them with short-lived tokens.

Is SMS-based MFA still acceptable?

It is far better than no MFA, but NIST classes it as restricted because codes can be intercepted or phished. Use passkeys or security keys for admins and sensitive systems, and plan to move everyone else off SMS over time.

What should we do first when a key leaks?

Revoke or rotate it immediately. Removing it from the repo or deleting the Slack message does not help, because copies and forks may already exist. Then check logs for any use of the key.

Can AI coding tools and agents leak credentials?

Yes. AI-assisted commits leak secrets at about twice the normal rate, and MCP config files often store tokens in plain text. Treat AI tools as another place secrets can end up, and scan them like any other app.