Notifications
Clear all
Topic starter
02/08/2026 12:22 pm
TL;DR: API sprawl is creating hidden endpoints, inconsistent controls, and compliance risk across cloud-native environments, with Salt Security citing that over 63% of organisations saw incidents from unmonitored or inadequately secured APIs in 2024. The governance problem is no longer discovery alone. It is lifecycle control, access control, and continuous enforcement across every API that can expose data or credentials.
NHIMG editorial — based on content published by Salt: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- Over 63% of organizations experienced security incidents due to unmonitored or inadequately secured APIs in 2024.
- The USPS Informed Visibility API exposed data for over 60 million USPS users after lacking proper access control and anti-scraping protections.
Questions worth separating out
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.
Q: Why do shadow APIs increase insurance and breach risk?
A: Shadow APIs expand the attack surface without corresponding ownership, testing, or monitoring.
Q: How can teams tell whether API governance is actually working?
A: A working programme can answer four questions quickly: who owns the consumer, what it can access, where the policy is enforced, and how the call is logged.
Practitioner guidance
- Implement continuous API discovery Build an always-on inventory that detects shadow and undocumented APIs across cloud environments, then tie each endpoint to an owner, data classification, and authentication method.
- Standardise authentication across all APIs Require consistent authentication, authorisation, and logging controls for every API, including legacy endpoints that still rely on static API keys or basic authentication.
- Retire zombie APIs on a fixed schedule Add decommissioning checkpoints to the application lifecycle so endpoints are reviewed for continued use, business justification, and access scope before they remain live in production.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- Specific examples of how API sprawl creates blind spots across cloud environments and business units
- Detailed discussion of how inconsistent authentication choices leave older APIs with weaker protections
- Case material on zombie APIs and the USPS Informed Visibility exposure, including the access-control failure pattern
- Practical recommendations for centralised API management, discovery, and lifecycle tracking
👉 Read Salt's analysis of API sprawl, shadow endpoints, and lifecycle risk →
API sprawl: what it means for security teams and identity controls?
Explore further
02/08/2026 1:22 pm
API sprawl is now an identity governance problem, not just an application security problem. Once APIs become the dominant interface between services, the real control issue is who or what can invoke them, under which credential, and with what lifecycle oversight. That brings machine credentials, access scoping, and offboarding into the same governance conversation as endpoint discovery. Practitioners should treat APIs as identity-bearing assets, not just technical endpoints.
A question worth separating out:
Q: Who is accountable when a partner API exposes customer data?
A: Accountability sits with both the API owner and the team governing the credential lifecycle. If third-party access is not scoped, monitored, and revoked when no longer needed, the organisation has accepted standing trust without lifecycle control. Frameworks such as NIST CSF and zero trust place that responsibility on access governance.
👉 Read our full editorial: API sprawl is widening attack surfaces faster than teams can govern
