API security inventories are lagging behind usage and governance

At a glance

What this is: This is an independent analysis of Salt’s API security report, which finds that visibility, inventory accuracy, and runtime monitoring are still lagging behind API growth.

Why it matters: It matters because APIs now sit inside identity, access, and data pathways, so weak inventory and posture governance can leave both human and non-human access paths exposed.

By the numbers:

• 58% of organizations monitor their APIs less than daily and lack confidence in the accuracy of their inventories.
• 55% of organizations admitted to slowing down the rollout of new applications due to API security concerns.

👉 Read Salt's 2025 State of API Security Report

Context

API security is now a governance problem as much as a technical one. As APIs proliferate across cloud platforms, application stacks, and AI-enabled workflows, organisations often lose track of what exists, who can call it, and whether those calls are still appropriate. That is especially relevant to identity security because APIs frequently carry the privileges of human users, service accounts, and automated workflows.

Salt’s report points to a familiar pattern: discovery improves more slowly than exposure grows. When inventory confidence is low and runtime monitoring is infrequent, security teams cannot reliably distinguish sanctioned use from unmanaged access, which creates blind spots for both API abuse and hidden non-human identity pathways.

Key questions

Q: How should security teams govern cloud workloads that rely on service accounts and API keys?

A: Treat workload identities as first-class governed assets, not implementation details. Assign ownership, scope permissions to specific tasks, rotate credentials on a defined cadence, and ensure every secret has a revocation path. The strongest programmes tie cloud architecture reviews to access review and offboarding processes so that hidden standing privilege cannot persist unnoticed.

Q: Why do API inventories become unreliable so quickly in cloud and SaaS environments?

A: They become unreliable because APIs change faster than manual ownership and documentation can be updated. New endpoints, partner integrations, AI-connected services, and short-lived credentials create gaps between what teams think exists and what is actually exposed. Continuous reconciliation is the only practical answer.

Q: What do security teams get wrong about API posture governance?

A: They often treat it as a policy document exercise instead of a live control. Posture governance only works when authentication, authorization, logging, and exposure settings are verified continuously against real traffic and configuration drift. Without runtime validation, teams may have rules that are never actually enforced.

Q: How do you know if API endpoint security controls are actually working?

A: Look for consistent method enforcement, low rates of anomalous requests, clear separation between read and write operations and stable auth outcomes across services. If the same credential can reach unexpected routes or if the gateway allows behaviour that the design never intended, the control is only partially effective.

Technical breakdown

Why API inventory accuracy breaks down at scale

API inventories fail when discovery, ownership, and change management are disconnected. Modern estates contain public APIs, internal services, partner integrations, and AI-connected endpoints that change faster than manual registers can keep up. If asset metadata is stale, the security team may know an endpoint exists without knowing its data sensitivity, authentication method, or last usage. That turns inventory into a reporting exercise rather than a control. In practice, incomplete discovery also weakens downstream controls such as authentication policy, rate limiting, and exception handling because teams are protecting an asset map that no longer matches reality.

Practical implication: tie API discovery to continuous asset reconciliation, not quarterly review cycles.

What runtime monitoring needs to see in API traffic

Runtime monitoring is about understanding behaviour, not just counting requests. A useful control should distinguish normal application calls from anomalous patterns such as unexpected token reuse, unusual source geographies, privilege escalation through chained calls, or high-volume scraping. For identity teams, the important point is that APIs often act as the enforcement layer for machine and human access alike. If logging is shallow, teams miss when a service account, API key, or delegated token is abused. Without behavioural context, alerting becomes noisy while genuinely risky access paths remain invisible.

Practical implication: alert on identity-sensitive API behaviours, not only on volume thresholds.

How posture governance turns policy into enforcement

API posture governance is the discipline of making API policy measurable and enforceable across design, deployment, and runtime. It covers authentication requirements, authorization scope, schema exposure, logging, and exception handling. In identity terms, it is the bridge between a declared access model and actual runtime access. If teams cannot validate that only approved identities can reach an endpoint, posture governance is incomplete. This is where API security intersects with IAM and NHI governance, because service accounts, tokens, and application credentials often outlive the business logic they were created to support.

Practical implication: map each API to an owner, an authentication model, and an approved identity scope.

Threat narrative

Attacker objective: The objective is to abuse trusted application interfaces to reach data, functionality, or downstream systems without tripping traditional perimeter controls.

1. Entry typically begins through an exposed or poorly governed API that is reachable with weak authentication or stale credentials.
2. Escalation occurs when the attacker reuses tokens, overbroad scopes, or undocumented endpoints to move from a single call path into broader data or control access.
3. Impact follows when the attacker extracts data, manipulates workflows, or uses the API as a low-friction route into connected systems.

NHI Mgmt Group analysis

API security now depends on identity-aware governance, not just endpoint discovery. Inventory accuracy matters, but inventories that do not capture the identity attached to each API call leave teams blind to privilege and trust relationships. APIs are often operated by service accounts, tokens, and automated workflows, so the real governance question is who or what is calling the interface and under what scope. Practitioners should treat API estate management as an IAM and NHI control problem, not only an application security task.

Posture drift creates a visibility gap that conventional scanning cannot close. The report’s emphasis on low-frequency monitoring reflects a broader industry weakness: teams often validate APIs after deployment, while access patterns evolve continuously. That creates a persistent mismatch between policy and runtime behaviour. API posture drift: the condition where approved API controls no longer match live authentication, authorisation, or exposure settings. Practitioners should assume drift unless they can continuously reconcile design intent with live traffic.

The most material risk is not API growth itself, but unmanaged access paths that accumulate around it. As organisations add integrations, partner access, and AI-connected workflows, the number of credentials and delegated permissions grows faster than review processes. This is where the identity bridge becomes important: APIs are a common enforcement layer for human and non-human access, so weak API governance becomes a proxy for weak identity governance. Practitioners should align API control owners with IAM and NHI ownership, or gaps will persist between teams.

Governance needs to shift from policy publication to control verification. Many teams have API security rules on paper, but the report shows that adoption and confidence are still uneven. That is a sign that policy frameworks alone are insufficient without telemetry, ownership, and enforcement feedback loops. NIST Cybersecurity Framework 2.0 and OWASP API guidance both point toward continuous control validation. Practitioners should measure whether policy is actually enforced at runtime, not whether it has been documented.

What this signals

API security programmes will increasingly be judged by whether they can prove live control, not whether they can describe policy. For identity teams, that means bringing API inventory, token governance, and service-account ownership into the same operational loop that already covers privileged access and non-human identities. The control gap is not discovery alone, but the failure to connect discovery to enforceable identity scope.

API posture drift: once APIs are embedded in cloud, partner, and AI workflows, exposure changes faster than quarterly governance can track. The practical response is continuous verification, with ownership metadata and runtime telemetry feeding a single view of access risk. Teams should expect API governance to converge with broader IAM and NHI operations, especially where machine identities invoke business-critical workflows.

Security leaders should also expect the AI layer to amplify API governance pressure. AI-generated code, agent-driven integrations, and delegated automation all increase the number of APIs that matter and the number of identities that can call them. That makes least privilege, token lifecycle management, and exception review strategic controls rather than tactical cleanup.

For practitioners

• Build a continuously reconciled API inventory Link discovery to asset ownership, authentication method, data sensitivity, and last-seen usage so the register reflects live environment state. Review orphaned or undocumented endpoints first, because they often carry the weakest control coverage.
• Instrument runtime alerts for identity-sensitive API behaviour Detect token reuse, unexpected privilege changes, unusual client geographies, and access to endpoints outside normal service patterns. Treat service-account and delegated-token misuse as a first-class detection use case, not a generic anomaly problem.
• Map each API to an explicit control owner Assign ownership across application, IAM, and platform teams so authentication, authorization, logging, and exception handling are reviewed together. Where non-human identities invoke the API, require a named owner for the credential lifecycle and scope.
• Validate posture drift against policy at runtime Compare approved access rules with live traffic and configuration changes, then block exceptions that bypass agreed authentication or logging requirements. Use the drift findings to prioritise the APIs most likely to expose data or delegated privileges.

Key takeaways

• API security is now a governance problem because inventory accuracy, runtime visibility, and policy enforcement are drifting apart.
• The report’s core warning is operational, not theoretical: when one in five organisations only achieve real-time oversight, attack surface grows faster than control.
• Practitioners should align API security with IAM and NHI ownership so that every endpoint has a live owner, a scoped identity, and runtime verification.

Key terms

• API posture governance: API posture governance is the practice of continuously validating that API authentication, authorization, logging, and exposure settings match policy. It turns a written standard into an enforceable control by tying each endpoint to ownership, telemetry, and exception management.
• Runtime Monitoring: The practice of observing identity activity while it is happening, not after the fact. For agents and NHIs, it means tracking tool calls, credential use, and resource access in real time so deviations from approved scope can be detected before damage compounds.
• API inventory reconciliation: API inventory reconciliation is the process of comparing discovered APIs against ownership, configuration, and live usage so the register stays accurate. It matters because stale inventories hide shadow endpoints, orphaned access paths, and unsupported credentials.
• Identity-sensitive API behaviour: Identity-sensitive API behaviour is any request pattern that signals a change in trust, privilege, or caller legitimacy, such as token reuse, scope expansion, or unusual source context. Tracking it helps teams distinguish normal traffic from access abuse.

What's in the full report

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

• Benchmark detail on how often organisations monitor APIs and where their inventories are breaking down.
• Adoption data for OWASP Top Ten guidance and posture governance practices across security teams.
• Breakouts on budget, staffing, and tooling constraints that shape real API security programmes.
• The report’s discussion of generative AI risks affecting API quality, runtime assurance, and code security.

👉 Salt's full report covers the monitoring, governance, and AI risk detail behind these findings.

Deepen your knowledge

NHI Mgmt Group’s 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 identity controls to the broader security programme they operate.