You reviewed your application's dependencies carefully. Meanwhile you installed four agents on every production host: an APM agent, a log shipper, a security monitoring agent and an endpoint tool. Each runs as root or with kernel privileges, each auto-updates from its vendor, and each sends data outward continuously.
Your application dependencies are reviewed, pinned and scanned. These are not, and they have more access than the application does.
This post is how to think about that trade, because the answer is not to remove them. For whoever signs off on what runs on production hosts.
What an agent actually has
Not all agents are equal, and the distinctions matter more than the vendor category.
Kernel access. An eBPF agent or a kernel module sees every syscall, every network connection and the memory of other processes. A bug here is a kernel bug, and a compromise is total.
Root on the host. Reads any file, including your secrets on disk, your TLS private keys and the memory of your application if it chooses.
Outbound network, continuously. This is the one people underweight. An agent maintains a connection to its vendor and sends a stream of data. Whatever it decides to collect leaves your environment, and the decision about what to collect is made by the vendor's configuration, which they can change.
Auto-update. Most update themselves, on the vendor's schedule, without a deploy on your side. That means code you have not reviewed arrives on every production host automatically. It is the same property as a tag that moves, applied to something running as root.
Together these describe something with strictly more authority than your application, subject to strictly less review.
The realistic threat
Not that the vendor is malicious. It is that an agent with this shape is a high-value target, and a compromise of the vendor's update channel reaches every host of every customer simultaneously.
That is the same shape as the supply chain attacks everyone now takes seriously in package registries, applied to a channel that most organisations do not track at all. If asked "what changed on your production hosts last week", the honest answer for most teams does not include the agent updates, because nobody records them.
The second, more mundane risk is data. An agent collecting logs, traces or process telemetry is sending a stream that may include what your application put in a log line, including the things that should not have been there.
Questions worth asking before installing one
- What privileges does it need, and does it need them permanently or only at install?
- Can auto-update be disabled, and can we pin a version? If the answer is no, you have accepted continuous unreviewed code changes on every host.
- What does it send, specifically, and can we see a sample? Not the marketing description, the actual payload.
- Can we restrict its egress to a known set of destinations?
- What happens if the vendor's endpoint is unreachable? An agent that buffers indefinitely can fill a disk. One that blocks can take your application with it.
- Has it had security advisories, and how were they communicated?
The auto-update question is the one that most changes your exposure and the one least often asked.
Controls that fit
Pin versions and update deliberately. Treat an agent update like any other dependency: a version bump, in your configuration, deployed through your pipeline. You lose the vendor's rapid fixes and gain the ability to know what is running. For a kernel-level agent this trade is usually worth it.
If you cannot pin, at least record what version is running where, so that after an incident you can answer when it changed.
Restrict egress to the vendor's endpoints. An agent that can only reach its own backend is much less useful to an attacker who compromises it. This is the single most practical control, and it reuses whatever egress restriction you already have.
Scope the privileges down. Many agents request root and function with less. Read the documentation for the minimum, and check whether the container needs the capabilities it was given rather than accepting the defaults from a quickstart guide.
Do not run them on your most sensitive hosts by default. The signing host, the certificate authority, the machine holding the deployment keys. Uniform agent deployment is operationally simpler and it puts the same third-party code on the hosts where a compromise costs the most.
Count them, and remove the duplicates. Most estates accumulate overlapping agents: two log shippers, an APM agent and a monitoring agent collecting the same metrics, an endpoint tool from a previous vendor nobody uninstalled. Each is a separate trust relationship and the redundant ones are pure cost.
Include them in your inventory
Agents are absent from most dependency inventories because they are not in a manifest. They belong there, with the version running, the privileges held, the destinations contacted, and an owner.
That inventory is what makes an advisory actionable. When a widely deployed agent has a vulnerability, the question is which of your hosts run which version, and teams that cannot answer it spend the first day of the response finding out.
The concession
These tools earn their access. An eBPF security agent detecting a live intrusion needs to see syscalls, and a request to remove that visibility because the agent is itself a risk is usually a bad trade. The same is true of APM during an outage.
So this is not an argument for fewer agents on principle. It is that the review they receive is wildly out of proportion to the authority they hold, and two specific things are worth changing even if you keep everything: know what version is running where, and constrain where they can send data. Both are achievable without giving up the capability.
The implication
You have a dependency review process for code your application imports, and a procurement process for software you buy. Agents fall between them: bought like a product, running like a privileged dependency, updated like neither.
Put them on the same list as everything else you depend on. They belong near the top of it.
