What we still need to verify : 3 points in this profile are not yet confirmed against vendor documentation.
- Full list of supported runtime environments beyond Kubernetes: verify against vendor docs
- Depth and coverage of the automated testing module: confirm with vendor
- Current integration list: verify against vendor docs
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Levo.ai collects API traffic using eBPF sensors deployed into the host or cluster. Because eBPF hooks the kernel networking path, the sensor observes request and response payloads without a proxy, without code changes, and without instrumenting each application with a library. For containerized workloads this removes most of the negotiation that traffic based API security normally requires. From the captured traffic it reconstructs endpoints and parameters, generates OpenAPI definitions for services that never had one, and keeps the catalog current.
The distinguishing work happens on top of the catalog. Payload analysis classifies fields carrying sensitive data, and because the sensors see both sides of internal service calls, Levo traces where a data type travels across services rather than only flagging where it first appears. That produces a data flow view: which downstream services handle regulated data, and which endpoints expose it externally. The platform also drives automated testing against the inventory, replaying and mutating captured requests to check for authorization flaws, injection and data exposure, seeded by real traffic rather than synthetic cases.
Where it fits
The sensors run in staging and production, usually as a daemonset in Kubernetes, and discovery is continuous. The catalog and data flow map are security team artifacts, used for inventory, compliance evidence and prioritization. Testing runs from the pipeline against a pre production environment, with findings routed to the owning team. The prerequisite is a runtime that supports eBPF sensors and a platform team willing to run them. Serverless and managed services that do not allow a node level agent fall outside this model.
Strengths
- eBPF capture avoids proxies, sidecars and code changes, making onboarding far less disruptive than mirroring or library instrumentation.
- Sees internal service to service traffic, so the inventory covers APIs that never reach a gateway.
- Sensitive data tracing across service boundaries answers data flow and regulatory questions that endpoint level tagging cannot.
- Generated specifications give teams a usable OpenAPI definition for services that had none.
Limitations
- Tied to environments where you can deploy an eBPF sensor. Serverless and managed platforms are outside its view.
- eBPF agents need appropriate kernel versions and elevated privileges, which some platform teams resist and some managed Kubernetes offerings restrict.
- Smaller and younger than the established API security vendors, so ecosystem integrations and enterprise reporting are less mature.
- Full payload capture at production volume raises data handling and storage questions to answer before rollout.
Who it suits
Engineering organizations running Kubernetes at scale with a platform team comfortable deploying kernel level agents, particularly where internal service to service visibility and data flow mapping matter. Teams on serverless or heavily managed infrastructure, or needing a mature enterprise reporting stack, should look elsewhere.
Used Levo.ai? Recommend it under your own name and title.
Recommend this tool