TL;DR: API sprawl is leaving hidden endpoints, inconsistent controls, and compliance risk across cloud-native environments, according to Salt. API estates need continuous lifecycle control, because discovery alone cannot govern access paths, retired endpoints, or active credentials.
Editorial analysis by NHI Mgmt Group, based on content published by Salt: “API Sprawl: The Quiet Rise of the ‘API Tsunami’”.
By the numbers:
- Over 63% of organisations experienced security incidents due to unmonitored or inadequately secured APIs in 2024.
Key questions
Q: Why do unmanaged APIs increase identity and access risk?
A: Because APIs are often accessed by service accounts, tokens, and application credentials that never pass through the same review discipline as human users.
Q: What are the signs that API governance is failing at runtime?
A: Common signs include undocumented endpoints, duplicated ownership, inconsistent responses, rising retry loops, and frequent discovery of APIs that are not in the catalogue.
Q: What breaks when API sprawl is not controlled centrally?
A: When API sprawl is unmanaged, teams lose visibility into where data flows, which credentials remain active, and which endpoints are still live.
Practitioner guidance
- Implement continuous API discovery Continuously scan cloud, SaaS, and internal environments for undocumented APIs, then compare them with the authoritative service inventory so shadow endpoints can be investigated quickly.
- Standardise authentication and authorisation Require one baseline for API authentication, token handling, encryption, and access control across all teams so older endpoints do not retain weaker policies than current services.
- Tie APIs to explicit owners Assign a named owner for every API, including partner and internal interfaces, so review, incident response, and retirement decisions always have an accountable team.
Bottom line: API sprawl creates unmanaged access paths that can outlive the systems and teams that created them.
Glossary terms: API sprawl, Shadow API, Zombie API, API Lifecycle Governance
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
API sprawl is now an identity governance problem as much as a security architecture problem. When every team can create, keep, and modify API access paths independently, the organisation loses lifecycle control over machine-facing entry points. That matters because API keys, tokens, and service credentials often outlive the business need that created them. Practitioners should treat API governance as an access governance discipline, not just an inventory exercise.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What is the difference between API discovery and API governance?
A: API discovery finds what exists, while API governance decides who may use it, how it may be accessed, and when that access must be removed. Discovery is the visibility layer; governance is the control layer. Organisations need both, because you cannot enforce policy on interfaces you have not found.
👉 Read our full editorial: API sprawl is widening attack surfaces faster than teams can govern