I sat in on an Anthropic webinar this week, “Secure the Advantage: A CISO’s Guide to Agentic AI.” One part stuck with me, but not in a good way. In a gum on the sidewalk kind of way. They emphasized relying on your existing security stack. They touted extending what you have, integrating with the tools your team already runs, and my favorite, don’t make security teams stand up a whole new layer.
I get their angle. Organizations are nervous about deploying agents, and security keeps showing up as the reason. Anthropic wants to reduce friction in deploying agents, and a new security layer feels like friction. But the advice is misguided, and I hear the proof of it from customers every week. Organizations are holding back on deploying agents because they can't secure agents with the tools they already own.
You know we’re going to dig into why.
Why your existing stack falls short
Identity. Agent identity today is a total cluster. Most local agents just inherit the human’s permissions or take other non-human identities (NHI) for MCP connections. You lose any semblance of who is doing what. Fine-grained access control for agents is technically possible, but doing it at scale is painful. Almost every company I talk to has just given up on a dedicated solution while they wait for Okta and Microsoft to figure it out.
EDR. This is the one I hear the most, “Won’t CrowdStrike solve this?” Every major EDR vendor bought an LLM firewall in 2024. Every major EDR vendor has failed to properly integrate those into their product, but will be the first to sell you agent security. Here’s the rub: first, those LLM firewalls were built to inspect prompts, and we're well beyond prompt-level defense. That's a fool's errand. Today's game is about preventing unauthorized actions, not about determining whether the prompt output was toxic. Most EDRs can do a decent job of spotting shadow AI running on the endpoint, but they have zero visibility into what those agents are actually doing.
So sure, EDR may eventually catch up. But if we waited for McAfee to build EDR, where would we be?
Network. Network tooling is great if your users are running web-based agents in a browser, like ChatGPT. For local agents, you might be able to capture the traffic to the LLM, but that depends on what you’ve set up. We’re still in the LLM firewall approach there. It’s not enough.
SIEM. The classic move: pump every log into the SIEM and call it visibility and call it a day. But it's a bottomless pit. Are you building detections off agent log data? Maybe, kinda, sort of? Detecting suspicious or unauthorized agent activity isn’t just keyword matching in logs. It has to include monitoring behaviors and actions. That doesn't translate. And the bigger problem is blocking. Agents operate at machine speed (yes, I hate that phrase too), so seeing the damage after the fact isn't security. You don't want to read tomorrow's newspaper to realize your house burned down. You want to prevent the fire in the first place.
DLP. In theory, DLP is well-positioned to detect data leakage and unauthorized access to sensitive data. And yet I've never met a company that does DLP well for humans, but somehow they're going to nail it for agents?
All of these tools barely scratch the surface of securing agents. They’re too narrow in their approach and visibility.
How about those AI Security Startups?
Before we go further, let's get specific about what these startups should actually do. There are four capabilities that matter:
Knowing every agent in your environment
Surfacing risky configurations
Enforcing granular permissions
Detecting, blocking, and investigating rogue activity in real time
Get all four right, and you've got something your existing stack literally cannot do.
The default move when the incumbents are behind is to find a startup that solves the problem and ride with them until the big vendors catch up. This is how the cycle has always worked. The incumbents are big, slow, and protecting existing revenue. They can't reorient around a new problem fast enough, and even when they try, it's bolted on rather than built in. That's how you end up with EDR vendors slapping LLM firewalls onto their stack and calling it agent security.
The startup advantage isn't just speed. It's focus. When the entire company exists to solve one problem, you get a product built for that problem rather than around it.
The biggest complaint I hear is "I'd need five or six different startup tools to address this." That's mostly true today. There isn't a single startup far enough along to be a true platform for agentic security. And most startups oversell their capabilities worse than EDR vendors do. But, there’s power in focus.
You also get something you almost never get with an incumbent: influence. Startups will actually build what you need. They'll take the call, hear your use case, and ship the feature. If you’re a mid-market company, good luck with getting the incumbent’s attention to impact the roadmap.
Yes, there's risk. Startups get acquired, run out of money, or pivot. But the math is rarely as scary as it feels. If a startup gets acquired by an incumbent you already work with, you're fine. If they go under, you swap. The bigger risk most teams underweight is the cost of doing nothing while you wait for your incumbent to figure it out. That's not a neutral position. That's an active decision to absorb every agent-related risk.
The other thing startups give you is optionality. You're not betting the farm. Most teams I talk to run a startup alongside their existing stack to cover the gap, not replace anything. If the incumbent eventually ships something credible, great, you've got a migration path. If they don't, you've got actual coverage in the meantime.
The history of cybersecurity is pretty clear on this. The companies that solve emerging problems aren't the incumbents. They're the ones close enough to the problem to move fast and focused enough to actually solve it.
Choose your own adventure
So AI security right now is a choose-your-own-adventure. You've got two paths:
Path 1: Wait for the incumbents. They'll get there eventually. It could be years. In the meantime, you're either deploying agents with known gaps or holding back deployments your business wants.
Path 2: Take a bet on a startup. You get near-term coverage that's actually built for the problem. You also get to influence the product. Nobody gets fired for hiring the known names. But they do get fired for ignoring a known risk when a security incident happens.
Both paths have risk, but they're different kinds of risk. The incumbent path is the risk that your security program stays flat while agents proliferate. The startup path is the risk of having to swap vendors in a few years. One is a security risk to your business. The other is a time and procurement risk to your team. Pick which one you'd rather explain after an incident.
It comes down to your risk appetite and what you're optimizing for. If you're deploying agents at any kind of scale across your business, the near-term gap matters more than the long-term vendor question.
Either way, do the math honestly. The advice that your existing stack has you covered isn't math, it's wishful thinking with a vendor's logo on it.
If you want to see what runtime visibility and control for agents actually looks like, that's what we're building at Evoke. Let’s set up a demo.
If you have questions about securing agents, let’s chat.


