Notifications
Clear all
Topic starter
02/08/2026 12:26 pm
TL;DR: API usage rose for 92% of organisations over the past year, while many now run hundreds or thousands of undocumented shadow APIs, according to KuppingerCole’s 2025 Leadership Compass cited in Salt Security’s analysis. Point tools miss the lifecycle risk, because insecure design, weak discovery, and runtime abuse must be governed as one control plane.
NHIMG editorial — based on content published by Salt: full-lifecycle API security and runtime defense
By the numbers:
- 92% of organizations increased API usage over the past year
Questions worth separating out
Q: How should security teams govern API access across humans, services, and agents?
A: Security teams should govern API access by identity type, caller context, and action scope, not by whether the API is internal or protected by a gateway.
Q: Why does shadow AI create a governance gap for IAM and security teams?
A: Shadow AI creates a governance gap because organizations cannot manage systems they do not reliably see.
Q: What breaks when API security is split between development and runtime teams?
A: When development and runtime security are split, gaps appear between what was tested and what is actually deployed.
Practitioner guidance
- Create a full API inventory with ownership attached Map every API to a business owner, data class, and authentication method.
- Enforce design-time policy checks before deployment Block release when APIs lack authentication, expose sensitive data unnecessarily, or violate approved policy rules.
- Instrument runtime telemetry for machine-to-machine abuse Track request patterns, token use, data volume, and unusual access sequences across live traffic.
What's in the full article
Salt's full analysis covers the operational detail this post intentionally leaves for the source:
- Detailed breakdown of the Posture Governance engine and the 70 pre-configured policy rules used to enforce API controls.
- Cloud Connect discovery workflow for AWS, Azure, and GCP, including how it finds assets without sensors.
- Runtime analytics, AI/ML detection, and MITRE ATT&CK event enrichment used to flag API abuse.
- Practical mitigation routing into SIEMs, WAFs, and gateways for live response and enforcement.
👉 Read Salt's analysis of full-lifecycle API security and runtime defense →
API security across the lifecycle: are your controls keeping up?
Explore further
02/08/2026 1:25 pm
API security is becoming an identity governance problem as much as an application security problem. The article’s real signal is that machine-facing access now depends on tokens, service accounts, and API keys that behave like non-human identities. That means discovery, authorisation, and lifecycle control matter more than isolated scanning. Teams should treat API governance as part of broader identity architecture, not a separate point discipline.
A question worth separating out:
Q: Which controls matter most when APIs are called by service identities?
A: Service identities should be governed with the same discipline as human users, but with tighter scope and lifecycle controls. That means short-lived credentials, route-specific permissions, rotation, and logging that can attribute each call. If those controls are loose, API security becomes an NHI problem as much as an application problem.
👉 Read our full editorial: API security must shift from point tools to full lifecycle control
