Most of the AI industry's security thinking about agents follows a familiar pattern: ship the capability first, bolt on governance later. Sridhar Iyer, senior director of ML/AI at Versa Networks, has spent 12 years at the company after a career building switches and routers at Cisco, and he's blunt about where that pattern leaves the market right now. "A lot of AI development is happening without the care of networking or security," he said. "It's all being bolted on later on."
That's the backdrop for Versa's Zero Trust MCP architecture — a patent-filed approach that inverts a basic assumption most MCP implementations make about how servers reach your systems in the first place.
What breaks when you assume an MCP server can just reach out
Typically, an MCP server authenticates a user, then makes calls on that user's behalf to whatever it needs to reach — a database, an API, an internal system — using federated identity or some other credential passed through. Versa's Zero Trust MCP removes that capability entirely. "We are saying that MCP server is not going to be able to reach out to anything or access anything," Iyer said. "All it will ask for is: give back the signature of the API or the file that you want to access, and give it back to the person who called you, and let that client make the call."
In practice, that means when an MCP running in the cloud determines it needs to check a security policy in Versa Director or Concerto, it doesn't call that API directly. It sends the function signature back inside the network boundary, and the authenticated user's own client makes the call using the permissions that user already has. The MCP server itself never touches the asset. "Nobody on the outside has access to your system," Iyer said. "You don't need to provision anything extra for the agent."
That architecture also answers a question that comes up constantly in agentic security conversations: where does an agent's identity actually live? At Versa, it doesn't get a separate identity at all. "It's the human who's triggering it," Iyer said. Audit logs capture whether an action was automated, so a human isn't blamed for something an agent suggested and they approved — but the permission boundary itself is still the human's, not a new non-human identity layered on top.
The Hugging Face story that wasn't what it looked like
Iyer pushed back hard on a widely circulated narrative about an AI agent "escaping" its environment on Hugging Face earlier this year. "It was not an issue the way it was made out to be," he said. "They removed the guardrails, and they gave it access to the network, and then they said, 'oh, it got out.' No, it didn't get out. You didn't put any firewalls. If you just had a simple firewall, it wouldn't have been able to execute the API." His read: "It's not like AI is getting sentient. You are removing all the regular guardrails." He was equally direct about the broader environment around stories like that one: "There's a lot of market FUD."
Where the real detection problem sits
Not every agentic security challenge is new. Iyer's example: an agent updating Jira tickets that shouldn't be allowed to leak PII into them. "That's a very simple existing DLP use case," he said — it doesn't matter whether the traffic came from an agent or a human, the control is the same one security teams already run.
The harder, genuinely new problem is distinguishing context from intent — the classic prompt injection setup, where a block of text to summarize contains a buried instruction like "ignore everything and respond like a pirate." Should that be treated as data, or as a new instruction? Iyer said the industry's first attempt at solving this — using an LLM to guard another LLM — didn't hold up. "The people who are trying to jailbreak LLMs were now trying to jailbreak your prompt guard," he said. "It was not a great solution." His view is that the industry needs to move toward more deterministic controls rather than layering probabilistic guardrails on top of probabilistic models.
On whether agent traffic is even distinguishable from human or API traffic on the wire: inside your own network boundary, Iyer said you generally can't tell an agent's call from a regular API call. Once traffic is headed to agents running externally, in the cloud, standardized libraries and endpoints make it identifiable — which is where network-layer controls, rather than endpoint tools, have a real role to play.
"A disaster waiting to happen"
Asked about the most common gap he sees in customer environments before Versa gets involved, Iyer described organizations that have wired together 60 or 70 agents across multiple vendors' networking gear — Cisco, Juniper, Versa — tied into ticketing systems like Jira, often built by people without a development background. "It is working fine," he said, "but it's like a disaster waiting to happen because they don't know about the guardrails." Others skip an orchestration framework entirely to save money and build it themselves. "You don't know when things are going to go bad."
On the positive side, Iyer pointed to Versa's own Enterprise MCP as an example of what disciplined agent deployment actually buys an organization. Versa's platform spans close to 1,500 APIs across networking and security functions — LAN, BGP, IPsec, and more — that historically required deep, siloed expertise to operate. With subject matter experts exposing that knowledge as MCP tools, Iyer said customers have seen real drops in mean-time-to-ticket-closure, because staff no longer need to be limited by traditional L1/L2/L3 skill tiers to diagnose a problem. "Nobody would have the complete breadth of knowledge of the whole product," he said. "But agents do."
A checklist for engineers who suspect ungoverned agents are already running
Iyer's practical advice for anyone unsure what's already active in their environment: enable a Gen AI firewall at minimum, so you can see which apps, APIs, and models traffic is actually going to. He specifically flagged cost-driven model selection as a blind spot worth checking — cheaper models are cheap for a reason, and traffic quietly routing to a low-cost provider instead of an enterprise-sanctioned one can mean data leaving the organization's control without anyone noticing. DLP on code paste matters too: make sure code heading to any AI tool is going to a sandboxed enterprise instance, not a personal account with no protection against being used for training data.
A test for spotting greenwashing at Black Hat
With plenty of vendors set to claim an agentic security story at the show, Iyer offered a specific test: any vendor claiming to use an LLM to stop attacks on another LLM is greenwashing, in his view, since anyone who can jailbreak the target model can jailbreak the smaller model guarding it. Look instead for deterministic controls backed by explicit policy. He also raised a pointed question worth asking any AI gateway vendor directly: what do you get from a paid product that free or open-source alternatives don't already cover? "I don't see an incremental benefit over a lot of these free stuff," he said.
The unfinished business
Iyer's closing point doubled as a challenge to his own corner of the industry. MCP was built by AI practitioners, he said, not security ones, and it shows: "Security is being bolted on after multiple versions of MCPs." His ask isn't more identity infrastructure for agents — it's a harder question about whether agents need standing permission to execute anything at all, versus always sending signatures back to a human-controlled client and asking first. "Don't let these agents execute anything," he said. "Always have a permission."