For most of the last decade, enterprise security teams built their defenses around a fairly stable idea: humans click things, and systems execute predictable code paths written and reviewed by engineers. Autonomous AI agents break both assumptions at once. An agent can read an email, decide to take an action, call a tool, and execute a multi-step task without a human in the loop at any point in the process — which means the attack surface security teams have to defend has quietly expanded to include the agent’s reasoning process itself, a target category that did not exist five years ago.
Prompt injection is the clearest example of why this matters. A malicious instruction hidden in a document, a web page, a calendar invite, or an email can be picked up by an agent during a routine task and treated as a legitimate command, because the agent has no reliable, built-in way to distinguish “instructions from my operator” from “text I happened to encounter while doing my job.” Traditional security tooling was never built to inspect that boundary, because that boundary did not exist before agents did. A firewall does not know how to evaluate whether a sentence buried in a PDF is a legitimate instruction or an attack.
What makes this especially uncomfortable for security teams is how ordinary the entry points look. It is rarely a sophisticated exploit that compromises an agent — it is a support ticket, a shared document, or a routine email that happens to contain a few sentences crafted to look like an authoritative instruction. The agent has no context to know that the email came from outside the trust boundary the rest of the organization takes for granted, and by the time a human notices the output looks wrong, the agent may have already taken an irreversible action.
Multi-agent systems compound this problem further, since an instruction injected into one agent can propagate to others it communicates with, each treating the previous agent’s output as trusted input rather than something that needs independent verification. This creates a chain-of-trust problem that does not exist in single-agent deployments, and it is one of the reasons security researchers have started paying particular attention to how agents hand off tasks and context to one another rather than only how they interact with the outside world directly.
Enterprise buyers have started to notice this gap, and the money is following at a pace that reflects genuine urgency rather than speculative interest. Security vendors focused specifically on protecting AI agents and the models underneath them have raised very large rounds recently, backed by exactly the kind of enterprise and financial institutions that would be the first and most consequential targets of an agent-based breach. Edgewisely’s reporting on one such funding round captures how seriously large enterprise buyers are now taking this category, treating agent security less like an emerging niche and more like a mandatory layer of infrastructure that has to be in place before agents get real autonomy.
This same urgency is visible in how some of the largest infrastructure companies are responding. Rather than leaving agent security entirely to a fragmented startup ecosystem, major hardware and cloud platforms have started building dedicated security models into their own stacks, treating agent defense as a core platform capability rather than an add-on a customer needs to source separately. Edgewisely’s coverage of one such platform move shows how quickly this category has gone from a niche concern to something the largest vendors in the industry feel compelled to own directly.
The practical implication for any company deploying agents internally is that access scoping matters more than it ever did for traditional software, where the blast radius of a bug was usually limited to what a specific piece of code was hard-coded to touch. An agent should have the narrowest possible set of permissions needed for its specific task, revoked or re-scoped the moment the task changes. Its actions should be logged with the same rigor applied to a privileged human account, not treated as routine application telemetry. And any action with real-world, hard-to-reverse consequences — sending money, deleting data, contacting a customer directly, modifying a production system — should have a human checkpoint until the underlying models and their surrounding controls are proven reliable enough to remove it.
There is also a governance dimension that boards are starting to ask about directly. Who inside the organization is accountable when an agent takes an unauthorized action, and how quickly can that action be detected and reversed? Companies that can answer this clearly, with an actual incident response plan specific to agent behavior, are in a fundamentally different risk posture than companies that are still treating “the agent did something unexpected” as a hypothetical rather than an eventuality worth planning for in advance.
Testing for these failure modes also requires a different mindset than traditional security testing. Red-teaming an agent means actively trying to manipulate it through the same ordinary-looking channels a real attacker would use, rather than only probing for conventional software vulnerabilities. Some organizations have started running continuous adversarial testing against their own deployed agents specifically to surface prompt injection vulnerabilities before an actual attacker does, treating it as an ongoing discipline rather than a one-time pre-launch review.
Agents are genuinely useful, and that is exactly why this problem will not go away by ignoring it or hoping the next model release fixes it on its own. The organizations treating agent security as a core requirement rather than an afterthought are the ones that will be able to deploy agents more aggressively than their competitors, precisely because they will be the ones who can trust the blast radius when something inevitably goes wrong.
