For a decade, network security procurement has been a consolidation story. Buy fewer vendors, collapse overlapping controls onto one platform, reduce the number of consoles an understaffed team has to watch. The logic is sound, and the market has rewarded it.
A new requirement has appeared that the consolidation frameworks do not cover, and most buying processes have not caught up: what happens when the entity accessing your systems is not a person.
The question nobody’s policy answers
Autonomous agents are now doing work inside enterprise environments. They query internal systems, call APIs, read documents, trigger workflows, and increasingly act across several systems in sequence without a human in the loop for each step.
Every identity and access framework in production was designed around a human being who authenticates, does things attributable to them, and can be trained, disciplined or offboarded. An agent has none of those properties. It may act under a service account with far broader permissions than any individual, at machine speed, with no sensible audit trail beyond “the service account did it.”
Ask a security team three questions and watch the answers get vague: which agents are operating in our environment, what can each one reach, and if one behaves anomalously at three in the morning, what stops it?
Most organisations cannot answer any of the three, and it is not negligence — the tooling to answer them is only now arriving, and it is arriving unevenly across the vendor landscape.
Where the vendors have actually diverged
This is where platform selection gets interesting, because the large security platforms are not equally far along.
Scale advantages are real: bigger vendors have more telemetry, broader integrations and more resilient infrastructure. But scale is not the same as being early on a new control surface, and on agent governance specifically, the ranking does not follow revenue. Edgewisely’s comparison of two major secure service edge vendors, including where each leads on AI agent governance is useful mainly because it separates those dimensions rather than assuming the larger vendor leads on everything.
Two details from that kind of comparison deserve more weight than they usually get in evaluations. Neither vendor in this category publishes list pricing, which means your negotiated outcome depends heavily on process discipline rather than published rates. And published vulnerability histories matter: a security vendor sits inline on your traffic, so its own defect record is part of your risk surface, not a footnote.
Consolidation is also happening in the other direction
The second structural shift is the blurring of the line between security operations and IT operations.
A large share of what security teams spend their time on is not adversarial. It is access requests, password resets, provisioning, endpoint issues, policy exceptions — operational work that happens to sit behind a security control. Automating that work with agents is a straightforwardly good idea, and it is where several large acquisitions have recently pointed. Edgewisely’s coverage of a roughly $500 million acquisition of a two-year-old agentic IT automation company reads as a bet that the help desk is the next control point worth owning.
The strategic logic is coherent. Whoever automates the operational workflow sits at the point where access is granted, which is the most valuable position in the stack. It is also the position where an automation failure becomes an access failure, which is precisely why it warrants more scrutiny than a help-desk purchase normally receives.
The model layer is developing its own controls
There is a third development that security teams should be tracking but generally are not, because it looks like a research topic rather than a control.
Model providers have begun formalising how their systems resolve conflicting instructions — establishing a ranked hierarchy where platform-level rules outrank deployer configuration, which outranks user input, which outranks content encountered in documents or web pages. Edgewisely’s explanation of how one provider’s code of conduct turns model safety into an instruction hierarchy makes the point that the ranking matters more than the rules themselves.
This matters operationally because prompt injection is, structurally, a privilege escalation attack: untrusted content attempts to issue instructions that outrank the legitimate ones. A defined hierarchy is the beginning of a defence, in the same way that separating code from data was the beginning of a defence against injection attacks in databases.
It is not a complete defence, and security teams should not treat a vendor’s published hierarchy as a control they have verified. But knowing which hierarchy your provider implements is now a reasonable due diligence question, and almost nobody is asking it.
What an agent incident actually looks like
It helps to picture the first serious incident concretely, because the abstract version does not drive urgency.
An agent is deployed to handle a routine internal workflow. It runs under a service account provisioned generously, because scoping it tightly would have delayed the launch and the team intended to revisit it. It reads from a document store that was indexed wholesale, because selective indexing was harder. One of the documents it retrieves contains text placed there by someone outside the organisation — a supplier’s attachment, a submitted form, a web page it was asked to summarise.
That text contains instructions. The agent, having no reliable way to distinguish content from command, follows them. It retrieves something it should not have, or sends something somewhere it should not go, at a speed no human process would have allowed.
The subsequent investigation is where the real damage sits. The logs show a service account performing authorised actions. Nothing was compromised in the traditional sense — no credential stolen, no vulnerability exploited, no control bypassed. The agent did exactly what it was permitted to do, with instructions from an untrusted source, and every control in the environment was functioning as designed.
That is the shape of the problem. It is not a breach in the way existing playbooks describe one, and the controls that would have prevented it — tight scoping, content and instruction separation, anomaly detection on non-human identities — are precisely the ones most organisations have not implemented.
What to add to your evaluation
Five questions, none of which appear on standard vendor scorecards.
Can you enumerate non-human identities? If the platform cannot show you every agent and service identity operating in your environment, it cannot govern them.
Can you scope agent permissions below the service account? Agents inheriting broad service-account rights is the current default and the most likely source of the first serious incident.
Is agent activity distinguishable in the logs? An audit trail that cannot separate human from agent action is not an audit trail once agents are doing meaningful work.
What is the kill switch, and who can pull it? Revoking an agent’s access mid-task should be a one-click operation at a defined authority level, not an engineering exercise.
What is the vendor’s own security record? Inline vendors are part of your attack surface. Their disclosure history is relevant to your risk, and they will not volunteer it.
The uncomfortable summary
Security teams spent a decade building controls for humans and endpoints. The thing now accessing systems in volume is neither. The vendors are building for it at different speeds, the frameworks have not been rewritten, and most organisations will discover the gap through an incident rather than an audit.
The teams that get ahead of this will be the ones who start by counting their agents. That number is almost always higher than expected, and the exercise of producing it tends to end the debate about whether this is urgent.
