Hypershield: using AI to make vulnerabilities non-exploitable

Is the future of security allowing Artificial Intelligence (AI) to make changes at the kernel level? How does Extended Berkeley Packet Filter (eBPF) and AI protect our environments from CVEs? 

During Tech Field Day extra at Cisco Live EMEA Amsterdam 2025, Andrew Ossipov and Jeroen Wittock presented Cisco Hypershield: AI-Driven Security for Dynamic Environments. 

One use case they talked about was distributed exploit protection, where eBPF provides the information what is in your environment, not just what libraries are being used but exact versions, what is being called by the applications. Then, using their AI, which looks at the CVE database, validates if your systems are vulnerable.

Right now, they make use of their own algorithms and Machine Learning (ML) to build protections, or ‘shields’, in order to remove that vulnerability so your system is non-exploitable. 

If you don’t know what eBPF is, a whole 30-min documentary is available, but to summarise briefly it’s an abstract virtual machine which sits in the kernel level and allows an extremely fast way to monitor and take action on a device without having to actually edit the kernel itself. 

If you haven’t been living under a rock, you may hear kernel and think CrowdStrike outage event. This approach is different because it’s a kernel feature, therefore it would function differently. However, as a security person I would not claim it could never cause an issue - any solution has that risk, we just need to ensure the right controls are there to limit the impact.  

Why is this cool? Well, I’m not sure about you, but the number of vulnerabilities that have been announced during holiday season, and requiring teams to validate if the organisation is vulnerable or not, outside business hours and often on the holiday itself, are more than a bit annoying. 

My years as a consultant, I experienced first hand organisations, who didn’t actually know fully what was in their environment, never mind the needs of the software. Many development teams that didn’t know exact dependancies, and may even laugh if you asked if it was documented. The idea that this solution could tell me what’s in place and if it’s vulnerable immediately, with high degree of certainty, is well attractive! 

On top of educating me on what I should probably already know, as I briefly said above it then builds a ‘shield,' i.e. propose the changes required to remove vulnerability from your environment. Working with a variety of organisations over the years, a consistent I ran into was after finally identifying if they are vulnerable, what next? This solution compliments the analysts skills, by building those 'shields' and proposing the changes needed to secure your environment prior to being exploited. Doing all this, while still letting our systems run and carry out the tasks they need. However, even making this shield, you’re making a change - have you broken something? 

Currently, the 'shields' being built require human validation that yes they’re stopping the vulnerability, but no they aren’t then blocking legitimate activities. As a security person, I’m not going to simply deploy something without my own form of validation. They cover this by taking live data and checking, if we deployed the 'shield', would it cause an outage? 

It does this by being ran in parallel to your live environment, so it could even see as a sort of detective view if we were to make the changes required to make this vulnerability non-exploitable - would your solution(s) still continue to run smoothly? To do this, you have your data plane, this is where everything is running, it’s the ‘real-life’ packets. Then on the shadow plane, it’s the same packets, they’re not stored, but here their tooling is checking would our ‘shield’ cause issues? i.e. dropped packets, increased latency, &c. Currently, you can’t go back through, i.e. point in time analysis, or set the time frame that the packets are monitored. They mentioned that may change in the future, and from my perspective I think that's worth it. To give me more confidence that I am not going to cause an outage.

Looking at what it does now, however, it allow a more accurate validation as it's real-life data and according to them reduces overhead of requiring both production and testing environments. Two thoughts I had on this: 

1. Whilst fabulous you are working on real-life data, and possibly don’t have inaccuracies when the production / testing environments have miss matches. There are still some situations I don’t think this is feasible. Security is built on confidentially, integrity, but also availability. Some situations I can recall were so fragile, that this approach would be highly unlikely in production, so maybe I would still have it setup, but in the testing environment regardless.

2. I appreciated that they said you could edit the test thresholds, so for example a test being marked as passed, maybe we need to have it with <1% failure, or we could have up to 3%, you can choose what is appropriate in your environment. You get both a full overall score, the example they gave had 80%, and you can dig into the different test results granularly. However, one point he did mention was the goal is to get to a place where you don’t need the human factor - you just have AI decide is this ‘shield’ safe, and if it assess it as yes, deploys. 

When I used to create a lot of reports for clients, I would draft up a report and share it to a colleague who would then do a peer review with track changes on. When I got it back, I would go through the proposed changes and decide if I was going to accept them or not. When I did peer reviews of other’s reports, I took the same approach. Annoyingly, I found some situations where a colleague I peer reviewed reports for, simply did an Accept All and didn’t read my points. Maybe I am annoyingly thorough, or they just were overwhelmed, however, it did lead to a situation where the client got a report with something that should not have been in there. Plus, many situations where I was pointing out the exact same thing, they never learnt.

Why am I saying this? That final part of point two above bothers me - I agree with the presenters that granular view of validation is attractive, but I disagree that Accept All approach works. Would we not end up in a situation where we were introducing another risk? Yes we aren’t changing the kernel directly, and maybe there are controls in place to stop us from a full outage of the device, but I’m not ready to trust that this approach can’t cause it’s own issues. I will say overall, l do love the idea of a way to get accurate results on our level of risk with vulnerabilities, and the use of AI to identify potential solutions that keep us running but safely - I am just not keen on the accept all point. It's one more tool in our belt for responding to the constant change to our threat landscape, so I am excited to hear how things continue to develop.