TL;DR: Edge controls can block obvious traffic, but they miss shadow APIs, third-party API flows, and slow-moving abuse patterns such as BOLA, according to Salt. API security needs discovery, posture governance, and runtime monitoring because perimeter enforcement alone cannot govern what it cannot see.
At a glance
What this is: This is an analysis of why WAFs, API gateways, and CDNs cannot fully secure APIs at the perimeter and why discovery plus runtime detection are required.
Why it matters: It matters because API sprawl, undocumented endpoints, and third-party integrations create governance gaps that also affect identity, entitlement, and machine-to-machine trust decisions.
👉 Read Salt's analysis of why API security cannot stop at the edge
Context
API security fails when organisations assume edge enforcement can see every API, every caller, and every abuse pattern. In practice, undocumented endpoints, direct workload-to-workload traffic, and slow credential abuse all sit outside the perimeter view, so discovery and behavioural monitoring become part of the control plane rather than an optional add-on. For IAM teams, the identity question is who or what is authorised to invoke each API and how that access is verified over time.
This matters to identity governance because APIs are now a common execution surface for non-human identities, third-party integrations, and delegated access. When an internal service or external SaaS call bypasses the edge, the organisation loses the opportunity to apply consistent authentication, authorisation, and audit controls. Salt’s article is typical of a broader and now familiar pattern: perimeter security is necessary, but it is not sufficient for API governance.
Key questions
Q: How should security teams discover APIs that bypass gateways and WAFs?
A: Use continuous discovery that blends traffic analysis, service mapping, and inventory reconciliation. Do not rely on perimeter tools alone, because they only see what reaches the edge. Any endpoint found in production but missing from approved inventories should be treated as a governance exception until ownership, authentication, and authorization are defined.
Q: Why do third-party API calls create identity governance risk?
A: Because they move sensitive data and delegated authority outside the control points that IAM teams usually monitor. When internal workloads call external APIs directly, the organisation may lose visibility into authentication context, logging, and downstream handling. That makes service account scope, token lifecycle, and outbound monitoring central governance controls.
Q: What do teams get wrong about detecting BOLA attacks?
A: They often look for a single malicious request instead of a pattern of repeated, low-signal access over time. BOLA usually depends on identifier manipulation and gradual enumeration, so it is missed by fast perimeter checks. Teams need cross-session correlation and object-level anomaly detection to spot it early.
Q: What should organisations do when an API is discovered outside approved controls?
A: Treat it as an unmanaged production asset and suspend blind trust until ownership, exposure, and authorisation are verified. Then determine whether the API handles identity data, secrets, or sensitive business functions, because that changes both the monitoring threshold and the remediation priority.
Technical breakdown
Why edge controls miss shadow APIs
WAFs, API gateways, and CDNs only inspect traffic that actually passes through them. Shadow APIs, direct service endpoints, and misconfigured routes can be deployed into production without being discovered by perimeter tooling. That creates a governance blind spot because the control point is upstream of the traffic, not inside the application or service mesh. Discovery therefore has to combine traffic analysis, application mapping, and inventory reconciliation to identify endpoints that are otherwise invisible.
Practical implication: build continuous API discovery that compares observed traffic against approved service inventories.
Why third-party API calls escape perimeter visibility
Modern applications frequently call external APIs directly from workloads, not through the organisation’s edge. Those flows can carry sensitive data, tokens, or embedded identifiers while avoiding the tools that sit at the network boundary. The security problem is not only exfiltration, but also loss of accountability, because the organisation may not see how a downstream service handles or logs the data it receives. This creates a hybrid trust problem spanning application security and identity governance.
Practical implication: inspect east-west and outbound application traffic, not just inbound edge traffic, for sensitive API interactions.
How BOLA evades fast perimeter detection
Broken Object Level Authorization is an access control failure where a caller can change an object identifier and reach data it should not see. Because the attack often unfolds slowly through repeated requests and low-and-slow enumeration, single-request inspection at the edge is not enough. Effective detection needs long-horizon correlation across sessions, identities, and object access patterns. In identity terms, the issue is not only authentication, but whether authorisation remains valid for each specific object and action.
Practical implication: correlate object access over time and alert on identifier enumeration or cross-account access patterns.
Threat narrative
Attacker objective: The attacker aims to reach data or actions that perimeter controls never observed, while remaining outside normal detection and audit paths.
- Entry occurs through a shadow API, third-party integration, or direct workload-to-workload call that bypasses the edge.
- Credential or object-level access is then abused through repeated requests, hidden data flows, or unauthorised identifier changes.
- Impact follows as sensitive data is exposed, logged, or accessed without the organisation having full visibility or auditability.
NHI Mgmt Group analysis
Perimeter-first API security creates a visibility gap, not a governance model. WAFs and gateways are enforcement points, but they cannot govern what bypasses them. That means shadow endpoints, internal service calls, and third-party API flows become unmanaged by default. The governance failure is not just incomplete detection, but a broken assumption that the edge is the system boundary.
API security is now an identity problem as much as an application problem. Every API call represents a machine or delegated identity exercising authority over data and functions. Once those calls bypass the edge, teams lose consistent control over authentication context, entitlement scope, and audit trails. NHI governance becomes relevant wherever service accounts, tokens, or workload identities are used to call APIs.
Long-horizon abuse patterns require long-horizon controls. BOLA and similar attacks rarely look like a single malicious event at the perimeter. They emerge from repeated, low-signal requests that only become visible when correlated across time, identity, and object access. That shifts the control objective from blocking packets to detecting behavioural drift before data exposure becomes systemic.
API discovery should be treated as an inventory integrity function. A discovered API that is not in the approved inventory is a governance exception, not just a technical observation. Shadow API sprawl: this is the state where undocumented or directly deployed APIs expand the attack surface faster than approval and review processes can follow. Practitioners should treat undocumented endpoints as entitlements that need lifecycle ownership.
The broader market signal is convergence between API security and identity governance. Discovery, posture governance, and runtime protection are increasingly inseparable because authorization decisions depend on knowing what exists, who calls it, and what that caller is allowed to do. For identity teams, the practical conclusion is that API security cannot be delegated entirely to edge tooling or left outside IAM and PAM oversight.
What this signals
Shadow API governance is becoming a practical IAM and security architecture issue, not just an application inventory problem. As more workloads call third-party services directly, teams need to map API callers to workload identities, token ownership, and approval boundaries. The control question is whether the organisation can prove who or what was authorised to invoke each API at the moment of access.
The programme signal is that edge-only controls will keep underperforming against low-and-slow abuse patterns. Teams should expect more demand for correlation across application telemetry, identity context, and object-level access logs, especially where non-human identities are involved. For identity-led organisations, that means runtime visibility becomes part of the governance baseline, not a specialised add-on.
Practitioners can use the NIST Zero Trust model to frame this shift: trust should be evaluated per request, per identity, and per resource, not assumed at the perimeter. That also aligns with API inventories treated as living assets rather than static documentation, which is the only defensible way to manage direct service calls and third-party integration risk.
For practitioners
- Inventory every exposed and internal API Reconcile gateway logs, service catalogs, and application telemetry to find undocumented APIs, direct routes, and shadow endpoints that bypass perimeter controls.
- Monitor east-west and outbound API traffic Inspect workload-to-workload and third-party API calls for sensitive payloads, token use, and logging risks that never appear at the edge.
- Correlate object access across time Detect BOLA-style abuse by linking repeated identifier changes, cross-account requests, and low-and-slow enumeration into a single behavioural view.
Key takeaways
- API security cannot be reduced to edge enforcement because shadow endpoints and direct service calls bypass the perimeter entirely.
- The core risk is governance blindness, where organisations lose visibility into who called which API, when, and with what authority.
- Discovery, object-level monitoring, and identity-aware runtime controls are the practical response to perimeter gaps in API security.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST-SP 800-207 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0007 , Discovery; TA0006 , Credential Access; TA0009 , Collection | The article focuses on discovery gaps and low-signal abuse patterns that map to ATT&CK tactics. |
| NIST CSF 2.0 | PR.AC-4 | API access scope and authorization are central to the access-control gap discussed here. |
| NIST SP 800-53 Rev 5 | AC-3 | Access enforcement for objects and services is the core control challenge in BOLA and shadow APIs. |
| NIST-SP 800-207 | Section 3.1 | The article aligns with per-request verification and reduced implicit trust in API access paths. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Third-party API flows and service identities are part of broader non-human identity governance. |
Map shadow API and BOLA risks to ATT&CK tactics and prioritize detections around discovery and collection.
Key terms
- Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
- 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.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- Practical examples of how edge tools miss undocumented APIs and direct workload traffic
- Salt's explanation of posture governance for APIs across the lifecycle
- Runtime detection examples for low-and-slow API abuse such as BOLA
- Implementation-oriented detail on discovering and securing third-party API dependencies
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and identity lifecycle control. It helps practitioners connect API access, delegated authority, and identity governance across modern environments.
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
