API security governance is failing where identity and automation meet

At a glance

What this is: Salt argues that API security failures now emerge at the intersection of IAM, automation, and third-party integration, where broken authorization and static credentials outpace conventional review and detection.

Why it matters: IAM, PAM, NHI, and application security teams need to treat API access as a governance problem, because authenticated abuse and machine-to-machine trust can bypass controls that only look for external attack paths.

Context

API security fails when teams assume that authentication alone creates trust. In practice, APIs sit inside identity flows, automation pipelines, and partner integrations, so weak authorization, static secrets, and overbroad scopes can turn ordinary machine access into a control failure.

The article’s central concern is governance rather than exposure volume. That makes it relevant to IAM, NHI, and PAM programmes because the same control gaps appear whenever services, scripts, and third parties are allowed to act with persistent or poorly bounded credentials.

For practitioners, the important point is that API protection cannot be separated from identity lifecycle, runtime monitoring, and integration design. Salt’s analysis reflects a broader pattern: once machine access is normalised, review and blocking controls often arrive too late.

Key questions

Q: What breaks when authentication and authorization are conflated in API security?

A: The system starts treating identity proof as if it were permission. That usually produces overly broad access, weak auditability, and credential handling that becomes the only guardrail. In practice, an authenticated caller may still be able to do far more than the business intended if authorization is not enforced as a separate decision.

Q: Why do machine credentials increase API security risk so quickly?

A: Machine credentials are hard to challenge interactively, easy to reuse across systems, and often remain valid far longer than their intended task. When secrets are embedded in code or configuration, the resulting access path can persist across deployments and integrations. That turns one automation choice into a standing privilege problem.

Q: What are the warning signs that API abuse is being chained across services?

A: The main warning signs are unusually broad access after a normal login, repeated calls across nested endpoints, and activity that looks legitimate at each individual step but not across the whole session. Teams should look for correlated identity and API behaviour, not isolated alerts, because chained abuse is designed to stay below single-control thresholds.

Q: How should security teams govern APIs that support third-party and partner integrations?

A: They should treat partner-facing APIs as governed access paths, not just technical interfaces. That means maintaining endpoint inventories, mapping exposed data, applying policy based on business context, and monitoring for behavioural deviation. Where APIs underpin regulated workflows, IAM, application security, and compliance teams should share the same policy model and response process.

Technical breakdown

Why API authorization fails in authenticated sessions

APIs often fail after authentication succeeds, not before. Broken object-level authorization, broken function-level authorization, and excessive data exposure let an authenticated caller act outside its intended scope, which is why API abuse so often looks legitimate in logs. The core weakness is that access decisions are applied too coarsely or too late, especially when multiple services, nested calls, and partner integrations are involved. In those cases, a valid token does not mean a valid action. Practical implication: enforce object and function authorization at the transaction boundary, not just at login.

Practical implication: enforce object and function authorization at the transaction boundary, not just at login.

How machine identity and static secrets widen the blast radius

API automation depends on machine identity, usually through secrets, tokens, or embedded keys. When those values are static, reused, or embedded in code and configuration, they become durable access paths that bypass human-centric controls such as MFA prompts or interactive review. Salt’s analysis also highlights that machine processes cannot be challenged the way a user can, which means identity governance has to move earlier in the lifecycle. The question is not only who can authenticate, but how long that credential should remain useful. Practical implication: reduce standing credential value by shortening token lifetime and removing embedded secrets from workflows.

Practical implication: reduce standing credential value by shortening token lifetime and removing embedded secrets from workflows.

Why third-party integration turns API governance into supply chain control

Modern API estates are made of connected services, partner calls, and outsourced components, so one weak integration can expand into a supply chain problem. Salt notes that attackers abuse this complexity by chaining exploits across infrastructure APIs, partner APIs, and automation layers until the original point of entry is hard to distinguish from ordinary traffic. That makes API inventory, dependency understanding, and blast-radius control central governance issues, not documentation exercises. Practical implication: treat partner and system APIs as controlled dependencies with explicit ownership, not invisible plumbing.

Practical implication: treat partner and system APIs as controlled dependencies with explicit ownership, not invisible plumbing.

Threat narrative

Attacker objective: The attacker aims to turn legitimate API trust into durable access, broader privileges, and high-value data or control over connected systems.

1. Entry occurs through exposed or trusted APIs, often inside authenticated sessions rather than by breaking perimeter defences.
2. Credential access or abuse follows when static keys, embedded secrets, or weak authentication are reused across services and automation paths.
3. Escalation happens through broken authorization, overbroad scopes, or chained API calls that let the attacker move beyond the original function.
4. Impact includes data exposure, account takeover, supply chain compromise, or remote code execution depending on which API path is abused.

Breaches seen in the wild

• ArtiPACKED 2024: Unit 42 found public GitHub Actions artifacts in major open source projects leaking live GITHUB_TOKENs, runtime tokens and cloud tokens.
• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

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 governance fails when identity decisions are treated as a login problem instead of a runtime authorisation problem. Salt’s analysis shows that most damaging abuse happens after a session is already trusted, which means the real control gap is not authentication alone but authorization drift across objects, functions, and service boundaries. Practitioners should treat API access as continuous entitlement governance, not a one-time identity check.

Machine identity makes API security an NHI governance issue, not just an application security issue. Static keys, embedded secrets, and automation tokens create standing access that conventional user-centric controls do not manage well. This is the same structural problem NHIs create elsewhere: persistent credentials, weak lifecycle ownership, and limited visibility into who or what is actually acting. Practitioners need to govern machine authentication with the same seriousness as privileged human access.

API supply chains create a governance blind spot because connected services are often managed as integrations, not dependencies. Once partner APIs, infrastructure APIs, and outsourced components are chained together, the attack surface is no longer a single application boundary. API dependency sprawl: this is the condition where service-to-service trust expands faster than inventory, ownership, and control design. Practitioners should bring explicit dependency ownership and blast-radius assumptions into API governance.

Runtime enforcement is becoming the decisive control because static review cannot keep up with automated abuse. Salt’s discussion of scraping, credential stuffing, brute force, and chained abuse shows why pre-production checks are not enough. Detection has to correlate user and machine behaviour during a session, otherwise the abuse looks normal until impact occurs. Practitioners should align API governance with continuous monitoring and blocking controls.

GRC teams now have a legitimate role in API security because audit language, privacy exposure, and runtime control all intersect here. The article makes clear that compliance language alone is not enough if controls remain passive or misaligned with actual API behaviour. Practitioners should use governance reviews to test whether APIs are only documented, or actually controlled.

From our research library:

• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: Privileged Access Management Guide

What this signals

API governance is converging with IAM, NHI, and PAM because the most important failures now happen after a caller is already trusted. That shifts the control question from simple authentication to whether identities, scopes, and runtime decisions are still aligned once automation and third-party integrations start chaining together.

API dependency sprawl: this is the governance gap created when service-to-service trust expands faster than inventory, ownership, and revocation processes. Practitioners should expect this pattern to become more visible as partner integrations, cloud-native design, and machine-to-machine authentication keep growing.

The control model has to move toward continuous evaluation of behaviour, not just pre-release checks, because static review cannot keep pace with authenticated abuse that looks normal at the session level.

For practitioners

• Inventory APIs as governed dependencies Classify first-party, partner, infrastructure, and internal APIs together so ownership, exposure, and trust assumptions are visible in one control plane.
• Tighten object and function authorisation Review BOLA and BFLA exposure by testing whether authenticated callers can access objects, actions, or nested queries beyond their intended scope.
• Remove static authentication values from automation Replace embedded API keys and long-lived secrets with short-lived machine credentials and owner-managed rotation, especially in CI/CD and partner integrations.
• Correlate user and machine behaviour at runtime Use detection logic that ties API calls, identity context, and session behaviour together so chained abuse is visible before data loss or privilege escalation.

Key takeaways

• API incidents are increasingly shaped by authorization failure, static machine credentials, and chained abuse inside trusted sessions rather than by simple exposure alone.
• Third-party integrations and automation make the blast radius of an API mistake much larger, which is why inventory and ownership matter as much as gateway policy.
• Continuous runtime correlation is the control shift that matters most, because API abuse often becomes visible only when identity, session, and call patterns are analysed together.

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.
• API Dependency: An API that a business process, application, or integration relies on to function. Treating APIs as dependencies means they require ownership, inventory, trust boundaries, and lifecycle controls, not just perimeter protection or gateway policy.

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 automation, privilege, and lifecycle risk across modern programmes.