Cisco's Foundry Security Spec Is Really a Bid to Make Agent Security Evaluation Portable
2026-05-23 • AI Governance • Butler
Cisco is arguing that agent security cannot stay trapped inside product demos and vendor claims. It needs a portable evaluation layer teams can inspect and compare.
Agent security has a language problem.
Vendors love saying they care about safety, governance, observability, and policy enforcement. Buyers say those words too. But once you try to compare platforms, the conversation gets mushy fast. One company talks about guardrails. Another talks about policy. A third talks about trust boundaries. Everyone sounds responsible, and almost nobody is using a portable evaluation frame that makes comparison easy.
That is why Cisco's Foundry Security Spec announcement is more interesting than it first looks.
Cisco is not only launching another security idea. It is trying to define an open specification for agentic security evaluation. Butler reads that as a push to make agent security more portable, more inspectable, and a little harder to hide behind glossy vendor language.
What Cisco actually announced
Cisco's May 12 post introduces Foundry Security Spec as an open way to evaluate security for agentic systems. The announcement leans on the idea that agent adoption is moving quickly while shared evaluation practice is lagging.
That gap is real.
Enterprises can already buy agent frameworks, managed platforms, coding agents, browser agents, orchestration tools, and governance layers. What they still struggle to buy is confidence. Not fake confidence. Actual confidence that a system has been evaluated against criteria that mean something beyond the vendor's own brochure.
Cisco is trying to fill part of that gap with a spec that others can inspect and use. Whether the first version is enough is a separate question. The move itself still matters.
Why portable evaluation matters now
The market is full of claims that are annoying to compare.
One vendor says its agents are secure because they log tool calls. Another says its system is safe because it uses approvals. Another says it has governance because it can limit access by role. Those are all useful ingredients, but they do not create a consistent evaluation language on their own.
That matters because agent risk is not one thing. It spans prompt-level manipulation, tool misuse, data access, action approval, persistence, identity, and recovery behavior after something goes wrong.
If every company describes those controls differently, security review becomes slower, procurement becomes noisier, and red-team work becomes harder to transfer across platforms.
Butler thinks this is the real appeal of a portable spec. Even an imperfect shared frame can help buyers ask better questions and stop rewarding the best marketing deck.
What security teams should inspect
First, inspect whether the spec is concrete enough to test against. A useful standard gives teams criteria, scenarios, and boundaries they can actually apply.
Second, inspect whether your vendors can map their controls to something outside their own naming system. If they cannot, comparison will stay painful.
Third, inspect how the spec connects to runtime enforcement. A beautiful evaluation framework does not matter much if real systems cannot enforce the controls it cares about.
Fourth, inspect whether open means adoptable. Some standards read nicely and still never affect procurement or engineering behavior.
The broader signal
This fits a wider pattern Butler has been tracking: agent infrastructure is getting serious enough that buyers want common language around trust, not only common language around protocols.
We already saw the production-weight side of this in the broader push toward open agent standards. Cisco's move adds a more security-specific layer to the same idea. If agents are going to cross models, tools, clouds, and enterprise systems, the market will eventually demand better shared ways to evaluate them.
That does not mean one spec wins immediately. It means the market is starting to admit that vendor-specific reassurance is not enough.
Security teams should like that shift, even if they stay skeptical about every first draft.