API security in 2025: why abuse, shadow APIs and AI matter

At a glance

What this is: Salt argues that API abuse, shadow APIs and third-party dependencies are becoming the dominant 2025 risk pattern because attackers are targeting legitimate API behaviour, not just exploitable bugs.

Why it matters: IAM and security teams need to treat API estate governance as an access-control problem, because exposed interfaces, unmanaged endpoints and connected services expand blast radius fast.

Context

API security is no longer just about finding a vulnerable endpoint or patching an exposed service. The operational problem is API estate governance: knowing what exists, who owns it, what it can do, and whether it is still supposed to be reachable. That becomes especially important when APIs sit inside identity, payment, healthcare, and AI workflows.

The article’s central claim is that misuse is overtaking classical exploitation. Shadow APIs, zombie APIs, third-party dependencies and AI-assisted detection all point to the same control gap: organisations struggle to govern fast-growing machine-to-machine access at the same pace that business teams expose new interfaces.

Key questions

Q: What breaks when API discovery is incomplete?

A: When discovery is incomplete, security teams miss shadow APIs, forgotten integrations, and endpoints that no longer have an obvious owner. Those gaps prevent consistent authentication, logging, rate limiting, and offboarding, which creates an easy path for attackers to find overlooked access points. An API estate cannot be governed if it cannot be inventoried.

Q: Why do shadow APIs create such a large security gap?

A: Shadow APIs bypass ownership, policy enforcement, and change control, so defenders cannot reliably classify the data they expose or the identities that can reach them. That makes them ideal for reconnaissance and data extraction. If an API is not in the live inventory, it is effectively outside governance.

Q: How should security teams govern third-party retail API access?

A: They should inventory every partner integration, define the minimum access scope, and require logging and offboarding controls for each trust relationship. Third-party APIs are not just technical connectors, they are delegated access paths into business processes. Governance has to cover onboarding, ongoing monitoring and removal, or the integration becomes a persistent risk.

Q: What signals show that bot abuse is becoming a governance problem?

A: Look for repeated returns from the same device family, unusually fast account replacement after bans, and clustered sessions that behave like one operator rather than many users. Those signals show the issue is not isolated abuse but a governance gap in identity correlation and enforcement persistence.

Technical breakdown

Why API abuse beats classic vulnerability hunting

API abuse happens when an attacker uses intended functionality in unintended ways, such as scraping data, automating fraud, or chaining legitimate calls at scale. That differs from vulnerability exploitation, where the attacker relies on a flaw like broken authentication or injection. Once APIs become the control surface for business logic, defenders must monitor behaviour, not just code defects. AI and machine learning help here because traffic volume and request patterns are too large for manual review. The real architectural shift is from perimeter thinking to runtime abuse detection.

Practical implication: instrument APIs for abnormal usage patterns, not only for known CVEs and misconfigurations.

Shadow APIs and zombie APIs create hidden exposure

Shadow APIs are undocumented or unmanaged interfaces, while zombie APIs are old endpoints that remain reachable after they should have been retired. Both are dangerous because security teams cannot protect what they cannot inventory. In practice, these APIs often bypass normal review, rate limiting and ownership processes, which makes them a governance blind spot as much as a technical one. This is where API discovery becomes an identity and access issue, because every unknown endpoint is an unknown permission path.

Practical implication: build continuous API discovery and ownership validation into change and asset governance.

Third-party APIs expand the trust boundary

When organisations depend on third-party APIs for payments, analytics or other core functions, they inherit someone else’s security posture and operational risk. The attack surface grows because connected ecosystems create transitive exposure: one weak partner integration can compromise data access or service integrity downstream. This is especially relevant to identity programmes because API credentials, tokens and delegated trust are the mechanisms that make those integrations work. The control question is not whether an API is external, but whether its access is bounded, monitored and revocable.

Practical implication: treat external API access like privileged delegated access and review it on a fixed lifecycle.

Threat narrative

Attacker objective: The attacker wants to extract data, automate abuse, or extend trusted access through APIs while avoiding detection.

1. Entry begins with legitimate access to a public, partner, or forgotten API rather than a forced exploit.
2. Credential or token use then enables abusive queries, data scraping, or automated misuse through intended business functions.
3. The attacker scales impact by hiding inside normal request traffic, exploiting unmanaged shadow or zombie endpoints and third-party dependencies.
4. The result is data theft, service abuse, or downstream compromise without the obvious signals of a classic vulnerability exploit.

Breaches seen in the wild

• T-Mobile API breach 2023: An attacker pulled data on 37 million T-Mobile accounts through one API, without authorisation, for six weeks before detection.
• Sourcegraph breach 2023: A site-admin token left in a Sourcegraph commit for 47 days let an attacker become admin and offer free access to its APIs and LLM via a proxy.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API estate governance is now an access-control problem, not just an application-security problem. The article’s threat pattern is not a single bug class but the accumulation of unmanaged interfaces, delegated trust and business logic exposure. Once APIs become the default path into services, ownership and lifecycle control matter as much as code review. Practitioners should treat API inventory, entitlements and revocation as governance controls, not housekeeping.

Shadow APIs create a visibility gap that security tooling alone cannot close. If an endpoint is not inventoried, it is also not being risk-assessed, monitored or retired on schedule. That makes undocumented interfaces the API equivalent of standing access with no owner, which is why discovery has to be continuous rather than periodic. For IAM and PAM teams, this is a reminder that hidden machine access is still access, even when it is not surfaced in conventional review workflows.

AI-assisted detection will matter because abuse now looks like normal traffic. The article correctly points to machine learning as a response to scale, but the deeper issue is behavioural ambiguity. A large share of API misuse will not trigger classic exploit signatures, especially when the attacker is using legitimate credentials or partner integrations. That pushes the field toward anomaly detection, policy enforcement and stronger entitlement governance across API consumers.

Third-party API risk is becoming delegated-trust risk. Modern integrations extend the trust boundary beyond the organisation’s own perimeter, and that creates governance debt when credential scope, rotation and offboarding are weak. The practitioner lesson is to manage API access like any other privileged dependency: bounded, monitored, revocable and attributable. Without that, partner connectivity becomes an uncontrolled access multiplier.

Shadow API discovery is the named concept practitioners should prioritise. Discovery is not a one-time asset inventory task, but a standing control for reducing unknown exposure. The organisation that cannot continuously enumerate its APIs will always be slower to detect misuse than the attacker is to find the overlooked endpoint. Practitioners should align API discovery with identity governance, especially where tokens and service accounts mediate access.

From our research library:

• 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.
• More than 80% of enterprises will have used generative AI APIs or deployed GenAI applications by 2026, up from 5% in 2023, according to Gartner.
• Read next: NHI Authentication Guide

What this signals

API security teams need to move from endpoint protection to estate governance. The practical test is whether every API has an owner, a purpose, a review cycle and a revocation path, because unmanaged interfaces behave like standing access that never expires.

Shadow API discovery: continuous discovery is becoming the control that separates managed machine access from hidden exposure. Organisations that cannot enumerate their APIs reliably will continue to discover risk only after misuse has already begun.

For practitioners

• Implement continuous API discovery Inventory public, partner and internal APIs continuously, then reconcile them against service ownership, business purpose and retirement status.
• Classify shadow and zombie endpoints Flag undocumented APIs and dormant endpoints as security exceptions until an owner confirms access scope, monitoring and decommissioning.
• Review delegated third-party access Treat partner API keys, tokens and service accounts as privileged access paths and require explicit lifecycle review for each integration.
• Tune detection for behavioural abuse Use anomaly detection to identify scraping, enumeration, rate spikes and unusual consumer patterns that indicate legitimate API misuse.
• Align API governance with identity controls Bind API permissions to named owners, rotation rules and revocation processes so exposed interfaces cannot outlive their business need.

Key takeaways

• API abuse is shifting attention away from classic vulnerability hunting and toward legitimate business logic being used at scale for scraping, automation and fraud.
• Undocumented shadow APIs, zombie endpoints and third-party dependencies create exposure that inventory and ownership controls are meant to prevent.
• The right response is continuous API discovery, delegated-access governance and behaviour-based detection, not just patching individual weaknesses.

Key terms

• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• Zombie API: A zombie API is a deprecated or abandoned interface that remains accessible after the organisation believes it should be retired. It is risky because old permissions, secrets, or backend trust can survive the business purpose, turning legacy access into an active exposure.
• API Abuse: The malicious use of legitimate API functionality for scraping, fraud, bulk extraction, enumeration, or workflow manipulation. Unlike classic exploitation, API abuse relies on valid requests and trusted access paths, which makes it harder to detect unless teams model misuse patterns explicitly.
• Delegated trust: Delegated trust is the decision to let another system or organization issue, validate, or transmit access on your behalf. It is common in cloud and SaaS environments, but it becomes risky when scope, duration, and revocation are not tightly controlled. In NHI governance, delegated trust must be explicit and continuously reviewable.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect API access controls to broader identity and access governance.