API discovery lag is widening the real-time security gap

At a glance

What this is: This is an independent analysis of why rapid API growth is outpacing discovery and why real-time monitoring is becoming the practical answer to exposed APIs.

Why it matters: It matters because API sprawl creates access and data exposure paths that identity, cloud, and application security teams must govern continuously, not at periodic review points.

By the numbers:

• The API count increasing by 167% in the past year.
• Only 58% of organizations have procedures in place for API discovery.

👉 Read Salt's analysis of real-time API scanning and discovery gaps

Context

API security fails when organisations do not know what is live, what is exposed, or which interfaces carry sensitive data. In practice, periodic scanning leaves a gap between deployment and detection, and that gap widens as release cycles accelerate. For identity and access teams, the issue is not only API scale. It is the governance problem of knowing which services, tokens, and authorisations exist at any moment.

The article argues for real-time scanning because modern APIs change too quickly for batch review to be reliable. That intersection matters to IAM and NHI programmes because APIs often depend on service accounts, tokens, and other non-human identities. When discovery lags, so does control over who or what can call sensitive interfaces, which is exactly where abuse begins.

Key questions

Q: How should security teams handle API discovery when services change daily?

A: They should treat discovery as a continuous control, not a periodic audit. That means inventorying APIs from deployment pipelines, cloud events, and runtime telemetry so ownership, authentication, and exposure are always current. Without that baseline, scanning finds problems too late to prevent abuse.

Q: Why do APIs create identity governance risk across machine and human access?

A: APIs often carry the real access decision for service accounts, tokens, and human sessions. If an API accepts the wrong identity context, broadens scope during errors, or leaks data in failure paths, the governance model is broken even when the application appears to work.

Q: What breaks when organisations rely on periodic API scans?

A: Periodic scans leave a gap between deployment and detection, which is enough time for exposed endpoints, weak business logic, or misconfigured authentication to be abused. In fast-moving environments, that means the security team is always reacting to a past state rather than controlling the present one.

Q: How do teams decide whether real-time API scanning is necessary?

A: If APIs are frequently created, modified, or exposed through cloud-native delivery, real-time scanning is usually justified. The stronger the linkage to sensitive data, privileged workflows, or machine-to-machine authentication, the less defensible batch-only review becomes.

Technical breakdown

Why periodic API scanning leaves exploitable windows

Periodic scanning creates a delay between the moment an API becomes reachable and the moment it is assessed for risk. That delay matters because modern APIs are created, modified, and retired continuously, especially in cloud-native delivery pipelines. If security checks only run on a schedule, attackers can operate inside a window where business logic flaws, misconfigurations, or exposed endpoints remain invisible. Real-time scanning narrows that gap by inspecting traffic and configuration as changes occur, rather than after a release cycle closes. Practical implication: shift from batch vulnerability review to continuous exposure detection for all internet-facing APIs.

Practical implication: shift from batch vulnerability review to continuous exposure detection for all internet-facing APIs.

How AI-assisted API creation changes the risk profile

AI-assisted development speeds API production, but it can also amplify two failure modes: weak configuration and poor data handling. If developers use AI to draft endpoints or integration logic, the resulting API may be functional yet still expose sensitive data, mis-handle authentication, or embed unsafe defaults. The article also points to a separate concern: feeding sensitive company data into public AI models during development. That creates a governance intersection between application security, data handling, and AI usage policy. Practical implication: review AI-generated APIs with the same control standards applied to manually written services, including authentication, logging, and data minimisation.

Practical implication: review AI-generated APIs with the same control standards applied to manually written services, including authentication, logging, and data minimisation.

Why real-time detection matters for zero-day business logic abuse

The article makes a useful distinction: in APIs, many vulnerabilities are not just known software flaws, but business-logic weaknesses specific to how a company has configured access and workflows. That means traditional vulnerability databases are only part of the picture. Real-time detection can surface anomalous usage patterns, unusual request sequences, and abuse of endpoints that look legitimate at the protocol level but not at the behavioural level. This is especially relevant where service accounts, tokens, or other NHI credentials authenticate machine-to-machine traffic. Practical implication: pair runtime telemetry with identity-aware controls so the system can spot misuse, not just broken code.

Practical implication: pair runtime telemetry with identity-aware controls so the system can spot misuse, not just broken code.

Threat narrative

Attacker objective: The attacker aims to use overlooked API exposure to reach sensitive data or privileged workflows before defenders detect the weakness.

1. Entry occurs through exposed or newly deployed APIs that have not yet been discovered or scanned.
2. Escalation follows when attackers exploit weak configuration, business logic flaws, or missing authentication controls to access sensitive functions.
3. Impact is achieved through data theft, account abuse, or operational disruption across connected services.

NHI Mgmt Group analysis

API discovery debt is now a governance problem, not just a tooling gap. When organisations cannot enumerate their APIs quickly enough, they cannot govern exposure, ownership, or authentication with confidence. That creates blind spots for both application security and IAM because machine-to-machine access often rides on tokens and service accounts. The practical conclusion is that API discovery must be treated as a control prerequisite, not a hygiene task.

Real-time scanning changes the control model from point-in-time review to runtime assurance. Periodic testing assumes the risk surface is stable enough to assess later. Modern API environments invalidate that assumption because interfaces appear and evolve faster than review cycles can keep up. Security teams should therefore treat runtime monitoring as part of operational control design, not as a post-deployment add-on.

API abuse is increasingly an identity problem because APIs authenticate machines, not just users. When service accounts, tokens, and keys are the mechanism of access, the question becomes who or what can call which function under what conditions. That puts NHI governance directly into the API security stack, especially where privileged integrations can move laterally across environments. Practitioners should align API protection with NHI lifecycle and access governance.

AI-assisted development is introducing configuration risk faster than most control programs can absorb it. If AI can help generate APIs in minutes, then security review must scale at the same pace or it becomes a bottleneck. The better framing is not whether AI is safe to use, but whether the organisation can validate the output before exposure. Teams should build approval and telemetry checkpoints around AI-generated services rather than relying on developer intent.

What this signals

API security programmes are moving toward runtime governance, because exposure can no longer be assumed to be stable between reviews. For identity teams, that means the same discipline used for NHI lifecycle control should extend to machine-authenticated APIs. Exposure drift: the window between deployment and detection is becoming the primary measure of control quality, not the existence of a scan policy.

The practical response is to connect discovery, runtime telemetry, and access governance into one control loop, rather than treating them as separate teams' problems. Where APIs depend on service accounts or tokens, NHI oversight becomes part of application security by default. That is the shift practitioners should prepare for, and it aligns with the control logic in NHI Lifecycle Management Guide.

For practitioners

• Implement continuous API discovery Maintain an always-current inventory of exposed APIs, owners, and authentication methods so new or changed interfaces are not left outside the control boundary. Tie discovery to CI/CD and cloud change events, not just scheduled scans.
• Move to runtime API monitoring Use real-time inspection for anomalous request patterns, unexpected authentication failures, and suspicious payload behaviour. This is the control that reduces the exposure window created by periodic scanning.
• Map machine-to-machine access to NHI governance Review service accounts, tokens, and API keys that authenticate critical integrations, then enforce ownership, rotation, and revocation rules alongside API security reviews.
• Gate AI-generated APIs before production Require security validation for endpoints generated or modified with AI assistance, including authentication checks, logging review, and data handling approval before release.

Key takeaways

• API security now fails most often through visibility lag, not just code defects.
• Discovery, runtime monitoring, and machine identity governance need to operate as one control loop.
• AI-assisted API creation makes pre-production validation a security requirement, not a workflow preference.

Key terms

• API Coverage: API coverage describes how much of an application’s user, entitlement, and activity data is available through programmable interfaces. In SaaS management, limited API coverage constrains automation and forces teams to use manual or hybrid controls for parts of the application estate.
• Runtime API Monitoring: Runtime API monitoring inspects API traffic and behaviour while the service is live, rather than only during scheduled scans. It looks for abuse patterns, abnormal request sequences, and misused credentials, making it especially useful where machine-to-machine access changes faster than review cycles.
• Machine-to-Machine Authentication: Machine-to-machine authentication is the process of proving the identity of one system to another before data or commands are exchanged. In practice, it must be paired with authorization, audit logging, and short-lived trust, or the same credential can become a reusable path into production systems.

What's in the full article

Salt's full article covers the operational detail this post intentionally leaves for the source:

• Specific real-time scanning approaches for identifying malicious intent versus benign API anomalies.
• Practical considerations for embedding API security into CI/CD pipelines and release workflows.
• The article's discussion of how AI is accelerating API creation while also raising security and data-handling concerns.
• Salt Labs' referenced findings on ChatGPT ecosystem flaws and third-party account access.

👉 Salt's full post covers the API security risks, AI-assisted development concerns, and runtime protection argument in more detail.

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 align identity controls with the operational realities of service accounts, tokens, and automated integrations.