API Security in 2026: Noname vs Salt Security vs Traceable Compared

Here is the honest framing for this comparison that most buyer’s guides won’t give you: of the three vendors in the title, only one still exists as a standalone API security company.

Noname Security was acquired by Akamai in June 2024 for $450 million and now operates as Akamai API Security. Traceable merged with Harness — an AI-native DevSecOps platform — in March 2025 and is being folded into Harness’s broader application security stack. Salt Security is the only one of the three still operating as an independent pure-play API security vendor.

That is the real story in API security in 2026: the category is consolidating, and it is consolidating in three different directions at once. Understanding those directions is more useful to a buyer than a feature-by-feature matrix, so we will cover both.

What API security actually needs to do

APIs are now the connective tissue of the enterprise. By current industry estimates, more than 70% of all internet traffic is API traffic, and the attack surface has grown proportionally. API attacks grew 109% year-over-year in the lead-up to Akamai’s Noname acquisition, and the growth curve has not flattened.

The OWASP API Security Top 10 — last updated in 2023 and still the canonical risk taxonomy — identifies ten categories of API-specific risk. The top three, which together account for the majority of real-world API attacks, are:

• API1: Broken Object Level Authorization (BOLA). The attacker manipulates an object identifier in an API request to access data they should not see. This single risk represents about 40% of all API attacks and has held the #1 position on the OWASP list since 2019.
• API2: Broken Authentication. Weak authentication implementations, including missing MFA, credential stuffing vulnerabilities, and session management failures.
• API3: Broken Object Property Level Authorization (BOPLA). The attacker accesses or modifies specific object properties they should not — often through over-fetching or mass assignment.

A serious API security platform in 2026 needs to do four things well:

Discovery. Find every API the organisation exposes — including the ones nobody documented, nobody inventoried, and nobody remembers building. These are the shadow APIs that dominate breach reports.

Posture management. Assess each discovered API against the OWASP API Top 10 and any applicable regulatory frameworks, flagging authentication weaknesses, broken authorisation patterns, exposed sensitive data, and misconfigurations.

Runtime protection. Monitor API traffic in production for attack patterns, anomalous behaviour, and signs of abuse. This is the operational heart of API security — and where the three platforms in this comparison differ most.

Testing integration. Embed API security checks into CI/CD pipelines so that vulnerabilities are caught before they reach production.

No vendor in the market is equally strong at all four. The question is which combination of strengths maps to which buyer.

The three platforms, as they stand in 2026

Akamai API Security (formerly Noname)

Noname pioneered the comprehensive API discovery category — finding shadow APIs became a signature capability before anyone else made it one. The acquisition by Akamai was the largest pure-play API security deal ever ($450M) and has reshaped the market more than any subsequent event.

Since the acquisition, Akamai has unified Noname’s platform with its earlier Neosec acquisition and with Akamai’s edge infrastructure — Kona Web Application Firewall, Bot Manager, and the App & API Protector. The result is a genuinely differentiated proposition: API discovery and posture management working alongside edge enforcement, with Akamai’s global threat intelligence feeding both layers.

The strongest operational argument for Akamai API Security in 2026 is the edge-plus-API integration. For organisations already running Akamai at the edge, adding API discovery, posture, and testing in the same platform consolidates vendors and produces better coverage than running two disconnected products. Shadow API discovery remains best-in-class; active API testing in CI/CD is a competitive capability; the edge-layer threat intelligence is unmatched.

The weakness, in candid terms, is that integration-stage products always carry integration risk. Noname’s technology is being folded into Akamai’s broader platform over several release cycles, and different capabilities have different maturity levels at any given point. Customers evaluating today should look closely at which specific Noname capabilities have been fully absorbed, which are still in transition, and which overlap with Neosec’s older technology. The Akamai product team has been transparent about this in public discussions, but the practical effect is that the current product is still stabilising.

Salt Security — the last independent

Salt Security is the only one of the three vendors in this comparison that remains independent, and this has become a marketing position in its own right. Salt’s proposition leans hard on ML-driven behavioural detection: the platform baselines normal API behaviour across attributes like caller, endpoint, payload structure, and response patterns, then flags deviations in real time.

On detection depth for the top OWASP risks — particularly BOLA and BOPLA, which dominate real-world API attacks — Salt is widely regarded as the strongest of the three. Their product research publishes some of the more detailed breakdowns of API attack techniques in the industry, and that rigour shows up in the platform’s detection logic. For security-led buyers who are purchasing API security because they need to find attacks, not because they need to check a compliance box, Salt is typically the strongest option.

Salt has also invested early and heavily in AI agent API security — an area that is about to become the single largest driver of growth in the category. Every autonomous AI agent deployed inside an enterprise uses APIs to access data and execute actions; the authorisation and behavioural patterns of those agents are different from human users, and Salt’s detection approach extends to them more naturally than competitors who built their platforms around human-initiated traffic.

The weakness is the obvious one: Salt is a pure-play. That cuts both ways. It means Salt’s roadmap focuses exclusively on API security rather than competing for engineering priority with edge services, DevSecOps, or application security. But it also means buyers add a standalone vendor rather than consolidating, and the commercial terms reflect Salt’s positioning — Salt is not the cheapest option in the market, and the sales conversation is typically an enterprise-grade one.

Harness (formerly Traceable)

Traceable’s original positioning was built on distributed tracing: rather than inspecting traffic at the network or gateway layer, Traceable instrumented application code to trace API calls end-to-end through a request’s full path across services. This produced unusually rich context — particularly for identifying BOLA and authorisation failures, where the question “did this user actually have permission to touch this object?” requires context from multiple service hops.

The March 2025 merger with Harness changed the positioning fundamentally. Harness is an AI-native DevSecOps platform covering CI/CD, feature flags, deployment, and increasingly the full security pipeline. Traceable is being integrated as Harness’s API security layer, alongside their broader application security offering. The combined pitch is that API security is just one dimension of a unified, AI-driven DevSecOps platform — which is a different proposition than standalone API security.

For engineering-led organisations that already run Harness for CI/CD, this is a genuinely compelling consolidation. The distributed tracing approach survives the merger and remains the strongest in the market for authorisation context, particularly in microservice-heavy environments. The CI/CD integration is best-in-class by construction, given Harness’s DNA.

The weakness is that for security-led buyers who are not already on Harness, the platform now carries the overhead of an entire DevSecOps stack they do not need. Harness is a serious piece of software with a serious price tag, and the API security module is not sold as an à la carte component in most commercial conversations. Security teams who want a focused API security tool and are not evaluating their DevSecOps stack at the same time will typically find this a harder fit.

The CNAPP convergence you cannot ignore

There is a fourth trajectory that every buyer in this market should factor into their decision: CNAPP vendors are absorbing API security as a native capability. Wiz, Orca, Prisma Cloud, and the other cloud-native application protection platforms have all added API discovery and posture management over the last 18 months. Palo Alto Networks has integrated API security into Prisma Cloud; Wiz has added API inventory to its platform; Orca is building out comparable capability.

None of these CNAPP-native API security modules is yet as sophisticated as a dedicated platform like Salt or Akamai. But the gap is narrowing, and for many mid-market buyers, “good enough” API security bundled inside the CNAPP they are already buying is more attractive than a standalone best-in-class API platform. This is the same dynamic that has played out in CSPM, DSPM, and SSPM — and the outcome is typically the same: the pure-plays remain relevant at the high end of the market, and the bundled capabilities absorb the middle.

For a buyer in 2026 evaluating whether to add API security, the decision tree looks something like this: If you are already running a CNAPP and your API surface is moderate, enable the CNAPP’s API module before buying anything else. If you are an Akamai shop, Akamai API Security is typically the right answer. If you are an engineering-led shop already on Harness, the Harness API security module is typically the right answer. If you are a security-led shop with a sophisticated API estate, a known attack surface, or demanding detection requirements — Salt Security is typically the right answer. And if none of these apply, look at your hyperscaler’s native API security tools first, because they often cover the common cases adequately.

OWASP API Top 10 coverage, in practice

All three platforms in this comparison address the OWASP API Top 10, but coverage depth varies across the list.

BOLA (API1). Salt is strongest, driven by its behavioural baselining. Akamai is strong via discovery plus testing. Harness/Traceable is strong via distributed tracing context. For a BOLA-dominant threat model — which, given that BOLA accounts for roughly 40% of real-world API attacks, applies to most organisations — Salt typically wins on detection capability, with Harness competitive where the estate is microservice-heavy.

Broken Authentication (API2). All three detect authentication weaknesses during discovery and posture assessment. In runtime, Salt’s behavioural approach catches credential stuffing patterns and session anomalies best; Akamai’s edge position is stronger for blocking brute force and bot-driven authentication attacks.

BOPLA (API3). Similar profile to BOLA — Salt and Harness lead on detection logic; Akamai leads on active testing.

Unrestricted Resource Consumption (API4). This is where edge-based platforms shine. Akamai’s rate limiting, DDoS protection, and quota enforcement at the edge are substantially stronger than anything a tracing-only or behaviour-only platform can do in-band. For organisations whose API security priority is preventing abuse rather than preventing breach, Akamai’s edge position is difficult to beat.

SSRF (API7). All three platforms detect SSRF attempts, but Harness’s distributed tracing gives unusually clear visibility into which service made which downstream call — which matters when investigating an SSRF chain across microservices.

Improper Inventory Management (API9). Discovery is the core capability here. Akamai, via Noname’s original strength, leads this category. Salt and Harness both offer discovery but neither matches Noname’s historical depth in finding shadow APIs.

The pattern, across the OWASP Top 10, is that the three platforms are genuinely differentiated rather than being three versions of the same thing. Salt leads on attack detection. Akamai leads on discovery, edge enforcement, and abuse prevention. Harness leads on distributed tracing context and CI/CD integration. A buyer who cannot articulate which of these matters most to them is not ready to buy.

AI agent APIs are about to change the calculation

The single most important development in API security over the next 18 months is not any vendor’s roadmap — it is the proliferation of AI agents inside enterprises. Gartner, McKinsey, and every major security research outfit has published some version of the same forecast: agentic AI systems will generate API traffic at orders of magnitude greater volume than human-initiated systems, and this traffic will have fundamentally different authorisation, behaviour, and risk characteristics.

This is not a hypothetical. Organisations with production AI agent deployments in late 2025 and early 2026 are already reporting that their AI agents generate more API calls per day than their entire human user base. And every one of those calls involves authorisation decisions — which objects the agent can access, which actions it can take, which data it can touch.

The OWASP foundation has responded by publishing a dedicated Top 10 for Agentic Applications, which addresses risks specific to AI agents — goal hijacking, insecure inter-agent communication, prompt injection propagating through API chains. Most of these risks hinge on API security fundamentals, which means the API security vendor that gets AI agent coverage right first will have a material competitive advantage through 2027.

Salt Security has been most public about this direction; Akamai is building on it; Harness is positioning around the DevSecOps integration angle (how do you secure agent-driven CI/CD pipelines). Every buyer evaluating an API security platform in 2026 should ask specifically how the vendor is approaching AI agent API traffic, because this is where the platform they pick will be tested over the next two years.

What to do in 2026

If you are evaluating API security in 2026, the practical sequence is:

First, inventory what you have. Most organisations underestimate their API surface by at least 50%. Before buying a platform, run an initial discovery exercise — even a cheap or free one — and understand the scale of the problem.

Second, establish a threat model. Is your concern breach (BOLA, BOPLA, data exfiltration) or abuse (rate-limit-evading bots, credential stuffing, API-driven fraud)? These point at different platforms. Breach prevention favours Salt or Harness. Abuse prevention favours Akamai.

Third, audit your existing stack. If you are already running a CNAPP, check what its API security module covers. If you are already on Akamai, start with Akamai API Security. If you are on Harness, start there.

Fourth, take AI agent traffic seriously in the evaluation. Every vendor will claim they are ready for it; not every vendor actually is. Ask for specific demos of how the platform handles high-volume agent-driven API traffic.

Fifth — and this matters for anyone buying in the next 12 months — understand the market’s consolidation trajectory. The pure-play API security category is narrowing. Salt remains independent; most other standalone vendors have been acquired or are likely targets. Buying decisions made in 2026 should assume that whichever vendor you choose, they will be operating inside a larger platform within the typical contract term.

Frequently Asked Questions

Is Noname still sold as a standalone product?

Not in the way it used to be. Since the June 2024 Akamai acquisition, Noname’s technology is sold as Akamai API Security — part of the broader Akamai application security portfolio alongside Kona WAF, Bot Manager, and App & API Protector. You can still buy the API security capabilities, but they are increasingly integrated with Akamai’s edge and threat intelligence rather than positioned as a standalone platform. For organisations not already on Akamai, the commercial entry point is higher than Noname’s was pre-acquisition.

Is Salt Security likely to be acquired soon?

Speculation about Salt’s eventual acquisition has been a feature of the API security market for years. The more honest answer is that Salt has thus far remained independent deliberately — using its pure-play positioning as a differentiator against Akamai and other consolidated platforms. Whether that position holds through 2027 will depend on how the rest of the market develops. Buyers should not base decisions on acquisition speculation.

How does Harness/Traceable compare to WAF-based API security?

They address different layers. A traditional web application firewall inspects HTTP requests at the network edge; Harness’s approach via Traceable instruments the application itself with distributed tracing agents, producing richer context about what an API call is actually doing across multiple services. For microservice-heavy architectures, the tracing approach catches issues — particularly authorisation failures — that a network-layer WAF cannot see. For monolithic applications with simpler request patterns, a WAF or edge-based approach is often adequate.

Can CNAPP vendors replace dedicated API security tools?

For many mid-market use cases, yes. CNAPP vendors like Wiz, Orca, and Prisma Cloud have added API discovery and posture management that is adequate for organisations with moderate API surfaces and standard risk profiles. For high-traffic APIs, security-critical applications, or organisations with sophisticated threat models, a dedicated API security platform still outperforms. The decision is similar to the one organisations face with DSPM, SSPM, and CSPM — the bundled capability absorbs the middle market while pure-plays retain the high end.

What is the difference between API discovery and API security?

Discovery is one component of a complete API security programme. Discovery answers “what APIs do I have?” — including shadow APIs, deprecated APIs, and undocumented endpoints. API security is the broader set of capabilities that also includes posture assessment, runtime threat detection, testing, and abuse prevention. A discovery-only tool is useful but incomplete; a platform without discovery cannot adequately secure what it cannot see.

How does API security relate to the software supply chain?

They overlap more than most organisations realise. Modern APIs often consume third-party APIs, third-party libraries, and third-party data — which means an API vulnerability can propagate through a supply chain in the same way a software dependency vulnerability can. Our software supply chain security guide covers this overlap in more depth, particularly the role of SBOMs and SCA tools in catching vulnerable API dependencies before they reach production.

Do I need a separate API security tool if my APIs sit behind an API gateway?

API gateways — Kong, Apigee, MuleSoft, AWS API Gateway, Azure API Management — provide authentication, rate limiting, and some traffic management, but they are not security platforms in the sense this article covers. A gateway is a policy enforcement point; an API security platform is a detection and response layer that watches what happens after the gateway decisions are made. Most serious enterprises run both: the gateway enforces baseline policy, and the security platform catches attacks that pass through compliant-looking traffic.