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

At a glance

What this is: Salt argues that API security has moved from a breach-response concern to a governance issue because production problems are widespread and API estates change too quickly for static controls.

Why it matters: For IAM, PAM, and application security teams, API governance now sits on the same plane as identity lifecycle and access control because unmanaged APIs create exploitable paths into business systems and sensitive data.

By the numbers:

• 94% of survey respondents had experienced API security problems in production, according to Salt research.
• 19% admitted to an API-related breach, according to Salt research.
• 11% of respondents update their APIs daily, according to Salt research.
• 31% of respondents update their APIs weekly, according to Salt research.

Context

APIs are now part of the control plane for digital business, not just a transport layer between applications. That changes the security problem: if APIs are updated constantly, discovered late, or left outside inventory and runtime monitoring, they become a governance gap rather than a simple coding defect.

For IAM and NHI programmes, the intersection is direct. APIs often expose sensitive functions, rely on service credentials and tokens, and can bypass traditional human-centric access review processes if they are not continuously inventoried and governed.

The pattern described in the source is not unusual for modern application estates. Rapid change, business logic complexity, and distributed ownership make API security drift a structural issue, not an exception.

Key questions

Q: What breaks when API authentication is weak or token governance is missing?

A: The API stops behaving like a controlled interface and starts behaving like a standing access path. Weak authentication and poorly governed tokens let callers appear legitimate while bypassing the business intent behind the endpoint, which increases the chance of data exposure and unauthorised function use.

Q: Why do poorly controlled APIs increase breach and compliance risk?

A: APIs often expose sensitive data and business functions, so weak authentication, missing authorization, or inconsistent policy enforcement can let attackers access records, disrupt services, or move laterally through connected systems. The impact is not only technical. It can create legal liability, regulatory penalties, customer trust loss, and reputational damage when protected data is exposed.

Q: How can security teams tell whether API risk controls are actually working?

A: Look for reduced abuse volume, fewer successful automated attacks, and clearer visibility into which non-human clients are making requests and why. If the control is effective, suspicious traffic should be slowed, challenged, or blocked before it reaches core systems, while legitimate integrations continue to function normally.

Q: How should organisations align IAM with API security governance?

A: They should treat APIs as access paths that carry identity, privilege, and lifecycle obligations. That means service accounts, OAuth applications, and workload tokens need the same ownership, scope review, and retirement discipline that human accounts receive. Without that alignment, API security remains fragmented across teams.

Technical breakdown

Why API blind spots become governance failures

API blind spots emerge when teams do not maintain a current inventory of exposed endpoints, versions, and consumers. That matters because API estates change quickly, and the security model depends on knowing what exists before policy can be enforced. When discovery is incomplete, security tooling sees only fragments of the attack surface, while business logic flaws and excess exposure remain invisible. This is why API security cannot be reduced to periodic testing alone. It requires an always-current view of what is in production, what is externally reachable, and what data or function each endpoint can access.

Practical implication: Practitioners should treat API inventory as a live governance control, not a documentation exercise.

Runtime protection for APIs and machine access

Runtime API security focuses on observing requests, responses, and behaviour while the system is live. That is necessary because many API abuses do not look like classic malware or vulnerability exploitation. They involve authentication abuse, object-level authorisation failures, business logic misuse, or unusual request patterns that only become visible in production. Where APIs are consumed by services, bots, or NHI credentials, runtime controls also need to understand non-human access patterns so legitimate automation is not mistaken for normal human traffic. The control goal is to distinguish expected automation from abuse and to stop unauthorized use before data is collected or functions are manipulated.

Practical implication: Security teams should align runtime detection with API behaviour, service credentials, and authorisation boundaries.

Shift-left API security is not the same as traditional vulnerability management

Traditional vulnerability management is a poor fit for many API issues because API flaws often arise from design and business logic rather than a reusable software bug. One endpoint may expose a function that another should not, or a parameter may reveal more data than intended. That means the security question is not only whether code is patched, but whether the API’s exposed function matches its intended business role. This is where API security becomes governance: ownership, change control, testing, and deployment discipline all affect whether a business API remains safe as it evolves.

Practical implication: Teams should test API authorisation and business logic before release, not rely on generic vulnerability scans after deployment.

Threat narrative

Attacker objective: The attacker wants to use API access to reach data or business functions that should not be exposed through that interface.

1. Entry occurs through an exposed or newly changed API that has not been fully discovered or governed.
2. Credential or authorisation weaknesses allow the attacker to call functions or access data beyond the intended scope.
3. The attacker collects records, manipulates business logic, or expands access across dependent systems.
4. Impact appears as data exposure, compliance failure, or application downtime that reaches beyond the API itself.

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 security is now an access governance problem, not a niche application problem. Once APIs become the front door to customer data, partner integrations, and machine-to-machine workflows, the question is who can call what, under which conditions, and how that access is governed over time. That is an identity and authorisation problem as much as an application problem. Practitioners should stop treating API abuse as an isolated technical event and start treating it as a control-plane failure.

API attack surface control is the named governance gap this article exposes. Constant change means static review models break down quickly, especially where service credentials, tokens, and delegated access are involved. The real issue is not just that APIs exist, but that many organisations cannot reliably answer which APIs are live, who owns them, and which of them can reach sensitive functions. Practitioners should make live API inventory and ownership part of security governance.

Machine access makes API governance harder because human-centric review processes miss service-to-service risk. When APIs are consumed by workloads and automation, the security model depends on non-human authentication, token scope, and function-level authorisation. That is why API governance overlaps with NHI governance in practice. Practitioners should evaluate API security controls as part of both application security and machine identity oversight.

Business logic exposure is the defining failure mode in API security. The article correctly points out that many API weaknesses are not conventional software vulnerabilities. They are design-time authorisation and exposure mistakes that let valid requests do the wrong thing. Practitioners should prioritise policy and function control over scans that only look for code-level flaws.

Continuous discovery is the control that most organisations still underweight. The combination of rapid release cycles and expanding API use means security teams need a persistent view of endpoints, owners, and data paths. Without that, runtime controls and compliance reporting are both built on stale assumptions. Practitioners should align API security governance to continuous asset discovery rather than periodic audit cycles.

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.
• Read next: API Key Management Guide

What this signals

API attack surface control is becoming a standing governance requirement, not a periodic project. When APIs are updated daily or weekly, the control problem shifts from discovery after the fact to continuous visibility into live endpoints, owners, and consumers. Practitioners should expect API governance to merge more tightly with machine identity management and authorisation review.

Security teams will also need to align API controls with broader identity programmes, because many of the highest-risk paths now involve service credentials and delegated access rather than human users. In practice, that means the inventory question and the authorisation question have to be answered together, or runtime protection will remain partial.

For practitioners

• Implement continuous API discovery and ownership mapping Track every exposed API, its owner, its data scope, and its consumer set so security decisions are based on live inventory rather than stale documentation.
• Enforce function-level authorisation checks Validate that each API function only performs the business action it is intended to expose, especially where partner integrations or service accounts can reach sensitive records.
• Bind service credentials to API scope Limit tokens, keys, and service accounts to the minimum API functions and datasets they need, and review that scope whenever integrations change.
• Add runtime detection for abnormal API behaviour Monitor for unexpected call volume, unusual object access, and queries that indicate data harvesting or function abuse rather than normal application use.
• Test API authorisation before deployment Include authorisation and business-logic validation in release checks so exposed functions are verified before they reach production traffic.

Key takeaways

• API security is now a governance issue because fast-changing interfaces create control gaps that static reviews do not close.
• The source cites 94% of respondents with API security problems in production and 19% with an API-related breach, showing that this is already an operational problem at scale.
• Continuous discovery, runtime authorisation, and machine-access scope control are the controls most likely to reduce exposure in modern API estates.

Key terms

• API Attack Surface: The API attack surface is the total set of ways an attacker can interact with exposed application programming interfaces. It includes endpoints, methods, authentication flows, tokens, parameters, error messages, and integrations. In security analysis, it is the full collection of API entry points, trust boundaries, and misconfiguration opportunities that may be abused.
• Runtime API security: Runtime API security is the protection of application programming interfaces while they are actively handling live traffic. It focuses on authenticating callers, authorizing each request, validating inputs, limiting abuse, and detecting anomalous behavior in real time. It also includes securing tokens, enforcing transport encryption, and monitoring API interactions for misuse or data exposure.
• Resource-Level Authorisation: A control pattern where each application or service decides whether a subject should be allowed to act. The decision is based on identity, context, and policy rather than on network location. This is the practical mechanism that makes zero trust enforceable in real environments.
• Tool Access Scope: Tool access scope is the exact set of systems, actions, and data an AI agent is allowed to reach. It should be narrow, explicit, and reviewable, because the risk emerges when the agent can transform a prompt into a real-world operation across connected services.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.