TL;DR: API abuse, shadow and zombie APIs, third-party dependencies, and AI-assisted detection will shape API security in 2025 as attackers increasingly target legitimate API functionality rather than only classic vulnerabilities, according to Salt. The underlying problem is governance gap, not just tooling gap: organisations need visibility, control, and accountability across exposed APIs before misuse becomes routine.
NHIMG editorial — based on content published by Salt: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations.
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 shadow APIs create more risk than normal monitored traffic?
A: Shadow APIs bypass the assumptions behind monitoring because the organisation does not know they exist, so no one has reliably reviewed their authentication, authorisation, or data exposure.
Q: What do security teams get wrong about third-party API risk?
A: They often focus on the vendor connection itself and miss the lifecycle of the entitlement behind it.
Practitioner guidance
- Build an authoritative API inventory Catalog every externally reachable, partner-facing, and internal API with owner, purpose, authentication method, and retirement date.
- Bind each API to an accountable identity Map every service, integration, token, and OAuth grant to a named business owner and review interval.
- Define abuse cases alongside vulnerability cases Create detections for scraping, rate-limit evasion, bulk export, repeated enumeration, and business-logic abuse across high-value APIs.
What's in the full article
Salt’s full article covers the operational detail this post intentionally leaves for the source:
- Salt’s specific 2025 product and roadmap framing for AI-assisted API security operations
- The vendor’s detailed view on API abuse, shadow APIs, and third-party risk prioritisation
- The source article’s own compliance commentary on how API regulation may tighten over time
- Salt’s closing demo-oriented positioning for organisations evaluating the platform
👉 Read Salt’s 2025 outlook on API abuse, shadow APIs, and AI →
API abuse and shadow APIs in 2025: are your controls keeping up?
Explore further
API abuse is becoming the default threat model for exposed interfaces. The article’s central claim is directionally correct: attackers increasingly prefer legitimate requests over obvious exploits because the business logic already does the hard work for them. That shifts the defensive problem from patching to policy enforcement, telemetry quality, and abuse detection. For identity programmes, the key implication is that API authorisation must be treated as a governed access path, not just a developer convenience.
A question worth separating out:
Q: How do security teams know if API abuse controls are working?
A: Security teams know API abuse controls are working when repeated credential use drops, abnormal request volume is detected early, and hostile client behaviour is blocked before backend systems see sustained load. Effective controls reduce both attack success rate and the time abuse can persist unnoticed.
👉 Read our full editorial: API security in 2025: why abuse, shadow APIs and AI matter