Many security applications were originally built for monolithic applications and on-premise data centers.
However, more and more applications are now constructed with microservices hosted across different clouds or data centers, connected through APIs.
This approach certainly accelerates deployment but also introduces security risks. Risks that require extensive, real-time, accurate data and context to mitigate—resources that would have been readily available had applications been deployed on-premises.
With the advent of cloud and API adoption, a different approach was necessary, leading to the introduction of agent and agentless methods.
Although each method was designed to serve distinct needs, they are often unfairly compared as if one could meet all requirements while the other is demonized. As a result, your team might end up with an option that is convenient for a vendor rather than the best fit for your needs.
Like most aspects of life, the truth about deployment models is not absolute but depends on your circumstances. In this blog, we explore this reality to help you make a well-informed and prudent decision, avoiding the propaganda of vendors who are reluctant to go the extra mile.
An agent is a code snippet a vendor provides that runs on client machines alongside application workloads without affecting its runtime. This does not refer to an in-app agent, but a language and framework-agnostic agent like our eBPF sensor. On the other hand, agentless deployment uses existing software (load balancers, firewalls, CDNs, and gateways) present in customer environments to capture traffic.
As previously iterated, there are no absolute right or wrongs, there are certain characteristics of both approaches that you should be aware of to reach a well-suited conclusion.
We have outlined and explained 5 major factors below:
The agentless approach is the clear winner here. Agents, deployed deep within enterprise networks, require approvals and permissions from multiple departments, which can take weeks to quarters in large enterprises.
Deployment may also be complex because applications are split across various clouds and physical servers and trust and compliance barriers for installing the agent.
In contrast, agentless approaches are simple plugins (e.g., Cloudflare Workers, AWS Lambda) that can be installed within days. This ease and ability to demonstrate value immediately are key reasons behind adopting agentless approaches.
While other instances of Application Security suggest otherwise, agents are typically more cost-effective for API Security when strategically built.
In pre-production environments, they must capture and process less than 5% of the API traffic to learn and map API behavior. There is no additional cost since the agent draws minimal CPU and memory from already paid-for cloud servers. The vendor can further tweak this minimal use as they control the agent.
Agentless approaches vary by vendor. For example, CloudFlare Workers are not currently charged, but costs for Lambda users can add up quickly. Enterprises or vendors cannot control the amount or extent of API traffic captured, making agents a more economical option with the right architecture, especially against certain agentless approaches like Lambda.
Like everything security, API Security products cannot be ignored after deployment.
Agentless approaches often require little to no effort on the part of enterprises as they are regularly maintained and upgraded by the vendors.
Each enterprise has different goals for API Security. If your goal is early remediation and compliance success, agentless approaches are insufficient.
As they cannot provide a complete, accurate inventory of your entire API ecosystem along with detailed documentation, let alone other details needed for API testing in pre-production environments against all offensive, defensive, and business logic exploitations.
Agentless solutions cannot capture details as they run in an alternate path. Whereas Agents due to being deployed in line with applications can provide a granular view of:
Agentless solutions miss third-party and internal APIs, as they only monitor traffic from external APIs, which account for less than 20% of all traffic. This leaves a significant part of your attack surface unaddressed, providing opportunities for successful attacks. Agentless approaches also depend on cloud, frameworks, and languages, further reducing visibility.
Most of our customers report gaining much more visibility with minimal effort to install and maintain the sensor compared to agentless approaches.
Misconfigurations constitute a large number of breaches, making flexibility in data definition, capture, sampling, and processing crucial.
An agent, like ours, is highly configurable and programmable, offering flexibility to capture traffic from specific microservices while excluding others.
Agentless approaches provide little to no flexibility and thus affect the cost, scale, and performance poorly.
For example, if you are performing API Discovery using traffic mirroring, the compulsion to process data in the cloud without being able to discard any leads to a significant spike in cloud usage and cost.
Both agent and agentless deployments have their advantages and trade-offs.
If you want to get started immediately without committing much of your budget, our agentless approaches can discover your external APIs with minimal cost.
At Levo.ai, we offer both solutions to our customers. If you're ready to dive deep into your security efforts, our agent-based approaches like the eBPF and PCAP sensor are useful.
Want to find an approach that best suits you?
Here are all the different ways Levo can perform instrumentation with your APIs:
.png)
Book a demo to see this live in action!
.png){kind=logo}
.svg)
.svg)
.svg)
