API Security Starts With Discovery, Akamai Executive Says

Organizations can’t protect APIs they haven’t found. That’s the central point Rupesh Chokshi, Akamai’s senior vice president and general manager of application security, makes about a problem that grows as businesses connect more applications, devices, suppliers and customers. His proposed starting point is practical: build an inventory, understand how each API behaves, then apply controls across development and runtime.

The need is sharpened by rising abuse. Cloudflare reported a 177% increase in API abuse attempts over the prior year, with credential stuffing identified as the most common tactic. Bots also target APIs to overwhelm services or seek sensitive data. Chokshi says attackers exploit weaknesses to steal information, take over accounts, manipulate loyalty points and make fraudulent purchases.

One example cited in the interview is a reported API abuse incident at Dell Technologies that exposed about 49 million customer records. Chokshi points to broken object-level authorization as a vulnerability that can enable account takeover and fraud. The broader lesson is that APIs can expose valuable actions and data even when an organization’s main website appears well protected.

Inventory comes before protection

Many companies don’t have a complete view of the APIs accessible from the internet or from other applications. Some are created for a project and forgotten; others exist outside the security team’s records. Chokshi says discovery tools can identify these unmanaged or “shadow” APIs, helping teams build a clearer picture of their exposure.

A cited report found that about 30% of APIs were shadow APIs. Chokshi’s response is to establish discovery and visibility first: catalog APIs, learn their usual traffic patterns and set a baseline for exposure. Teams can then assess discovered APIs for vulnerabilities and risks.

That sequence matters because an inventory is useful only if it informs action. Chokshi recommends applying zero-trust principles at the application layer and putting controls around API discovery, posture management, runtime protection and testing. In practice, that means understanding what an API does and who uses it before deciding what access and monitoring it needs.

Discovery also has to be ongoing. APIs change as products evolve, and a catalog that reflects only an earlier snapshot can miss new endpoints or altered behavior. The interview doesn’t specify a particular scanning schedule or tool configuration, but its logic is clear: teams need enough visibility to recognize both the APIs they intend to run and the traffic patterns that may signal misuse.

AI raises the pace of API attacks

Chokshi expects AI models to become part of more applications through APIs. He says the familiar risks remain: data theft, ransomware, malware, account abuse and API abuse. The change is in how attackers can use AI to scan APIs at scale, find weaknesses and plan more involved attack sequences.

In his account, automated reconnaissance lets attackers spend less effort on repetitive discovery and more on later stages, such as entering networks or monetizing stolen data. That efficiency could make attacks more frequent and indiscriminate across organizations of different sizes and industries. The interview does not quantify the effect of AI on attack volume, so the claim is best read as a warning about capability and scale rather than a measured forecast.

For developers, Chokshi’s recommendation is to treat API security as part of system design from the start. Discovery, risk analysis, runtime defenses and testing should be integrated into the development lifecycle. As applications add AI and machine-learning components, teams also need to keep reassessing the APIs those components use and the data or functions those connections expose.

That work has a lifecycle dimension: API behavior can change after release, and protections applied only during development may not catch abuse at runtime. Conversely, runtime monitoring can’t replace security testing before deployment. Chokshi’s approach combines both, with repeated assessment as applications and their connections change.

Gaps in practice and Akamai’s approach

Chokshi identifies three recurring failures: incomplete API inventories, weak incident response and insufficient testing before code reaches production. He says security teams may concentrate on customer-facing websites while missing other external and internal APIs that provide routes into systems and data.

Response planning is another weak point. When credential stuffing or API abuse occurs, some organizations struggle to contain the incident or prevent a repeat. Chokshi argues for a defined response and hardening plan, alongside testing during development. These measures address different stages of the problem: testing can catch flaws before release, while response procedures help teams act when defenses fail.

Akamai’s products, as Chokshi describes them, cover API discovery, protective controls, automated response workflows and security across the development lifecycle. He says the company combines AI, data analysis and security specialists in its approach. These are vendor claims; the interview provides no comparative performance figures or deployment costs. Teams assessing such tools would still need to evaluate coverage against their own API estate and operating requirements.

What to expect next

Chokshi expects demand for API security to grow over the next three to five years as application-to-application communication and connected services expand. He says many organizations lack the controls and practices needed to manage their exposure, and calls for a baseline that includes discovery, inventory management, vulnerability assessment, risk mitigation and runtime protection.

He also expects security needs to rise as AI and machine-learning applications rely on APIs. Chokshi says senior technology leaders increasingly treat API security as a priority, but the interview does not offer adoption figures. The practical test will be whether organizations turn that attention into maintained inventories, regular testing and response plans that work across the full API estate.

Chokshi on people and everyday technology

Outside security, Chokshi says colleagues in the cybersecurity industry and his family keep him motivated. He values the continuous learning required to respond to new threats and says his two daughters’ curiosity offers a grounding perspective.

His preferred productivity device is the smartphone. He uses one for messaging, video calls, document review and remote access, as well as banking, reading, meditation and entertainment. The choice reflects how much work and personal activity now depends on connected services—many of them reached through APIs. For security teams, that dependence makes the basic task Chokshi emphasizes even more consequential: know what is connected before trying to protect it.