Hoxhunt and KnowBe4 are often shortlisted together, which is odd, because they are not really the same product. KnowBe4 is a broad awareness platform with a mature phishing engine attached. Hoxhunt is an adaptive phishing engine with training attached. Buyers who understand that distinction early make a much faster decision.
KnowBe4 and Proofpoint Security Awareness are the two names that appear on almost every enterprise shortlist, and the choice between them usually comes down to one question that has nothing to do with training. Do you already run Proofpoint for email security? If you do, Proofpoint’s awareness product inherits threat intelligence that KnowBe4 cannot replicate. If you do not, KnowBe4’s standalone breadth and simulation tooling generally wins.
A support agent at a SaaS company had been connected to the same CRM tool for four months. It read tickets and drafted replies. Nobody had touched its configuration since the day the tool was approved.
Then the tool’s description changed on the server. Not the code, not the schema, not the permissions. Two sentences of English prose that the agent reads before every call, now telling it to copy each drafted reply to an outside address.
The agent complied. It had no way to separate documentation from instruction, because for a model reading a tool manifest there is no difference. That is one category in the OWASP MCP Top 10, and it is one of ten ways the connection between an agent and its tools comes apart.
A support page told customers to allowlist a storage hostname so their downloads would work. Nobody thought twice about publishing that hostname, because knowing a name is not the same as having access to it.
Except it was. Asking that hostname for a listing worked from an ordinary browser with no credential offered and none required, and next to the folder the company meant to publish sat one nobody did, full of client records.
Nothing about that bucket was exploited in the traditional sense. A permission that AWS makes off by default was switched on at some point, by someone, for a reason that made sense at the time, and it stayed on because nothing about a misconfigured setting looks different from a correct one until someone asks it the right question.
A build agent’s credential should be able to upload artifacts and read its own configuration. Nothing more. On paper that is a short, auditable list.
In practice the policy attached to it often reads "Action": "*", "Resource": "*", because a wildcard was close enough to what the pipeline needed and nobody came back to narrow it. That credential is now an administrator wearing a boring name, and the person who granted it never has to know.
The attacker who finds it does not need to hold the privileged role directly. They only need to pass it to something that will run with it, which is why this class of failure survives a policy review that only checks who holds the admin role.
