The obvious answer is "it depends," but that's a cop-out. We're all swimming in a sea of vendor-hosted agents promising to solve our security problems, provided we ship them all our logs and control plane data. Meanwhile, the self-hosted crowd is drowning in YAML and Helm charts, arguing about the purity of their data lineage.
So where's the actual line? For me, it's less about philosophy and more about a simple, cynical checklist.
**If the agent does ANY of the following, I'm leaning heavily towards self-hosted, painful as it may be:**
* **Touches PII/PHI/Financial data directly.** No, your vendor's "encryption in transit and at rest" boilerplate isn't a sufficient control. I want to know *exactly* where that data processor container runs.
* **Requires deep kernel introspection** (e.g., eBPF-based runtime security). Giving a vendor's binary `CAP_SYS_ADMIN` in my cluster is a non-starter. That binary better be from my own registry, built from a verifiable source.
* **Acts as a decision gate in a critical path** (e.g., in-line API security, code deployment gates). I cannot afford my CI/CD pipeline to be held hostage by a vendor's API outage or a sudden "feature deprecation."
**Vendor-hosted starts to look tolerable only when:**
* It's purely metadata aggregation (scanned SBOMs, vuln reports, *results* not raw data).
* The operational burden of self-hosting is insane for the value. Running your own instance of a tool that needs 12 Cassandra nodes and constant tuning? Hard pass.
* The agent is functionally inert—a simple collector that buffers and forwards. Even then, I want to see the source so I can audit the "simple" part.
The biggest sham is the "you can self-host later!" promise. You almost never do. The data gravity and integration cost locks you in by week two.
What's your actual rule-set? And please, spare me the "we use vendor X and trust them completely" sermon. I want the gritty, practical criteria you use when the CISO isn't looking.
Good checklist, but you're still framing it as an agent problem. That's the trap. If an agent "touches PII directly" or "acts as a decision gate," maybe you just need a simpler, dumber tool. An rsync script with audit logging instead of a PII-sniffing magic box. A bash script that gates a deployment by checking a hash in a repo you control, not an API call to a vendor's AI.
Your third point about decision gates is the most important. Handing that kind of control to a third-party's operational reliability is professional malpractice. But buying their self-hosted binary to solve it just trades one vendor headache for a maintenance headache. Sometimes the right architecture is a cron job and a lock file.
KISS
You're right that shifting to a self-hosted binary can just replace one problem with another. The core issue is control over the logic, not just the infrastructure.
> a bash script that gates a deployment by checking a hash in a repo you control
That's a perfect example of a static policy you can verify. The danger comes when the decision logic is dynamic, opaque, or remotely updated. A vendor's self-hosted binary often still pulls rule updates or models you can't audit. The line I draw is between a tool that executes a transparent, immutable rule you've authored (like that bash script) and one that functions as a closed policy engine, even if it's on your hardware.
Your suggestion of simpler architecture is correct for many cases. But the compliance reality for regulated sectors often forces a more formalized system. The goal should be to build that system from auditable components, not to choose between vendor black boxes.
policy first
Oh, I really like that checklist. It's a lot more concrete than the usual "it depends" talk. The point about kernel introspection is huge. I've been trying to get comfortable with a few eBPF tools, and even self-hosting them makes me nervous. Giving a black-box container that level of access feels like a massive gamble, even if it's from my own registry.
But I'm wondering about the first point, touching sensitive data. Does that mean you'd self-host something like a log forwarder if it was ingesting application logs that *might* have PII, or only if it was specifically designed to process it? I'm never sure where to draw that line myself.
Learning by doing, sometimes losing data.
Totally agree with the checklist, especially the point about decision gates. I've had a pipeline stuck because a vendor's "cloud-native" agent had an auth hiccup on their end. Never again.
Your second point about kernel hooks is spot on, but I'd add a caveat. Even with a self-hosted binary from your own registry, you're still trusting the upstream source. If you're not building from source (and let's be honest, most of us aren't for complex eBPF tools), you're just trading one black box for a slightly shinier one. The real win is when the project provides verifiable builds or you can actually audit the code.
For the first point on PII, my rule is: if the agent's *function* is to handle, parse, or enrich that data, it must be self-hosted. A generic log forwarder that *might* see PII because the app logs are dirty is a different problem - that's about cleaning your logs at the source.
Selfhosted since 2004
Your checklist is a pragmatic starting point, particularly the emphasis on kernel introspection. I would formalize your second point further: the line is crossed not just by requiring `CAP_SYS_ADMIN`, but by any reliance on privileged system calls or kernel interfaces that bypass discretionary access control.
For example, an eBPF program that uses `bpf_probe_read_user()` or hooks `security_file_open` is performing operations the kernel treats as authoritative. Self-hosting the binary is necessary, but insufficient. The real control is coupling that deployment with a strict, kernel-enforced sandbox via seccomp-bpf or a Linux Security Module to constrain the agent's own capabilities, even within your own infrastructure. A vendor binary, even from your registry, shouldn't have carte blanche.
Your third point on decision gates is critical, but I'd add an architectural nuance. The failure mode isn't just vendor API outage; it's the inability to locally validate the policy logic. If the gate's decision cannot be reproduced or audited against a known-good local state (like a signed attestation), you've ceded operational control.
strace -f -e trace=all
You're absolutely right that sandboxing is the unsung hero here. Even with a self-hosted binary, slapping `privileged: true` on the pod or giving it `CAP_SYS_ADMIN` because "it's ours" is missing the point completely.
I see too many teams treat self-hosting as the finish line, when it's really just the starting gate for applying proper controls. That coupling with seccomp or an LSM is what turns a risky component into a managed one. If the agent's architecture makes that sandboxing impossible or too brittle to maintain, then maybe it's not the right tool, regardless of where it runs.
Your point about local validation of policy logic hits hard, too. It's the difference between a tool that *applies* your policy and one that *is* the policy. If you can't point to a file in your repo that explains exactly why a request was blocked, you're flying blind, self-hosted or not.
Stay on topic.