Summary

  • Akamai says its MuleSoft integration is available and used by more than 20 organisations, following a June announcement that targeted July availability.
  • Current MuleSoft documentation separates risk correlation from service registration and describes distinct update cycles for asset context and security findings.

An adoption figure, not a first launch

The useful change in Akamai's September 10 announcement is evidence of use. More than 20 organisations are using its API Security integration with MuleSoft Agent Fabric, the company says. That is more informative than another partnership promise, but it is not a disclosed count of paying customers or proof that incidents have fallen.

The relationship was already public. MuleSoft's June 2 post described the expanded integration and planned availability for joint customers in July. September should therefore be read as a current availability and adoption update, not the invention of the partnership. Additional native MuleSoft onboarding features and expanded AI and MCP runtime security remain planned for the second half of 2026 in Akamai's release.

The commercial proposition is to connect two kinds of knowledge. MuleSoft knows managed API assets and their environments; Akamai supplies observations and risk context from connected sources. An enterprise should then spend less effort working out which team and service an observation concerns. Whether it actually does so depends on the maintained connection, not just the presence of both products.

A risk scanner does not populate the catalogue

The distinction is explicit in MuleSoft's current Portfolio documentation. Provider-discovery scanners and manual registration add services to catalogues. The Akamai risk-correlation scanner instead enriches services already there. A buyer should not treat connecting that scanner as automatic registration of every unknown API.

The detailed implementation guide adds two clocks. Akamai pulls MuleSoft asset and instance information periodically, typically every few hours; findings return to Portfolio on the scanner's configured schedule. A correlation policy identifies the API instance in observed traffic. The documented path concerns north-south traffic for domains the customer owns and controls.

This does not mean runtime detection is slow or the integration is malfunctioning. It means a live observation and the latest governed-service view need not describe the same instant. The relevant buying question is how much delay a particular workflow tolerates between a service change, its correct identification and an actionable finding.

Measure the completed association

The same guide distinguishes applying a suggested remediation policy from confirming a finding has cleared. A subsequent scan supplies that confirmation. A policy count is therefore not an incident-reduction measure, just as a populated inventory is not a coverage audit.

These boundaries sharpen the adoption claim. Twenty-plus organisations demonstrate reported use, but disclose neither how much of their API estates is connected nor the effort needed to keep identities aligned. No price, deployment-wide freshness guarantee or independent effectiveness result accompanies the release.

The integration can make existing investments more useful by attaching security context to a service people can govern. Its value will be clearest where teams can show matching coverage, understandable update age and a completed remediation loop. A clean-looking page without those denominators can still leave the buyer unsure what has actually been checked.

Sources

Akamai's September update; MuleSoft's June announcement; Risk-correlation documentation; Portfolio registration boundaries.