Notifications
Clear all
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.
NHIMG editorial — based on content published by Salt: LLMjacking? Actually API attack prevention, posture governance, and runtime threat protection
By the numbers:
- 64% of organizations have encountered an API attack or security breach in just the past year.
Questions worth separating out
Q: What breaks when API security depends only on gateways and WAFs?
A: Teams lose visibility into business logic abuse, object-level authorisation failures, and low-and-slow reconnaissance that looks legitimate at the transaction layer.
Q: Why do shadow AI tools create identity governance risk?
A: Shadow AI is risky because users often reach those tools through identities, browser sessions, or tokens that were never assessed for data handling or access scope.
Q: How can security teams tell whether API risk controls are actually working?
A: Look for reduced abuse volume, fewer successful automated attacks, and clearer visibility into which non-human clients are making requests and why.
Practitioner guidance
- Build a continuously reconciled API inventory Map every internal, external, shadow, and partner-facing API to an owner, environment, authentication method, and data classification.
- Enforce runtime authorisation on sensitive API paths Validate object-level access, data scope, and tenant boundaries at request time for every high-value API.
- Tie API access to NHI lifecycle controls Treat API keys, OAuth tokens, certificates, and service accounts as governed machine identities.
What's in the full article
Salt's full analysis covers the operational detail this post intentionally leaves for the source:
- A breakdown of API discovery and posture governance steps for teams that need to build an authoritative inventory.
- Examples of runtime threat patterns and business logic abuse cases that illustrate where gateway-only inspection falls short.
- Operational discussion of how to prioritise shadow APIs, third-party integrations, and high-risk data paths for remediation.
- Implementation context for teams aligning API controls with access governance and machine identity lifecycle management.
👉 Read Salt's analysis of API attack prevention, posture governance, and runtime protection →
API sprawl and shadow exposure: what IAM teams need to know?
Explore further
02/08/2026 1:29 pm
API security is now a governance discipline, not a point-solution problem. The article is right to focus on discovery, posture, and runtime threat protection, because those are three distinct control layers. Security teams fail when they treat API protection as a gateway tuning exercise instead of a lifecycle problem that spans ownership, authentication, and data exposure. For identity programmes, that means API governance must be tied to entitlement management and machine identity oversight.
A question worth separating out:
Q: Who is accountable when a public API leaks data through valid access?
A: Accountability usually spans application owners, IAM or platform teams, and security leadership, because the failure is shared between access design, endpoint logic, and monitoring. In regulated environments, the organisation must also be able to show that access controls and logging were proportionate to the sensitivity of the data involved.
👉 Read our full editorial: API sprawl and shadow exposure are widening attack surface risk
