When an API key is exposed, an attacker can use it immediately to access systems, extract data, run up costs, or move laterally through connected services. Most exposed keys are discovered by automated scanners within minutes of going public. The average cost of a single incident tied to an exposed API key is $650,000. In 2024, GitHub detected over 39 million leaked secrets on its platform. Seventy percent of credentials leaked in 2022 are still active today. The damage is not theoretical. It is financial, operational, and often regulatory.
What an API Key Actually Is
An API key is a credential. It is a string of characters that identifies and authenticates an application or user when making requests to an external service or system. It works like a password. The service on the other end sees the key, confirms it is valid, and allows the request to proceed.
API keys grant access to databases, payment systems, cloud infrastructure, messaging services, AI platforms, third-party data feeds, and internal tools. In most environments, a single key can read, write, modify, or delete records depending on the permissions attached to it.
The difference between an API key and a username-password combination is that API keys are often embedded directly in code, configuration files, environment variables, or build scripts. This makes them convenient. It also makes them easy to lose track of.
When a key leaks, the organisation that issued it does not automatically know. The attacker does not announce themselves. They simply begin using the key.
How API Keys Get Exposed
Understanding how exposure happens is the first step toward preventing it. The causes fall into a small number of recurring patterns.
1. Committed to a public code repository
This is the most common cause. A developer writes code locally with an API key hardcoded for testing. They push to GitHub, GitLab, or Bitbucket without removing the key. The repository is public. Within minutes, automated scanners pick it up.
GitGuardian's 2026 State of Secrets Sprawl report found that 28.65 million new hardcoded secrets were added to public GitHub repositories in 2025 alone, a 34% increase over the prior year. GitHub's own security data for 2024 counted 39 million secret leaks across its platform. This is not a niche problem affecting a handful of careless developers. It is an industry-wide pattern at scale.
2. Left in collaboration tools
GitGuardian's 2025 research expanded beyond code repositories and found that 2.4% of corporate Slack channels contained leaked secrets. More significantly, 6.1% of Jira tickets exposed credentials, making Jira the most vulnerable collaboration tool in the analysis. Developers paste keys into support tickets, internal messages, and documentation without considering who else might have access now or in the future.
3. Exposed in public Postman workspaces
In December 2024, researchers identified 30,000 publicly accessible Postman workspaces where developers had saved production secrets including live API keys, access tokens, and in some cases sensitive healthcare records. These workspaces were visible to anyone with the URL.
4. Stored in Docker images
GitGuardian's scan of DockerHub images found credentials embedded in public container images. A developer builds an image with a key included, pushes it to a public registry, and it is available for anyone to pull and inspect.
5. In private repositories that are not as private as assumed
Many organisations believe private repositories are safe. GitGuardian's data found that 35% of customers' private repositories contain plaintext secrets. AWS IAM keys appear five times more frequently in private repositories than in public ones. Private does not mean secure, especially with access management gaps, contractor access, or misconfigured permissions.
6. Through CI/CD pipelines and build logs
Build pipelines that print environment variables to logs, or pipelines misconfigured to expose secrets in outputs, create another common exposure path. These logs are often stored in systems with broader access than the secrets themselves.
What Happens After a Key Is Exposed: The Attacker's Perspective
When a key is published publicly, the window before it is discovered and used is often measured in minutes, not hours.
Automated credential harvesting tools continuously scan public GitHub commits, DockerHub images, paste sites, and developer forums. These tools operate at scale. They are not waiting for a human to stumble across your key. They are scanning millions of commits per day looking for patterns that match known API key formats.
Once a valid key is captured, the attacker's next steps depend on which service the key accesses.
Cloud infrastructure keys (AWS, GCP, Azure)
With a cloud provider key that carries broad permissions, an attacker can provision new instances, spin up compute resources, exfiltrate data from storage buckets, create new IAM users to maintain persistent access, and delete or encrypt data. Cloud bills can reach tens of thousands of dollars in hours. The financial damage comes from both the attack itself and the compute costs the attacker runs on the victim's account.
Payment and financial service keys (Stripe, PayPal, Braintree)
A Stripe API key with write permissions can be used to issue refunds, create charges, access customer payment data, or redirect funds. Financial services face API-related fraud losses exceeding $4 billion annually according to SQ Magazine's 2026 API Security Breach Statistics analysis.
AI and LLM platform keys
On July 13, 2025, a private API key for xAI's language models was accidentally published on GitHub by a developer at Elon Musk's Department of Government Efficiency. The key was embedded in a script called agent.py and granted access to more than 50 xAI large language models. The exposure was not detected internally. It was flagged by GitGuardian, which monitors public repositories for leaked credentials. Security researchers confirmed the key could be used to send requests and retrieve data without any additional authentication.
Authentication platform keys
In 2024, the United States Treasury Department was breached. The breach was traced to a single leaked API key for BeyondTrust's authentication platform. Attackers bypassed millions of dollars in security infrastructure simply by using an exposed credential. As GitGuardian CEO Eric Fourrier noted, attackers exploiting leaked secrets do not need advanced skills. They need one valid credential.
Database and SaaS integration keys
A key connected to a customer database can return full records including personally identifiable information, financial data, or health records. A key connected to a CRM or email platform can export contact lists, send mass communications, or delete records. The permissions model attached to the key determines the blast radius.
The persistence problem
Seventy percent of secrets leaked in 2022 are still active today according to GitGuardian's 2025 research. This means an attacker who finds an old, forgotten credential in a repository that has since been updated or archived can still use it. The code may be stale. The key is not. Most teams revoke keys only after discovering a breach. Proactive rotation is rare.
The Financial and Regulatory Cost
The cost of an exposed API key is not limited to what an attacker extracts. It includes the full incident response, investigation, remediation, legal exposure, and reputational impact.
The average cost of a single incident directly linked to an exposed API key is $650,000, according to TRaViS's analysis of real-world breaches. Across the broader API security space, the average API breach costs $591,000 per event, rising to $832,800 in financial services, according to DreamFactory's 2026 enterprise API security statistics report. IBM's 2024 Cost of a Data Breach Report put the global average data breach cost at $4.88 million when factoring in all consequences.
The regulatory dimension adds a separate layer of exposure. If an API key breach results in unauthorised access to personal data, the organisation may be subject to:
GDPR notifications and potential fines if EU resident data is involved
HIPAA reporting and penalties if protected health information is accessed
PCI DSS consequences if payment card data is reachable through the key
SEC disclosure obligations for publicly traded companies if the breach is material
Sector-specific regulatory investigations in financial services, healthcare, or government
Healthcare breaches involving APIs increased by over 25% year over year driven by digital transformation, according to SQ Magazine. Fintech startups experience API-related threats in nearly 50% of incidents. Public sector organisations reported API attacks increasing by over 30% in 2025.
Beyond direct cost, 84% of companies faced at least one API incident annually in 2025. Ninety-nine percent of organisations faced API security problems. Only 10% had a posture governance strategy in place to address them.
Real Incidents Worth Knowing
A handful of recent, documented incidents illustrate how this plays out in practice.
US Treasury Department, 2024
A leaked API key for BeyondTrust's authentication platform gave attackers access to Treasury Department systems. The credential bypassed the organisation's existing security investments. The breach was investigated at the federal level and highlighted the risk of third-party API credential management.
xAI API Key on GitHub, July 2025
A developer working for the Department of Government Efficiency committed a Python script to a public GitHub repository with a live xAI API key embedded in the code. The key granted access to more than 50 large language models. GitGuardian's automated scanner detected it. The incident was publicly reported before internal teams identified the exposure.
Postman Workspace Exposure, December 2024
Researchers found 30,000 publicly accessible Postman workspaces containing production API keys, access tokens, and sensitive records. These were not breaches in the traditional sense. The data was simply left where anyone could find it, through a misconfigured sharing setting.
GitHub March 2024
A scan of public GitHub repositories revealed nearly 13 million API secrets exposed and accessible. The findings included keys for major cloud providers, payment processors, and communication platforms.
US Retail API Breach, 2025
A poorly secured API integration at a retail organisation exposed the payment data of over 5 million customers. The breach occurred through an endpoint that lacked basic authentication controls and had been live, unmonitored, for an extended period.
What Attackers Look for After Getting In
Once an attacker has a working API key, their behaviour depends on their goal. Most follow a predictable path.
Reconnaissance first. They call read-only endpoints to understand what the key can access. How many records are there? What data types are available? What services is this key connected to? This phase is quiet and generates logs that look like normal usage.
Data extraction. If the key accesses a database or storage system, they export records. Customer data, internal documents, financial records, user credentials, and health information are all high-value targets.
Credential pivoting. An API key connected to one service often has configuration data nearby that points to other services. Attackers use initial access to find secondary credentials. AWS keys frequently lead to additional services within the same environment.
Persistent access. If the key allows creating new credentials, attackers create secondary access points before revoking the original would block them. This is why revoking a known-exposed key is necessary but not always sufficient.
Monetisation or extortion. Data is sold, ransomed, or used in downstream attacks. In some cases attackers establish a persistent presence and sell ongoing access to others.
The 2025 API security data shows that 95% of API attacks come from authenticated sessions. Traditional perimeter security does not catch this. From the infrastructure's perspective, the attacker looks like a legitimate user.
What to Do Immediately If You Discover an Exposed Key
Speed matters. The faster you act, the less damage occurs.
1. Revoke the key immediately
Do not investigate first. Revoke first. Every minute a key is active after you discover the exposure is time an attacker can use it. Revocation takes seconds. Investigation takes hours.
2. Check access logs for the key
After revoking, pull the full access log for that key. Look for requests that do not match normal usage patterns, unusual times, unexpected IP addresses, bulk data requests, or calls to endpoints that are not part of your standard integration. This tells you whether the key was used and what was accessed.
3. Assess the permissions
Understand exactly what that key could do. This determines the scope of potential impact and drives your notification and remediation decisions.
4. Scan for secondary exposure
The leaked key may have been in a commit alongside other credentials. Check the same file, the same commit, and the same repository for any additional secrets that were exposed at the same time.
5. Notify affected parties if required
If there is evidence of data access, your legal and compliance obligations begin. Understand your notification timelines under applicable regulations and begin that process in parallel with technical remediation.
6. Issue a new key with the correct scope
When replacing the key, audit the permissions. Most API keys are over-permissioned. Replace the exposed key with one that carries only the permissions the integration actually needs.
7. Document and run a post-mortem
Record how the key was exposed, how it was detected, what happened between exposure and detection, and what control failed. Use this to improve your secrets management process. One incident properly analysed prevents several future ones.
How to Prevent API Key Exposure
Prevention is far cheaper than remediation. These are the controls that actually reduce risk.
Use environment variables, not hardcoded values. API keys should never appear in source code. They belong in environment variables or secrets managers, injected at runtime by the infrastructure.
Use a secrets manager. Tools like AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, and Azure Key Vault store credentials centrally, control access, audit usage, and support automated rotation. These exist precisely to address the secrets sprawl problem.
Enable secret scanning in your repositories. GitHub's native secret scanning, combined with tools like GitGuardian or Gitleaks running in CI/CD, catches exposed credentials before they reach the main branch or go public. GitGuardian scans 1.4 billion commits annually.
Apply least-privilege permissions. Every API key should carry only the permissions required for its specific function. A key used for read-only reporting should not have write access. Narrow the scope of every credential you issue.
Rotate keys regularly and automatically. Automated rotation means that even if a key is exposed, it has a shorter validity window. Most teams rotate only when a breach is suspected. Regular automated rotation removes the dependency on breach detection.
Audit your repository history. A commit containing a key that was immediately removed from the code still exists in the git history. Rotate any credential that has ever appeared in a commit, regardless of whether it was subsequently deleted.
Review your Postman, Jira, and Slack environments. GitGuardian's 2025 data shows that 6.1% of Jira tickets expose credentials. Collaboration tools are an underappreciated vector. Include them in your secrets management scope.
Remove zombie keys. Identify all API keys in use across your organisation. Revoke any that are no longer actively needed. Unused credentials with valid permissions are a liability with no corresponding benefit.
The Scale of the Problem in 2026
The numbers heading into 2026 describe a problem that is getting worse, not better.
GitGuardian's 2026 State of Secrets Sprawl report found 28.65 million new hardcoded secrets added to public GitHub repositories in 2025, a 34% increase over the prior year. An academic study published at IEEE Security and Privacy 2025 analysed over 80 million files and found that up to 30% of projects are at risk of credential exposure.
Forty-seven percent of API endpoints remain exposed for more than six months without being detected. This means an attacker who finds a key in January may still be using it in July while the owning organisation has no visibility into the access.
Most security investment in this area goes toward detection. The harder problem is remediation speed and the structural conditions that allow credentials to remain valid long after exposure. The average exposed secret identified in 2022 is still usable today. That is the actual gap: not finding the leak, but closing it permanently and quickly.
The trend is clear. APIs are everywhere. Credentials are being created faster than they are being managed. The tools to find and exploit them are automated and freely available. And the majority of organisations still lack a formal governance strategy for the credentials they issue.
Frequently Asked Questions
How quickly can an exposed API key be found by attackers? Automated scanning tools monitor public GitHub commits, paste sites, and developer forums continuously. Research from GitGuardian and others indicates that valid credentials are often identified within minutes of being published publicly.
Can you tell if your API key has been used without your knowledge? Yes, if you have access logs enabled for the service the key connects to. Most cloud providers and API platforms log all requests with timestamps, IP addresses, and endpoints called. Reviewing this log after revoking an exposed key shows whether it was accessed and what was done.
Is revoking the key enough? Revoking stops future use of that specific key. It does not undo any data that was already accessed or exported. It also does not address secondary credentials an attacker may have created using the initial access. Revocation is the first step, not the complete response.
Why do so many leaked keys stay active for months or years? GitGuardian's research found that 70% of secrets leaked in 2022 remain valid today. This happens because most teams rotate keys reactively rather than proactively, and because removing a key from code does not invalidate the credential itself. Rotation must happen at the source, with the issuing service.
What is secrets sprawl? Secrets sprawl refers to the uncontrolled spread of credentials such as API keys, passwords, and tokens across code repositories, collaboration tools, build systems, and documentation. GitGuardian's 2026 report found 28.65 million new hardcoded secrets on public GitHub in 2025 alone. It is one of the most significant and underaddressed risks in modern software development.
Conclusion
An exposed API key is not a minor housekeeping issue. It is an open door. The attacker on the other side does not need skill, specialised tools, or insider knowledge. They need the credential, and tools are already scanning for it.
The scale of the problem in 2026 is significant. Nearly 29 million new secrets were leaked on public GitHub in 2025. Seventy percent of older leaked credentials are still active. The average incident costs $650,000. And only 10% of organisations have a governance strategy covering how their API credentials are issued, managed, and rotated.
The technical controls that address this are well understood. Secrets managers, automated scanning, least-privilege permissions, and regular rotation are not new ideas. The gap is implementation and consistency.
Every API key your organisation issues is an access point. Know where they are, what they can do, who has them, and how quickly you could revoke any one of them if needed. That is the standard every team handling sensitive systems should be working toward.
At Ascella Group, we help engineering and security teams build the practices, tooling, and governance structures that keep credentials under control. If your organisation is unsure about the state of its API credential management, that uncertainty is itself a risk worth addressing.