LayerX Pricing After the Akamai Acquisition

LayerX pricing has an acquisition boundary before it has a number. LayerX announced an agreement to join Akamai, and the LayerX homepage now redirects to Akamai Workforce Protector. Akamai labels that product "formerly LayerX." A current estimate should therefore use the Akamai product name and contracting path, along with support terms, while preserving LayerX as the product lineage buyers still search for.

TL;DR

• LayerX is now presented by Akamai as Akamai Workforce Protector, formerly LayerX.
• The current public pages explain interaction controls but provide no complete dollar rate card.
• The scope reaches AI and SaaS, while web and private applications add further quote variables. Desktop activity also needs its own deployment assumptions.
• Ask Akamai to identify licensed users and managed browsers, plus devices, extensions, applications, policy modules, retention, support, and transition terms.

LayerX pricing now sits under Akamai

The LayerX acquisition announcement says LayerX entered a definitive agreement to be acquired by Akamai and would join Akamai's Enterprise Security organization after completion. The current Akamai Workforce Protector page closes the naming loop by presenting the product as formerly LayerX.

The old LayerX homepage also redirects to that Akamai product page. That transition affects procurement even when the underlying browser controls remain familiar. Buyers should confirm the selling entity and order form, plus the support portal, service description, and renewal path in the current Akamai paperwork.

My view is blunt: a 2026 request for "LayerX seats" is too stale to approve. The quote needs the current product identity and the exact services Akamai will deliver.

The interaction surface sets the scope

A legacy LayerX AI governance page describes browser-native controls for mapping AI use and setting policies, including restricting sensitive-data sharing. The current Akamai page expands the description across AI and SaaS, plus web, private applications, and desktop applications. It also names prompts and responses, along with agent actions and data exchanges, as interaction surfaces.

That breadth means a seat count can be only one input. The quote may need to account for the workforce population and browser types, plus managed and unmanaged devices, desktop visibility, private-application access, browser extensions, and the AI applications covered by policy. Ask the vendor to identify the actual commercial meter rather than assuming every surface shares one license.

Picture the scoping meeting with a laptop open to a browser extension inventory. Beside it sits a second sheet listing desktop AI clients and private applications. If the quote covers only the first sheet, the architectural promise and the purchased scope have diverged before deployment.

Browser controls and model routes are different categories

A browser-native product observes activity where employees work. It can associate browser actions with user context and inspect data exchanged with web applications, while applying controls at that interaction point. Akamai now describes Workforce Protector as combining browser-native protection and desktop visibility, plus centralized policy management and cloud intelligence.

An application-to-model API route creates another control point. A backend agent may call an LLM without a human browser in the path. An internal application may use a shared provider credential while supplying identity in application metadata. Those requests need an inventory and policy design that follows the HTTP model route.

The shadow AI explainer covers unsanctioned tools and the traffic paths that create visibility gaps. The AI governance framework covers the operating layers between policy documents and audit evidence. Use those distinctions when reviewing the Akamai proposal. Browser protection can own employee interaction controls while another layer owns backend model authorization.

Build the quote around coverage and evidence

Start with the workforce and device estate, then add interaction channels. Record employee and contractor populations. List managed browsers and permitted alternatives. Count device classes and note the use of unmanaged devices. Add browser extensions and desktop applications, plus SaaS services, private applications, and sanctioned AI tools that require policy.

Ask Akamai to return a written scope covering:

• The licensed population and the definition of an active or billable user.
• Browser extension and browser coverage, plus desktop and private-application coverage included in the order.
• AI discovery and data controls, plus access rules, identity protection, and extension-risk functions included.
• Event retention and evidence export, plus integrations, data regions, and administrative roles.
• Deployment services and support levels, plus service commitments and renewal assumptions.
• Treatment of existing LayerX agreements and migration dates, including any product-name changes on renewal.

A quote with these fields can be tested against architecture. A single annual total without them cannot.

Acquisition terms belong in the renewal file

The acquisition announcement told existing LayerX customers that the same team and product would continue, backed by Akamai. Akamai's current product page now labels Workforce Protector as formerly LayerX. Procurement should preserve both documents with the order so future reviewers can connect a LayerX deployment record to an Akamai Workforce Protector invoice.

Ask for explicit answers on support ownership and data processing. Confirm which terms come from an existing LayerX agreement and which terms change under Akamai. Record the product identifier used for entitlements, because a name on an old security review may differ from the name in the current portal.

Avoid inventing a migration discount or assuming legacy rates survive. Those facts belong in the buyer's actual amendment or renewal quote. Public product pages can establish scope and lineage. They cannot establish a customer's negotiated price.

DeepInspect

DeepInspect operates on authenticated HTTP traffic deliberately routed between users or agents and LLM endpoints. It evaluates application-supplied identity and data context against versioned policy, then records the permit or deny decision, including any redaction decision, on that model route.

Workforce Protector can govern interaction surfaces around browsers and desktop tools, plus SaaS and private applications. DeepInspect's boundary is the routed model request. Keep both scopes explicit in the quote and test each control against the traffic it can actually inspect. Book a technical deep dive at deepinspect.ai.