Zuplo
API Security

Akamai's 2026 API Security Survey Shows an 87% Incident Rate

Nate TottenNate Totten
April 30, 2026
6 min read

Akamai's fourth-annual API Security Impact Survey: 87% of organizations hit by an API incident at $700K average cost. Five takeaways and what to do next.

Akamai’s fourth-annual API Security Impact Survey, released on April 28, surveyed 1,840 security professionals across 10 countries and 6 industries. The headline: 87% of organizations experienced an API security incident in the past year, at an average cost exceeding $700,000 per incident.

Akamai’s State of the Internet report last month flagged the same 87% rate from a different angle: attack patterns and OWASP categories. This survey adds the business layer: what incidents cost, where AI fits in, and why visibility is declining even as security spend grows.

Best for:
  • Security and platform teams who own API gateway policy
  • DevSecOps practitioners trying to translate survey findings into architecture decisions
  • Engineering leaders sizing the gap between perceived and actual API security maturity

Here are the five findings that matter most, and what to do about each.

1. The headline numbers are getting worse

The numbers tell a clear story of acceleration:

  • 87% of organizations reported an API security incident in the past 12 months, up from 76% in 2022
  • Organizations averaged 3.5 incidents per year
  • The average cost per incident exceeded $700,000
  • Financial services were hit hardest, with 96% reporting API attacks
  • The costliest incidents were in energy and utilities ($860,000 average), followed by manufacturing ($732,000) and health and life sciences ($725,000)

These are real losses hitting real budgets. With 80% of respondents ranking API security among their top three cybersecurity priorities, the problem has executive attention. The question is whether attention translates into action.

2. AI is the new risk multiplier

Perhaps the most significant new finding: 42% of security professionals report that APIs powering AI applications, agents, and LLMs were targeted by cyberattacks in the past year. Meanwhile, 38% rank securing AI technologies as their top cybersecurity priority for the year ahead.

This tracks with our Q1 2026 API security scorecard. AI isn’t just creating new APIs. It’s creating new kinds of traffic traditional security tools can’t model.

An AI agent making tool calls through an MCP server generates non-deterministic request patterns. A RAG pipeline produces traffic volumes that shift unpredictably based on user prompts. A fine-tuning job might hammer a data endpoint for hours, then go silent.

On Zuplo gateways we already see AI agent traffic with retry shapes and burst patterns that don’t match anything human users produce. A single flat IP-keyed limit falls over the moment a real agent shows up.

Why traditional rate limiting fails for AI traffic

Rate limiting that assumes steady-state human patterns doesn’t work here. You need per-consumer rate limiting keyed on identity, not IP.

Zuplo’s rate limiter buckets traffic by user, IP, or a custom function, with separate limits per route. A known AI agent’s API key gets a high-burst ceiling while anonymous IP-keyed traffic gets a tighter one.

Common mistake:

Treating an AI agent’s bursts like attacker traffic by relying on IP-keyed rate limits alone. A legitimate agent will trip the limit; a real attacker rotates IPs. Key on consumer identity, then size limits per tier.

Rate Limit Inbound policy

Bucket by user, IP, or custom function, with separate limits per route. Configure tiers for AI agents and human consumers.

AI-specific security on Akamai infrastructure

For teams running AI workloads on Akamai infrastructure specifically, Zuplo’s AI Gateway on Akamai provides an integrated governance layer.

It pairs Zuplo’s rate limiting and authentication with the Akamai AI Firewall for prompt injection defense, data loss prevention, and toxic content filtering, addressing AI-specific attack vectors at the infrastructure level.

3. The API visibility crisis is getting worse, not better

Here’s the finding that should alarm every security team: only 23% of enterprises have full API inventories that include details on which APIs expose sensitive data. In 2022, that number was 40%. API visibility is declining even as attack surfaces expand.

Organizations are spending more on API security than ever, yet losing track of their own APIs. APIs proliferate faster than manual inventory can keep up.

Microservices, AI integrations, third-party connectors, internal tools: every team ships new endpoints, and the central security team finds out when something breaks.

An OpenAPI-first approach solves this by design. When the gateway requires an OpenAPI specification as the source of truth for routing, every route must be defined in a spec before it can receive traffic. Undocumented endpoints don’t exist at the gateway layer.

With Zuplo, the OpenAPI spec drives routing, request validation, documentation, and SDK generation. If a route isn’t in the spec, the gateway doesn’t route to it.

That property only delivers full visibility if the gateway is the only public ingress: backends on private networks, gateway as the single front door. With that in place, OpenAPI-first eliminates shadow APIs and zombie endpoints by architecture, not by periodic audits always running behind.

4. The C-suite thinks things are better than they are

The survey uncovered a dangerous perception gap: 40% of C-suite leaders reported advanced API testing maturity, compared to only 28% of DevSecOps practitioners, the people actually doing the work. That 12-point gap between executives and operators is a leading indicator of underinvestment.

When leadership believes security is more mature than it is, budgets go elsewhere. When DevSecOps teams know about gaps but can’t show data, they can’t make the case for better tooling.

Closing the gap means one source of truth. When API security policies live as configuration-as-code in Git, “how mature is our API security?” stops being self-report. The repo is the answer: authentication policies, rate limits, and validation rules are version-controlled, reviewable in pull requests, and deployable through CI/CD.

Executives don’t need to read JSON to benefit. A short audit script that reads the route list and flags any route without an authentication, rate-limit, or request-validation policy attached produces a coverage report in seconds.

Run it in CI and the gap closes the moment someone ships an unprotected route. Both sides argue from the same data instead of from interpretation.

5. Dedicated API security staff isn’t enough

The survey found that 53% of organizations have dedicated API security personnel, yet the 87% incident rate persists. Hiring more security people isn’t solving the problem because the problem isn’t staffing. It’s architecture.

Security teams can’t manually review every endpoint, validate every payload, or monitor every consumer. Enforcement has to happen automatically at the infrastructure level. The team’s job is to configure the rules, not enforce them request by request.

That’s the shift an edge-native API gateway enables. “Edge-native” means the gateway runs as workers on a global CDN, so policies execute close to the caller rather than at a single regional origin.

Instead of leaning on application code for auth, validation, and rate limits, you push those concerns to the gateway.

What edge enforcement looks like in practice

  • Authentication: Enforce API key auth, JWT validation, or OAuth 2.0 as a policy on every route. Requests without valid credentials never reach your backend.
  • Request validation: Validate every incoming request against your OpenAPI schema automatically. Malformed payloads, missing required fields, and wrong data types are rejected before your application code ever sees them.
  • Rate limiting: Set per-consumer limits that prevent abuse from both human and AI consumers. Different tiers for different consumer classes, enforced at the edge across 300+ locations globally.
  • WAF protection: For enterprise deployments, Zuplo’s managed WAF (Web Application Firewall) integrates with Akamai App & API Protector. The WAF sits in front of the gateway and adds a defense layer against OWASP Top 10 threats, DDoS, and zero-day vulnerabilities before traffic reaches your policies.
  • Key lifecycle management: Zuplo’s API key system provides instant rotation and leaked-key detection via GitHub secret scanning. When 42% of respondents report AI API attacks, proper key lifecycle management is the difference between a contained incident and a $700,000 breach.

API key management

Instant rotation and leaked-key detection via GitHub secret scanning. Treat keys as a lifecycle, not a string in a database.

What this means for your team

The Akamai survey confirms a pattern we’ve seen across multiple reports this year: incidents are accelerating, AI is expanding the attack surface, and most organizations don’t have adequate visibility into their own APIs.

All three have architectural answers, not headcount answers: OpenAPI as the source of truth, auth and per-consumer rate limits enforced at the edge, request validation against the spec, and gateway config stored in Git so security posture is reviewable rather than self-reported.

Zuplo’s WAF integrates with Akamai App & API Protector, which puts us in the same edge security ecosystem that produced this research. The controls the survey calls critical (authentication, rate limiting, request validation, API visibility) are what Zuplo ships out of the box.

Ready to close the gaps this survey exposed? Start for free and deploy OpenAPI-first routing, per-consumer rate limiting, and automated request validation. Those three controls address every root cause in Akamai’s findings.