Introduction

For two decades, enterprise security architecture was organized around a simple assumption: the network perimeter was the boundary that mattered most. Firewalls, VPNs, and network segmentation existed to keep attackers on the outside and sensitive systems on the inside. That assumption no longer matches where attacks actually happen. Akamai's 2026 State of the Internet security report found that 87% of organizations experienced an API-related security incident in 2025, with the average number of API attacks per organization rising from 121 to 258 per day, a 113% year-over-year increase, and Akamai's own security leadership now describes APIs as the primary attack surface for the modern enterprise, ahead of both web applications and network infrastructure [1].

This is not a marginal shift in emphasis. It reflects a structural change in how enterprise systems are built and connected. APIs are the mechanism through which cloud services, SaaS platforms, mobile applications, partner integrations, and increasingly AI agents all exchange data. Every one of those connections is a potential entry point that exists outside the traditional network perimeter entirely, which is precisely why perimeter-era controls have less and less to say about where the actual risk sits.

The Data Behind the Shift

Three independent research efforts published in 2026 converge on the same conclusion from different angles. Wallarm's 2026 API ThreatStats Report analyzed 67,058 vulnerabilities disclosed in 2025 and found that 11,053, or 17%, were API-related. More significantly, of the 245 vulnerabilities the U.S. Cybersecurity and Infrastructure Security Agency added to its Known Exploited Vulnerabilities catalog during the year, 43% were API-related, making APIs the single most common category of actively exploited vulnerability in that dataset [2]. Wallarm's analysis of 60 publicly disclosed API breaches found broken authentication responsible for 52% of cases and unsafe consumption of third-party APIs responsible for 27%, categories that map directly onto the OWASP API Security Top 10, the reference taxonomy for API-specific risk [2][5].

Verizon's 2026 Data Breach Investigations Report adds a broader confirmation. Exploited vulnerabilities are now the leading initial access vector across breaches generally, at 31% of cases, up from roughly one-fifth the year before, overtaking stolen credentials for the first time in the report's nineteen-year history [3]. APIs are not the only category of vulnerability driving that shift, but Wallarm's KEV data suggests they are disproportionately represented within it.

A third data point explains why detection has not kept pace with exposure. Enterprise Management Associates research, cited in CSO Online's coverage of API security trends, found that roughly 70% of enterprises have only about 30% of their APIs formally documented, a gap that does not include shadow APIs sitting entirely outside security governance [6]. An attack surface that is 87% likely to produce an incident and only 30% inventoried is, by definition, a surface most organizations cannot fully see, let alone defend.

Figure 1. Average daily API attacks per organization, 2024 vs. 2025 (Akamai).

Why This Shift Is Accelerating Now

Two forces are compounding the API attack surface faster than most governance processes were built to track. The first is simple growth: API estates are expanding rapidly as organizations connect more systems, more partners, and more internal services through API-based architectures rather than monolithic applications. The second, and newer, force is agentic AI. Security researchers interviewed in SecurityWeek's 2026 API security outlook describe AI agents as implicitly introducing new APIs, tools, services, and data connectors, every time they are deployed, expanding the attack surface horizontally through more endpoints, vertically through more critical business logic, and contextually as APIs become embedded directly into autonomous agent workflows [7].

Wallarm's research quantifies part of this convergence directly: of 2,185 AI-related vulnerabilities identified in 2025, 786, or 36%, directly overlapped with API vulnerabilities [2]. AI security and API security are not two adjacent disciplines that happen to interact occasionally. For more than a third of AI-specific vulnerabilities, they are the same finding described twice.

What This Looks Like in Practice

The Optus data breach of September 2022 remains one of the clearest illustrations of what an API-as-attack-surface incident actually looks like on the ground. According to filings with the Australian Communications and Media Authority, an internet-facing API with a coding-error-weakened access control exposed the personal data of more than 9.5 million customers over several days before being discovered, not through a novel exploit, but through an unauthenticated endpoint that had been reachable for roughly two years [4]. Nothing about that incident required advanced attacker tradecraft. It required only that an API existed, was reachable, and was not being watched, a pattern the aggregate statistics above suggest is far more common than any single incident implies.

A more routine version of the same dynamic plays out inside most enterprises continuously, without making headlines. Internal APIs built to connect a CRM to a billing system, or a mobile app to a backend service, accumulate over years across multiple teams. Each one individually seems low-risk. Collectively, they form an attack surface that grows faster than any manual review process can track, which is exactly the gap the documentation statistic above describes.

From Perimeter to API: What Actually Changed

The perimeter model assumed a defensible boundary: a known set of network entry points, monitored by a known set of controls, separating trusted internal systems from an untrusted external internet. That model made sense when most enterprise applications were monolithic, hosted on infrastructure the organization directly controlled, and accessed through a limited number of well-understood channels.

Modern enterprise architecture does not work that way. A single customer-facing transaction today might touch a dozen internal microservices, several third-party payment and identity providers, a cloud storage layer, and increasingly an AI agent orchestrating parts of the workflow, each connection made through an API rather than through a network boundary a firewall can inspect in the traditional sense. Cloud-native applications distribute logic and data across services that were never designed to sit behind a single perimeter. The result is not that the perimeter became less secure. It is that the perimeter stopped being where most of the meaningful connections actually happen, which is why perimeter metrics increasingly describe a smaller and smaller share of an organization's real exposure, even when those metrics look healthy on their own terms.

A Second Illustration: The Cost of Undocumented Connections

The Optus case is a useful illustration precisely because it was public and well-investigated, but the same underlying pattern, an API that existed, was reachable, and was not being watched, plays out constantly in less visible forms. Financial services and SaaS organizations that integrate through partner and open-banking APIs routinely accumulate connections built for a specific project, a specific integration partner, or a specific short-term initiative, connections that frequently outlive the business relationship that created them. Each individual connection is typically reviewed once, at creation, and rarely revisited unless a specific reason forces a second look.

This matters because the EMA documentation gap cited earlier, roughly 70% of enterprises with only 30% of their APIs formally documented, is not evenly distributed across an organization's API estate. Newer, actively developed APIs tend to be reasonably well tracked, since they pass through current governance processes. Older APIs, built before current governance existed or inherited through an acquisition or platform migration, are precisely where documentation tends to be weakest, and precisely where the attack surface described throughout this piece tends to concentrate.

Several implications follow directly from this data rather than from speculation about future trends.

Perimeter-oriented security metrics increasingly describe a shrinking share of actual risk. Firewall rules and network segmentation remain necessary, but an attacker exploiting a vulnerable, internet-facing API often never touches the network perimeter in any way those controls would detect.

Inventory is the precondition for everything else. An organization cannot secure, monitor, or govern an API it does not know exists. The 70/30 documentation gap identified above is not a minor operational inconvenience; it is the reason detection consistently lags exploitation in the incidents described throughout this piece.

Authentication and authorization failures, not exotic exploits, remain the dominant cause of API breaches. Wallarm's finding that broken authentication accounts for 52% of analyzed API breaches suggests that foundational access-control discipline delivers more risk reduction than most advanced tooling investments made without first fixing that basic layer [2].

CyberTech Intelligence's perspective is that Runtime Visibility, the practice of maintaining continuous, current discovery of active APIs rather than relying on periodic manual review, is the single highest-leverage control available to organizations trying to close this gap, because every other control described above depends on first knowing an API exists.

It is also worth being explicit about what this shift does not mean. It does not mean network-level controls have become unnecessary, or that perimeter security spending should simply be redirected wholesale to API tooling. It means the relative share of risk those controls address has shrunk, and that security reporting, budget allocation, and staffing decisions built around a perimeter-first mental model will systematically underweight where incidents are actually concentrating unless API-specific visibility is added alongside, not instead of, existing network security investment.

Actionable Recommendations

The recommendations below are ordered deliberately. Inventory and authentication discipline address the two largest, most consistently documented causes of API compromise identified in the research above, and both are achievable using tools most organizations already operate, before any new detection or AI-specific tooling investment is considered.

  • Run a full API discovery exercise comparing documented inventory against actual production traffic, closing the gap the EMA research identifies before investing further in runtime protection tooling.
  • Prioritize authentication and authorization review across existing APIs before pursuing more advanced detection capabilities, since broken authentication remains the single largest analyzed breach cause.
  • Extend inventory and ownership requirements explicitly to APIs called by AI agents, given that AI-related vulnerabilities now overlap substantially with API vulnerabilities.
  • Treat API attack surface metrics, not only network perimeter metrics, as a standing item in security reporting to leadership, reflecting where the data shows risk actually concentrating.

Conclusion

The shift from network perimeter to API as the primary enterprise attack surface is not a prediction. It is a description of where 2025's incidents, exploited vulnerabilities, and breach data already concentrated, confirmed independently by Akamai's traffic telemetry, Wallarm's vulnerability analysis, and Verizon's breach investigation dataset. Organizations that continue to measure and report security posture primarily in perimeter terms are measuring a shrinking part of their actual exposure. Closing that gap starts with inventory, continues with authentication and authorization discipline, and increasingly must account for APIs that AI agents create and call on an organization's behalf. None of this requires abandoning existing security investment; it requires recognizing that the center of gravity has moved and reallocating attention accordingly.

Strengthen Your API Attack Surface Visibility with CyberTech Intelligence

CyberTech Intelligence helps enterprise security teams establish continuous visibility into their real API attack surface, closing the gap between documented inventory and actual production exposure.

To evaluate your organization's current API attack surface visibility, connect with CyberTech Intelligence for an API Exposure Assessment.

Connect With Us

References

[1] Akamai. 2026 State of the Internet: Apps, APIs, and DDoS Security Report. Akamai, 2026. https://www.akamai.com/newsroom/press-release/ai-transformation-at-risk-ap-is-emerge-as-the-primary-attack-surface-akamai-research-finds 

[2] Wallarm. 2026 API ThreatStats Report. Wallarm, 2026. https://www.wallarm.com/reports/2026-wallarm-api-threatstats-report 

[3] Verizon. 2026 Data Breach Investigations Report. Verizon, 2026. https://www.verizon.com/business/resources/reports/dbir/ 

[4] SecurityScorecard. 5 Lessons from the Optus Data Breach for Telecom and Third-Party Risk (citing ACMA filings). SecurityScorecard, 2026. https://securityscorecard.com/blog/5-lessons-from-the-optus-data-breach-for-telecom-and-third-party-risk/ 

[5] OWASP. OWASP API Security Top 10. OWASP Foundation, 2023. https://owasp.org/API-Security/ 

[6] CSO Online. APIs Are the New Perimeter: Here's How CISOs Are Securing Them (citing Enterprise Management Associates research). CSO Online, 2026. https://www.csoonline.com/article/4148315/apis-are-the-new-perimeter-heres-how-cisos-are-securing-them.html 

[7] SecurityWeek. Cyber Insights 2026: API Security — Harder to Secure, Impossible to Ignore. SecurityWeek, 2026. https://www.securityweek.com/cyber-insights-2026-api-security/