API security beyond the edge: why discovery and runtime matter

At a glance

What this is: This article argues that API security fails when it stops at the edge, because hidden endpoints, third-party integrations, and delayed abuse patterns require discovery and runtime visibility.

Why it matters: IAM, API, and cloud security teams need to treat API exposure as a lifecycle and visibility problem, not just a perimeter control problem, especially where machine-to-machine access and sensitive data flows intersect.

Context

API security is not just about blocking traffic at a gateway or firewall. The core governance gap is visibility: organisations can protect what they can see, but edge tooling cannot govern shadow APIs, direct service-to-service calls, or external API dependencies that bypass the perimeter.

That creates a practical blind spot for identity and access teams as well. API calls increasingly carry machine credentials, tokens, and delegated access across internal and third-party systems, so discovery and runtime governance become part of the identity control surface, not just an application security issue.

Salt's argument is typical of modern API risk discussions: the failure is not a lack of edge enforcement, but an architecture that assumes all relevant traffic passes through the edge.

Key questions

Q: What breaks when API protection stops at the boundary?

A: Boundary-only protection fails when legitimate requests are accepted but the system still allows them to expose data, trigger unintended actions, or fan out into unsafe downstream workflows. The weakness is not access validation. It is the lack of control over what authenticated traffic can do after entry, especially in distributed architectures and agent-driven flows.

Q: Why do shadow APIs and third-party flows increase API risk?

A: They create access paths that traditional edge controls cannot inspect consistently. Shadow APIs may bypass gateways entirely, while third-party calls often move data and credentials between internal workloads and external services outside perimeter view. That makes authorisation, logging, and revocation harder to govern, especially when machine credentials are involved.

Q: What are the signs that BOLA detection is failing?

A: Warning signs include repeated requests across similar object IDs, account-level access that changes slowly over time, and legitimate-looking sessions that accumulate access to records they should not reach. If detection only focuses on single requests or source reputation, BOLA-style abuse can continue unnoticed. Behavioural correlation is the missing capability.

Q: How should security teams secure public APIs without relying only on perimeter controls?

A: Security teams should treat API security as application-layer protection, not just network filtering. Public APIs need access control, authentication, input validation, privacy controls, and continuous detection for abuse patterns such as stolen tokens, credential stuffing, and reverse engineering. WAFs, gateways, and IAM help, but they do not fully protect each API’s logic or data exposure risks.

Technical breakdown

Why edge tools miss shadow APIs

WAFs, gateways, and CDNs only inspect traffic that traverses them. Shadow APIs can be deployed directly into production, exposed through alternate routes, or reached by internal workloads without ever touching the edge control point. That means discovery based only on perimeter observation will always be incomplete. The security problem is not merely undocumented endpoints. It is the mismatch between where teams assume traffic flows and where API calls actually terminate, especially in modern microservice and mobile back-end designs.

Practical implication: build discovery from inside the environment, not only from perimeter logs, so undocumented APIs are found before they are exploited.

How third-party API flows bypass governance

Third-party API consumption often happens server to server, where one internal workload calls an external service directly. In that model, the perimeter sees little or nothing, yet the organisation may still be exposing customer data, authentication tokens, or business logic to another system. This is where API security intersects with identity governance: the calling workload, its token scope, and the receiving service all matter. If teams do not inventory these delegated flows, they cannot assess whether the access is necessary, logged, or revocable.

Practical implication: inventory third-party API dependencies alongside service credentials and token scopes, not as a separate procurement list.

Why BOLA needs runtime analysis, not just rules

Broken Object Level Authorization, or BOLA, is often a low-and-slow attack pattern. An attacker may test object identifiers over time, looking for a weak authorisation decision that reveals data tied to another user or tenant. Simple edge rules are poor at this kind of behaviour because the malicious pattern is distributed across requests and sessions. Runtime monitoring is therefore about correlation, context, and behaviour over time, not just request filtering. This is also why API security cannot be reduced to one-off misconfiguration checks.

Practical implication: add behavioural detection for repeated access patterns and object enumeration, especially where the same token is used across many requests.

Threat narrative

Attacker objective: The objective is to reach data or business functions through API paths that perimeter controls do not observe well enough to stop.

1. Entry occurs through a shadow API, a directly exposed endpoint, or a third-party API flow that never passes through the edge controls.
2. The attacker or abusive user then probes identifiers, objects, or service interactions over time, using normal-looking requests to test authorisation boundaries.
3. When the authorisation weakness is found, data is accessed or business logic is abused without triggering perimeter-focused detections.

Breaches seen in the wild

• McHire default password flaw 2025: A forgotten test admin account with the password 123456 and an API flaw exposed McDonald's McHire applicant records to researchers.
• Capital One breach 2019: A misconfigured firewall handed over its cloud role credentials, and an over-privileged role exposed data on 106 million people.

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 discovery has become an identity visibility problem, not just an application inventory problem. If teams do not know which APIs exist, they cannot know which credentials, tokens, or delegated trust relationships are in scope. That makes discovery the first governance control, not a side task. Practitioners should treat undocumented endpoints as unmanaged access paths.

Runtime monitoring is the control that compensates for slow abuse patterns. Perimeter enforcement is well suited to obvious abuse, but not to BOLA-style activity that unfolds over many requests and sessions. The governance lesson is that detection has to follow behaviour, not just origin. Practitioners should move from single-request thinking to session-level and object-level analysis.

Third-party API dependence expands the attack surface beyond the organisation's edge. Once internal workloads talk directly to external services, the security question becomes who can call what, with which token, and for what purpose. That is an access governance issue as much as an API issue. Practitioners should include third-party API paths in entitlement reviews and risk assessments.

API posture governance is the named concept this topic exposes. Discovery without posture governance still leaves inconsistent standards, while posture governance without runtime visibility misses active abuse. The two controls only work together when they are treated as a lifecycle model. Practitioners should align policy, inventory, and runtime detection as a single operating model.

From our research library:

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

What this signals

API posture governance: organisations need a single view of API inventory, authentication expectations, and runtime misuse signals if they want to govern access beyond the perimeter. Discovery tells you what exists, but only posture plus runtime shows whether the access pattern is acceptable.

For identity teams, the real issue is that API traffic increasingly depends on service tokens, delegated trust, and machine-to-machine access paths that traditional human-centric reviews do not cover. That means API security and identity governance now overlap at the point where authorisation is issued and observed.

Perimeter controls still matter, but they are insufficient when the request path is invisible, the trust chain is external, or the abuse pattern unfolds over hours rather than milliseconds. In practice, teams need to treat API security as a lifecycle control problem, not a front-door inspection problem.

For practitioners

• Inventory APIs from inside the environment Use internal telemetry, service maps, and application logs to identify undocumented endpoints, direct service calls, and shadow APIs that perimeter tools miss.
• Track third-party API dependencies and token scope Record which internal workloads call external APIs, what data they send, which tokens they use, and whether those credentials can be revoked or narrowed.
• Add behaviour-based detection for BOLA patterns Look for repeated object enumeration, unusual sequential identifier access, and session activity that gradually expands across accounts or tenants.
• Treat API discovery and posture as one control plane Set standards for inventory completeness, authentication expectations, and runtime logging so that undocumented APIs are not left outside governance.

Key takeaways

• Edge-only controls leave blind spots where shadow APIs, direct service calls, and external integrations can move data without meaningful perimeter oversight.
• BOLA and similar abuses are hard to catch with request-by-request inspection because the failure appears in patterns that unfold across time and sessions.
• Discovery, posture governance, and runtime monitoring belong together if API security is going to cover the full lifecycle rather than the front door.

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.
• API posture governance: API posture governance is the ongoing discipline of defining, measuring, and enforcing how APIs are exposed, secured, and used across an organization. It covers authentication, authorization, inventory, schema control, rate limits, logging, versioning, and risk review, so APIs remain discoverable, least-privileged, and aligned with security and compliance requirements.
• Runtime Monitoring: The practice of observing identity activity while it is happening, not after the fact. For agents and NHIs, it means tracking tool calls, credential use, and resource access in real time so deviations from approved scope can be detected before damage compounds.

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.