API security governance is failing where identity and automation meet

At a glance

What this is: This is a forward-looking analysis of why API security incidents continue to cluster around access control, automation, and supply chain complexity.

Why it matters: It matters because API abuse now intersects directly with IAM, machine identity, secrets management, and runtime authorization, making isolated control fixes ineffective across modern identity programmes.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Salt's analysis of API security predictions and governance gaps

Context

API security failures rarely start with a single broken control. They usually emerge where authentication, authorization, developer workflow, and third-party integrations intersect, which is why classic perimeter thinking misses the real risk. The primary issue in API security is not just exposure, but the governance gap between what teams believe is protected and what automated callers can still reach.

In identity terms, APIs are now part of the access fabric. Service accounts, API keys, OAuth scopes, and machine-to-machine sessions create the same governance problems as human identities when they are overprivileged, poorly bound, or difficult to observe. That makes API security a practical issue for IAM, PAM, secrets management, and runtime control, not just application teams.

Key questions

Q: How should security teams handle API keys and tokens as part of identity governance?

A: Security teams should treat API keys and tokens as governed identities, not just technical secrets. That means assigning ownership, defining scope, logging use, and removing credentials when the business process ends. The same lifecycle logic used for service accounts applies here, because stale API credentials are a common path to misuse and data exposure.

Q: Why do APIs create so many authorization failures in practice?

A: APIs expose business logic directly, so a valid login does not guarantee a valid action. Failures happen when object-level and function-level checks are inconsistent, when scopes are too broad, or when trust is pushed to the client. Attackers exploit that gap by using legitimate sessions to reach data or functions they should never see.

Q: What do security teams get wrong about API perimeter controls?

A: They assume syntax inspection and request reputation are enough. In BOLA, the payload can be clean, the endpoint can be correct, and the token can be valid while the access decision is still wrong. The real control gap is the missing relationship check between identity and object.

Q: How should teams respond when API abuse is coming through trusted integrations?

A: They should narrow the trust boundary, reduce standing access, and review what each integration can read or invoke. Trusted does not mean safe when the caller is overprivileged or compromised. The immediate priority is to contain blast radius by tightening scopes, rotating exposed secrets, and segmenting high-risk API paths.

Technical breakdown

Why broken authorization dominates API incidents

Broken object level authorization, broken function level authorization, and excessive data exposure persist because APIs often expose business logic directly rather than through coarse application screens. In that model, a caller with a valid session can still enumerate objects, invoke privileged functions, or retrieve fields the business never intended to expose. Authentication only proves identity, not intended scope. The real failure is that authorization logic is too thin, too inconsistent, or too dependent on the client behaving correctly. This is why API incidents often look like ordinary access from the outside while still producing major abuse inside the trust boundary.

Practical implication: enforce object and function checks server-side on every call, not just at login.

How machine identity and secrets management widen the attack surface

Modern API ecosystems rely on secrets, tokens, certificates, and service accounts that operate without interactive challenge. That makes them easy to embed in code, configuration, CI/CD pipelines, and third-party integrations, but also difficult to observe and rotate consistently. Once an attacker acquires a credential used by automation, they can often move through trusted interfaces without triggering the control assumptions built for human users. This is where machine identity becomes a governance issue. The question is not whether the secret exists, but whether it is scoped, monitored, rotated, and revoked as a first-class identity object.

Practical implication: treat API credentials as governed identities with lifecycle, scope, and revocation requirements.

Why attack chains now matter more than single flaws

The article’s broader warning is that attackers increasingly chain multiple small weaknesses into a larger path to impact. A weak auth control, an exposed API, a third-party dependency, and noisy logging may each look manageable in isolation. Combined, they create a route for data loss, privilege escalation, account takeover, or supply chain abuse that is far harder to catch in time. Zero Trust principles help, but only if they are implemented across the full call sequence and paired with runtime analytics that can correlate machine and user behaviour across a session.

Practical implication: instrument API telemetry for chained behaviour, not just individual alerts.

Threat narrative

Attacker objective: The attacker aims to turn trusted API access into broad operational control, data theft, or downstream compromise without breaking obvious perimeter defenses.

1. Entry begins with exposed or weakly protected APIs, including leaky interfaces, static credentials, or third-party integrations that accept trusted calls.
2. Escalation follows when attackers abuse broken authorization, stolen tokens, or overbroad scopes to access objects, functions, or adjacent systems beyond intended use.
3. Impact occurs through data exposure, account takeover, privilege escalation, remote code execution, or supply chain compromise that is difficult to distinguish from legitimate API traffic.

NHI Mgmt Group analysis

API security is now an identity governance problem, not just an application security problem. The article is right to connect API incidents with authentication, authorization, and machine identity because API calls are effectively identity decisions at runtime. When service accounts, OAuth scopes, and static secrets are left outside lifecycle governance, the organisation creates privileged pathways that conventional app testing cannot fully see. Practitioners should treat API governance as a shared IAM and runtime responsibility.

Standing authentication material is the core failure mode behind many API abuses. API keys, tokens, and embedded secrets create persistent trust that attackers can reuse long after the original deployment context has changed. That is a governance failure because the access object outlives the business need, especially across CI/CD, third-party integrations, and delegated services. The practical conclusion is that standing secret exposure windows must be collapsed, not merely monitored.

API attack chains expose the limits of control-by-point-solution thinking. WAFs, gateways, and access controls each solve part of the problem, but none of them alone provide full context across object access, function execution, and session behaviour. That is why API security needs continuous observation and policy enforcement across the full call sequence. Practitioners should design for correlated runtime control, not isolated inspection points.

Shift-left alone cannot govern API risk once automation is the dominant consumer. The article shows why pre-production testing misses abuse that only appears in real sessions, real integrations, and real third-party trust relationships. That is a broader governance signal for identity programmes: lifecycle controls, anomaly detection, and privilege scope must extend into runtime. Practitioners should assume the production API layer will surface failures that design-time review never sees.

API dependency sprawl: APIs now behave like dependencies in the supply chain sense, which means inventory, trust, and external coupling all need governance together. Once an organisation accepts that API enablement is part of digital supply chain design, the security model shifts from perimeter defence to managed trust relationships. Practitioners should inventory APIs as first-class dependencies and apply lifecycle control to their credentials and integrations.

What this signals

API security teams should expect the governance conversation to move closer to IAM and secrets lifecycle control. The practical signal is that runtime abuse and credential exposure are no longer separate problems, especially when a single leaked secret can remain active long enough to be reused across partners, pipelines, and automation.

Trusted-call risk: the next stage of API maturity is not simply more inspection at the edge but more disciplined control of who and what can call an API in the first place. That means tighter scope design, better credential ownership, and behaviour analytics that can distinguish legitimate machine traffic from chained abuse.

The reader takeaway is that API programmes will increasingly be judged by how well they can inventory machine identities, reduce standing access, and correlate usage across sessions. Teams that separate application security from identity governance will keep missing the same failure modes in different forms.

For practitioners

• Map API credentials to identity lifecycles Inventory API keys, OAuth clients, service accounts, and certificates as governed identities. Assign owners, expiration rules, revocation triggers, and rotation cadence so static authentication values do not persist beyond their business purpose.
• Enforce server-side authorization on every object and function Review API handlers for broken object level authorization and broken function level authorization. Validate access on the server for each request, not in the client, gateway, or front-end logic alone. Use least-privilege scopes for internal and third-party callers.
• Correlate runtime signals across sessions Instrument telemetry to link user and machine behaviour across an entire session, including unusual call sequences, privilege changes, and data access patterns. Feed these signals into detection so chained abuse is visible before impact.
• Treat third-party integrations as trust boundaries Classify SaaS connections, partner APIs, and supplier integrations as separate trust domains. Review what data each integration can read, write, or invoke, and remove assumptions that external API callers are inherently safe.

Key takeaways

• API incidents keep recurring because access control, secrets, and trust boundaries are governed in isolation rather than as one runtime problem.
• The operational signal is not just exposure but delay: leaked secrets can remain exploitable long enough to turn into broader abuse.
• Practitioners need API governance that combines identity lifecycle control, server-side authorization, and correlated runtime detection.

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.
• 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.
• Standing Secret Exposure: A condition where a credential persists long enough to be reused, copied, logged, or extracted from state, memory, or pipeline artefacts. This is the core governance problem in many IaC environments because the secret survives beyond the action that needed it.

What's in the full article

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

• The article walks through the specific API security predictions that informed the analysis, including supply chain risk, authentication failures, and runtime control gaps.
• It expands on why API gateway, WAF, and access-control assumptions break down across first-party and third-party integrations.
• It includes the author’s discussion of how machine assistance and runtime correlation change detection expectations for API abuse.
• It outlines the governance and compliance implications that make APIs relevant to GRC and privacy teams.

👉 Salt's full article covers the API attack patterns, identity failures, and runtime control limits in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps practitioners connect identity controls to the broader security programme that APIs now depend on.