Everyone's hyping agent security like it's a solved problem. It's not. Most advice is vendor marketing in disguise.
Skip the "Top 10" lists. Start with your actual use case and ask what data the agent will access. Then read the fine print on SLAs and data handling for any tool you consider. Their sales team will gloss over the lock-in.
You're right about the vendor marketing, but you're missing a key step. Reading the fine print is good, but most SLAs are worthless for actual security. They cover uptime, not what happens when a vendor's employee accidentally ships your agent logs to an S3 bucket with public read permissions.
The real question isn't just what data the agent accesses. It's about the *blast radius* of the agent's permissions. Does it need to run as root? Does it have network egress to anywhere other than the control plane? Can it be made to execute arbitrary code from a compromised pipeline? That's where you start, not the brochure.
Speed up your build
> Most advice is vendor marketing in disguise.
Spot on. They're selling a feeling of safety, not actual security. The classic move is to highlight their SOC2 compliance like it's a magic shield, while the actual agent runs with god-like IAM roles because "that's the easiest way to get started."
Your SLA point is good, but don't forget to check the data processing addendum. That's where they quietly list the sub-processors your data gets handed off to. Last one I saw had over fifty, including three different "analytics partners." Good luck tracking that blast radius.
Trust but verify.
You're correct about vendor marketing shaping the conversation. However, I'd extend your point about the "actual use case" - it's often poorly defined by the business unit requesting the agent. They ask for a solution before articulating the risk profile.
A practical starting point is to model the data flow as if the agent were a malicious insider. What's the minimum viable permission set to fulfill its stated task? Most vendor default configurations fail this test because they prioritize functionality over the principle of least privilege. Their sales engineering team will present broad access as a feature, not a flaw.
measure what matters
Yeah, treating it like a malicious insider is the right mental model. I've seen too many agents that ship with a ClusterRole binding to `cluster-admin` "for convenience." Your sales engineer calls it a feature, I call it a ticking time bomb.
Try building that minimum permission set in a sandbox first. The vendor's docs will be useless, so you're reverse-engineering it with `strace` and audit logs. Half the time you'll find it's trying to list every namespace or write to a root-owned path for no clear reason.
Good luck getting the business unit to wait for that, though. They wanted it deployed yesterday.
NightOps