Topic starter
02/08/2026 12:32 pm
TL;DR: API traffic now accounts for more than 80% of internet traffic and 64% of organisations reported an API attack or breach in the past year, according to Salt, while many teams still underestimate their API estate by 70% to 80%. The governance problem is visibility, inventory accuracy, and runtime control, not just perimeter inspection.
Editorial analysis by NHI Mgmt Group, based on content published by Salt: “Don't Be a Statistic: Proactive API Security in the Age of AI”.
By the numbers:
- 64% of organizations have encountered an API attack or security breach in just the past year.
- 87% of organizations are uneasy about data governance or data exposure from insecure APIs.
Key questions
Q: What breaks when API inventories are incomplete?
A: When inventories are incomplete, teams cannot reliably know which APIs exist, what data they expose, or which identities and tokens can reach them.
Q: Why do shadow APIs increase insurance and breach risk?
A: Shadow APIs expand the attack surface without corresponding ownership, testing, or monitoring.
Q: What are the signs that an API control program is failing in practice?
A: Common warning signs include spikes in 403 responses, bursts of schema violations, sequential ID access, repeated webhook IDs, and tokens reused across services.
Practitioner guidance
- Build a complete API inventory Discover internal, external, shadow, and third-party APIs, then tie each one to an owner, data classification, and authentication method.
- Classify API entitlements and exposed data Document which identities, tokens, and service accounts can call each API and what objects or records they can reach.
- Replace perimeter-only protection with runtime governance Use behaviour-aware controls that can detect legitimate but abusive requests, especially where business logic is the attack path.
Bottom line: API sprawl turns incomplete discovery into an exposure problem because hidden interfaces often retain reachable data and functions after governance has moved on.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:29 pm
API visibility has become an identity control problem, not just an application inventory problem. If teams cannot reliably enumerate internal, external, shadow, and third-party APIs, they cannot govern the machine identities and delegated access paths that depend on them. That makes API sprawl a structural weakness in IAM and NHI programmes, not a perimeter issue. The practitioner conclusion is simple: inventory quality now determines control quality.
A few things that frame the scale:
- Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
- 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
A question worth separating out:
Q: How should security teams govern AI infrastructure that depends on APIs and microservices?
A: They should treat the combined stack as one identity system and map every machine-to-machine handoff, token, and delegated permission to an accountable owner. The key control is not the API gateway alone. It is the ability to trace, limit, and revoke access across the entire runtime path without relying on manual exception handling.
👉 Read our full editorial: API sprawl and shadow exposure are widening attack surface risk