Notifications
Clear all
Topic starter
02/08/2026 12:21 pm
TL;DR: API attacks are rising as organisations expand APIs, microservices, and distributed architectures, while many teams still misjudge their exposure and struggle to turn visibility into policy, according to Salt Security. The practical shift is from counting APIs to governing posture, behavior, and access boundaries across the full API lifecycle.
NHIMG editorial — based on content published by Salt: a CMO perspective on API security, AI risk, and 2024 priorities
By the numbers:
- According to the State of API Security Report Q1 2023, there was a 400% increase in unique API attackers last 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 do APIs become high-risk when organisations scale quickly?
A: APIs become high-risk because scale increases the number of hidden trust relationships.
Q: What do teams get wrong about API discovery and monitoring?
A: Teams often treat discovery as a one-time project, but shadow APIs appear through rapid releases, SaaS integrations, and forgotten code paths.
Practitioner guidance
- Establish an authoritative API inventory Create a single source of truth for API ownership, authentication model, data sensitivity, and production status.
- Tie API policy to identity controls Map each API to the service accounts, tokens, and secrets that can reach it, then review scope, lifetime, and privilege as part of identity governance.
- Continuously compare posture to policy Use posture checks to verify authentication settings, exposure, and data handling against approved baseline rules.
What's in the full article
Salt's full post covers the operational detail this post intentionally leaves for the source:
- How Salt frames API posture governance in terms of policy authoring, assessment, and compliance checks
- The company’s specific examples of how its API security lifecycle messaging maps to customer use cases
- Its discussion of AI-assisted API attack detection and the operational claims behind that approach
- The investor and partner context Salt uses to position its market trajectory
👉 Read Salt Security's analysis of API security governance, AI risk, and posture management →
API security governance: are your controls keeping up with API sprawl?
Explore further
02/08/2026 1:22 pm
API posture governance is becoming a control-plane issue, not a point-solution feature. Once organisations have thousands of APIs, manual review cannot keep pace with change, and that creates a governance gap between what policy says and what production actually permits. The relevant discipline is no longer only detection, but continuous comparison of exposure, authentication, and data access against approved intent. Practitioners should treat API posture as part of core security governance.
A question worth separating out:
Q: Who is accountable when API posture drifts from policy?
A: Accountability should sit with the business owner of the API, the security team enforcing policy, and the platform team operating the control. If those roles are unclear, posture drift becomes nobody’s problem until an incident forces attention. Clear ownership and review cadences are the difference between managed risk and inherited risk.
👉 Read our full editorial: API security governance is shifting from visibility to policy enforcement
