API security is now an identity and governance problem

At a glance

What this is: API security is framed as an identity and governance issue because discovery gaps, authorization flaws, and business logic weaknesses let attackers abuse legitimate API flows.

Why it matters: It matters to IAM, NHI, and security teams because APIs now carry delegated access across business processes, so governance has to extend to every token, call, and permission path.

Context

API security is the discipline of controlling who or what can call an interface, what data or functions those calls can reach, and how the system verifies that access. The article argues that the problem has moved beyond perimeter-style protection because APIs now expose core business processes, hidden endpoints, and delegated access paths that traditional controls often miss.

For IAM and NHI practitioners, the overlap is real: API tokens, service accounts, and application-to-application permissions often become the mechanism by which business logic is abused. That makes API governance part of identity governance, not a separate technical silo. In mature environments, the attack surface is less about one API and more about the unmanaged relationships between APIs, credentials, and workflow permissions.

Key questions

Q: Where does API security fail in practice when discovery is incomplete?

A: It fails when teams cannot see every endpoint, owner, and calling identity, because hidden APIs bypass the controls that would normally enforce authentication, authorization, and monitoring. Unknown endpoints often become unmanaged access paths, which is why discovery must be continuous rather than a one-time project.

Q: Why do valid API requests still create breach risk?

A: Valid API requests still create breach risk because authentication proves the caller is known, not that the caller is entitled to the specific object. If the application accepts an identifier or booking code as proof of access, attackers can modify that value and harvest data without tripping traditional perimeter controls.

Q: How can teams tell whether API governance is actually working?

A: A working programme can answer four questions quickly: who owns the consumer, what it can access, where the policy is enforced, and how the call is logged. If any of those answers differ across protocols or gateways, the control model is fragmented and needs consolidation.

Q: Should organisations treat APIs as identity and access control points?

A: Yes. APIs increasingly carry user, service, and third-party access decisions, so they function as active identity control points. That means token scope, response minimisation, delegation, and lifecycle management all matter. If those controls are weak, the API becomes a pathway for unauthorised disclosure even when authentication is intact.

Technical breakdown

Why business logic flaws evade standard API security tests

Business logic vulnerabilities happen when an API behaves exactly as coded but not as intended by the business. Broken object-level authorization and broken function-level authorization are common examples: the request format is valid, but the caller should not be able to reach that object or function. These issues are hard to detect because scanners and basic vulnerability tools look for generic technical flaws, not whether the workflow itself violates access rules. That means the security problem is often governance over application behaviour, not just code quality.

Practical implication: Test APIs against intended workflows and permissions, not only against technical injection and misconfiguration checks.

How API discovery becomes an identity control problem

Discovery is the prerequisite for governance. If teams do not know an API exists, they cannot inventory its authentication method, map its tokens or service accounts, or apply policy to it. Undocumented APIs are especially dangerous because they create shadow access paths that operate outside normal review and lifecycle controls. In identity terms, this is an entitlement visibility failure: access exists, but the organisation cannot reliably see who or what has it, why it has it, or whether it should still exist.

Practical implication: Build continuous API inventory processes that connect each endpoint to its caller identity, authorization model, and owner.

Why Zero Trust only works when API trust is verified at runtime

Zero Trust assumes no request is trusted by default, so every API call should be authenticated and authorized in context. In practice, that means tokens, workload identities, and delegated permissions must be evaluated continuously across distributed environments, including hybrid and multi-cloud estates. The challenge is that many APIs are designed for speed and interoperability, while Zero Trust demands explicit verification on every transaction. When those models drift apart, access paths become more permissive than the architecture claims.

Practical implication: Enforce contextual authorization and token governance at the point of request, not only at login or deployment time.

Threat narrative

Attacker objective: The objective is to turn legitimate API behaviour into unauthorized access, data theft, or operational disruption without triggering obvious perimeter alerts.

1. Entry often begins through an exposed or undocumented API endpoint that security teams have not inventoried or governed.
2. The attacker then abuses weak authentication or authorization logic to reach objects, functions, or business flows they should not control.
3. Once access is established, the attacker can extract data, impersonate legitimate users, or trigger denial-of-service conditions that affect core business operations.

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 has become an identity governance problem, not just an application security problem. Modern APIs often carry the permissions that move data and trigger business actions, so authorization failures are really governance failures over delegated access. When a token or service account can reach more than it should, the API is exposing an access model, not just an endpoint. Practitioners should treat API authorization as part of identity governance.

API discovery is the new inventory control point for machine access. An unknown API is an unknown entitlement surface, and unknown entitlements are the opposite of Zero Trust. This is where NHI governance intersects directly with API security, because every undocumented integration tends to be backed by a credential, token, or workload identity that no one is reviewing. Practitioners should assume hidden APIs imply hidden identities until proven otherwise.

Business-logic abuse is the named concept teams need to sharpen. The weak point is not always technical compromise but misuse of a valid flow in a way the business never intended. That makes the control objective broader than blocking attacks at the perimeter. Practitioners should test whether workflows enforce intended privilege boundaries, not just whether they accept valid syntax.

Zero Trust breaks down when request-time decisions are not aligned with API design. Strong authentication is not enough if an authenticated caller can still reach an object or action it should not see. The governance task is to bind policy, token scope, and business authorization together across the whole API estate. Practitioners should verify that runtime authorization matches the policy on paper.

Regulated industries face a compounded problem because API security failures become compliance failures quickly. When APIs move regulated data, access control, monitoring, and auditability are not optional implementation details. The practical issue is not whether APIs are important, but whether teams can prove control over every sensitive transaction path. Practitioners should map API governance to privacy and regulated-data obligations.

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.
• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: API Key Management Guide

What this signals

API security now behaves like an identity perimeter. The practical boundary is no longer the application screen or the login event, but the sequence of calls made by tokens, service accounts, and delegated permissions. That means security teams need to govern API access as an identity lifecycle problem, not just as code-level hardening.

API inventory is becoming the control plane for Zero Trust in software estates. If an organisation cannot enumerate its APIs, it cannot reliably enforce least privilege, audit access, or separate approved integrations from shadow ones. The next maturity step is continuous visibility into machine access paths, not periodic point-in-time review.

Business-logic abuse is the API risk that most often survives conventional scanning. Standard tools are good at signatures and misconfigurations, but they do not understand whether a workflow lets an authenticated caller take an action the business never intended. Practitioners should expect the hardest API problems to sit at the boundary between authorization and process design.

For practitioners

• Inventory every production API and undocumented endpoint Build a live inventory that ties each API to an owner, authentication method, token type, and business function so nothing remains outside governance.
• Map API access to specific identities and scopes Trace every service account, token, and delegated permission to the exact API actions it can perform, then remove scope that exceeds business need.
• Test business workflows for authorization bypass Use adversarial testing to validate object-level and function-level authorization across real user journeys, not just against generic injection cases.
• Apply runtime verification to high-risk API calls Require contextual checks for sensitive requests, especially where APIs move regulated data or trigger privileged actions in hybrid and multi-cloud environments.

Key takeaways

• API security is now a governance issue because access often lives in tokens, service identities, and workflow logic rather than in a single perimeter control.
• Discovery gaps and business-logic flaws are the conditions that let legitimate API traffic become unauthorized access or data exposure.
• Teams that want effective Zero Trust for APIs need request-time authorization, continuous inventory, and testing that follows real business flows.

Key terms

• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Broken Function Level Authorization: A failure where an API allows a caller to invoke a function reserved for a more privileged role. The problem appears when the API checks whether a user is logged in but not whether they are allowed to perform that action. It is a privilege boundary failure at the application control layer.
• API Discovery: API discovery is the process of finding and cataloging APIs across an environment so security teams know what exists, what data it exposes, and how it behaves. It is essential because shadow, zombie, unmanaged, and third party APIs are frequent blind spots that attackers can exploit without being noticed.
• Business logic vulnerability: A business logic vulnerability is a flaw in how an application’s workflow or rules are enforced, allowing an attacker to misuse a process rather than break code directly. These issues often evade signature-based tools because the weakness lies in authorisation, sequence, or state handling.

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 identity controls to the access paths that modern APIs depend on.