API security is now a governance issue, not just a breach issue

At a glance

What this is: Salt Security argues that API security should be treated as a business and governance priority because unmanaged APIs create risk, cost, and revenue exposure.

Why it matters: For IAM practitioners, APIs are part of the access fabric, so blind spots in discovery, authorisation, and runtime monitoring can turn into identity and data exposure across both human and machine-driven flows.

By the numbers:

• 94% of survey respondents had experienced API security problems in production, with 19% admitting to an API-related breach.
• 11% of respondents update their APIs daily, and 31% update them weekly.
• Businesses that utilize APIs were 12.7% more profitable over the past decade than those that did not use APIs.

👉 Read SALT's ebook on how protecting APIs protects the bottom line

Context

API security is a governance problem because APIs change quickly, expose business logic directly, and often sit outside the level of visibility organisations apply to user access. When attack surface discovery lags behind change velocity, teams inherit blind spots that traditional vulnerability management and periodic review processes do not close. In identity terms, APIs are often the control point where human, service, and application access converge.

Salt Security frames the issue around business risk, but the deeper operational lesson is that API access needs continuous control, not occasional inspection. That makes the topic relevant to IAM, PAM, and NHI programmes because service accounts, tokens, and partner integrations frequently depend on APIs to move data and trigger actions. The organisations most exposed are usually the ones with the fastest API churn and the weakest runtime governance.

This is not an edge case. APIs now sit inside core customer, partner, and internal workflows, so the control gap is structural rather than accidental.

Key questions

Q: How should security teams govern APIs that change frequently?

A: Security teams should treat fast-changing APIs as continuously governed assets, not quarterly review items. That means maintaining live inventory, mapping each endpoint to an owner and identity, and validating authorisation at runtime. If the API can change daily, the control model has to change with it. Static documentation alone will always lag behind exposure.

Q: Why do AI agents create new risk for IAM and NHI programmes?

A: Because they can execute actions, inherit permissions, and connect to sensitive systems without a human acting each time. That shifts risk from static account management to runtime behaviour, delegated access, and lifecycle control. IAM programmes must therefore track both the agent and the identities it uses.

Q: What breaks when API security is based only on vulnerability scanning?

A: What breaks is the assumption that every API risk is a code flaw. Many API incidents come from broken authorisation, business-logic abuse, or stale exposure that scanners do not recognise. If teams rely only on scanning, they will miss the misuse patterns that attackers exploit in production.

Q: Who is accountable when a partner API exposes customer data?

A: Accountability sits with both the API owner and the team governing the credential lifecycle. If third-party access is not scoped, monitored, and revoked when no longer needed, the organisation has accepted standing trust without lifecycle control. Frameworks such as NIST CSF and zero trust place that responsibility on access governance.

Technical breakdown

Why API attack surface discovery fails in fast-changing environments

APIs are difficult to govern because they are not static assets. Endpoints appear, change, and disappear as applications evolve, which means an inventory built from periodic scans or design documents becomes stale quickly. Many security tools still assume a relatively fixed application perimeter, but API ecosystems are defined by constant change, version drift, and undocumented exposure. That creates the governance gap: teams think they know what exists, but runtime traffic often shows a different picture. Practical control depends on continuous discovery tied to observed traffic and application change events.

Practical implication: build continuous API discovery into change and deployment workflows, not annual review cycles.

How business-logic abuse turns APIs into zero-day exposure

API vulnerabilities are often not classic code flaws. They are business-logic problems, where an attacker abuses how the application processes requests, sequences actions, or trusts identity tokens. Because each API can encode unique business rules, generic vulnerability scanners often miss the exploit path. That is why API issues can behave like zero-days even when no software defect exists in the usual sense. Effective defence has to inspect behaviour, authorisation decisions, and context, not just signatures or known bad inputs. Runtime visibility matters because the abuse is often legitimate-looking traffic with malicious intent.

Practical implication: validate authorisation and business rules at runtime, not only during pre-production testing.

Why API security overlaps with IAM, secrets, and machine identity

APIs are identity-rich systems. They are authenticated by OAuth tokens, API keys, certificates, and service accounts, then authorised through scopes, roles, and business policies. That means API security is inseparable from IAM, PAM, and NHI governance whenever non-human identities call services or exchange data. If credentials are over-privileged, long-lived, or poorly monitored, an API becomes a fast path to data access and privilege escalation. The real control question is not only whether the API is reachable, but whether the identity behind it is least-privileged, well-governed, and observable across its lifecycle.

Practical implication: include API credentials and service accounts in the same lifecycle, review, and rotation controls as human access.

Threat narrative

Attacker objective: The objective is to turn trusted application interfaces into a durable path for data theft, fraud, or operational disruption.

1. Entry begins when attackers discover exposed, undocumented, or poorly monitored APIs that accept valid-looking requests.
2. Escalation follows when they abuse business logic or over-privileged tokens to move beyond intended access boundaries.
3. Impact occurs when the attacker extracts data, triggers unauthorized actions, or disrupts services through the API layer.

NHI Mgmt Group analysis

API security is now an identity governance issue, not a niche application-control problem. APIs are the place where tokens, service accounts, and partner access intersect with business logic, so weak visibility becomes an identity failure as much as an application one. Traditional IAM controls struggle when access is mediated by machine credentials and rapidly changing integrations. The practitioner conclusion is clear: API governance must be treated as part of the access fabric, not a separate security silo.

API churn creates a governance lag that most organisations are not measuring properly. When 11% of environments change APIs daily and 31% weekly, periodic review models cannot keep pace with exposure. The result is a control gap between what security teams think is deployed and what actually exists in runtime. API visibility debt: the longer discovery trails change, the more likely teams are to miss exposed endpoints, stale auth paths, and shadow integrations. Practitioners need continuous inventory and runtime validation to close that gap.

Business-logic abuse is why API risk persists even when conventional vulnerability counts look low. Attackers do not need a memory corruption bug if they can manipulate request flow, abuse trust assumptions, or exploit authorization drift. This is where API security overlaps with NHI governance, because the same credentials that permit service-to-service communication can also enable high-impact misuse when scope is too broad. The conclusion for security leaders is to measure control quality by abuse resistance, not just by defect counts.

The market is moving toward behavioural and identity-aware API controls because static perimeter logic is not enough. That shift aligns with NIST CSF access management expectations and with the reality that machine identities now carry substantial operational privilege. Organisations that still rely on static allowlists, incomplete inventories, or delayed remediation will keep absorbing the same class of incident in different forms. Practitioners should expect API governance to converge with IAM, PAM, and NHI oversight over time.

Security teams should stop treating API protection as a cost centre and start measuring it as risk and resilience infrastructure. The article is right to tie security to business outcomes, but the most important outcome is control consistency across data, application, and identity paths. Where that consistency is absent, revenue growth simply expands the attack surface faster. The practitioner takeaway is to align API security metrics with identity governance metrics, not only with vulnerability counts.

What this signals

API security programmes are converging with identity governance whether teams plan for it or not. The more applications rely on tokens, service accounts, and partner integrations, the more API exposure becomes an IAM and NHI control problem. Teams should expect authorisation review, secrets handling, and service ownership to be evaluated together rather than as separate disciplines.

API visibility debt will become a measurable governance metric. The organisations most at risk are not necessarily those with the most APIs, but those whose inventories, scopes, and runtime controls drift fastest. That means the practical target is not perfect reduction of API count, but continuous reconciliation between what is deployed, what is authorised, and what is observed.

Control maturity will shift from scanning to runtime assurance. Static security checks will still matter, but they will no longer be enough to demonstrate effective governance for machine-to-machine access. Practitioners should prepare to report on active authorisation coverage, secret lifecycle coverage, and the proportion of APIs tied to named business owners.

For practitioners

• Map every API to an owning identity and business process Build an authoritative inventory that links each API to a service account, token issuer, application owner, and data class. This closes the gap between technical exposure and governance accountability.
• Add runtime authorisation checks to high-value APIs Validate scope, role, and request context during live traffic, especially where APIs carry customer data or trigger financial actions. Use runtime policy decisions to catch business-logic abuse that static testing misses.
• Include API credentials in lifecycle and rotation controls Treat API keys, OAuth tokens, and certificates as governed secrets with expiry, rotation, and offboarding rules. Connect them to the same review process used for service accounts and other NHI assets.
• Prioritise APIs with frequent change and weak visibility Use change frequency, undocumented endpoints, and alert blind spots to rank remediation. The fastest-moving APIs are the ones most likely to drift out of control between reviews.

Key takeaways

• API security is an access-governance problem because machine identities, secrets, and business logic intersect at the same control point.
• Salt Security cites 94% of respondents with API security problems in production and 19% with an API-related breach, underscoring how common exposure has become.
• Practitioners need continuous discovery, runtime authorisation, and secret lifecycle controls if they want APIs to support growth without expanding risk.

Key terms

• Runtime Attack Surface: Runtime attack surface is the part of a system that becomes reachable only when code is actually executing, such as parsing, object creation, and process spawning. It matters because static review can miss risks that only appear under specific inputs or production conditions.
• Business Logic Abuse: Business logic abuse occurs when an attacker uses a valid API in a way the application designer did not intend, such as exceeding limits, chaining actions, or misusing workflow assumptions. The API is functioning technically, but governance and policy are failing at the intent layer.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

What's in the full article

SALT's full ebook covers the operational detail this post intentionally leaves for the source:

• Benchmark-style discussion of how API security ties to risk reduction, compliance exposure, and revenue outcomes.
• Business cases for reducing remediation cost and downtime by improving API visibility and runtime detection.
• Practical discussion of how security teams can use AI and ML to automate manual API security workloads.
• Examples of how organisations evaluate whether API protection is reducing control gaps at production scale.

👉 The full SALT ebook expands on risk reduction, expense mitigation, and revenue use cases for API security.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect identity control to broader security programmes where machine access and business risk meet.