Every security vendor is being asked the same question right now: if AI can write code, can it also break protection? During a recent internal hackathon, Verimatrix decided to stop speculating and run the experiment. We sat down with Dr. Klaus Schenk, CTO of Verimatrix, to talk about what happened when his team pointed a frontier AI model at client-side content protection—and what it taught them about building AI-resilient security.

Key takeaways

  • AI-assisted reverse engineering works but only under expert guidance. Progress came from an adversarial correction loop that presupposes the person driving already knows how to attack the system.
  • There is no shortcut for inexperienced attackers. Without domain knowledge, the output is a confident but wrong analysis, not a usable recipe.
  • Cost is not the barrier; expertise is. The experiment cost tens of dollars in model usage; the roughly 25 expert corrections were the expensive part.
  • AI compresses expert time, so protection designs need to be state-of-the-art. A skilled analyst gets to an understanding of a system faster with AI, which raises the bar for how much headroom a design should carry.
  • AI-resilient design means leaving no known attack vector to find.


The takeaway is neither “AI changes nothing” nor “AI breaks everything”—it is that good security architecture is still robust in times of powerful AI, but a weak architecture will be broken more quickly. 

Q: Klaus, why run this experiment at all?

K: Because speculation does not help anyone. Our customers keep asking whether AI changes the threat picture for their streaming services, and the honest answer used to be “we don’t know yet.”  The hackathon gave us the opportunity to answer a very concrete question. Hands-on: Can one of today’s most capable AI models reverse engineer a client-side protection scheme—and if so, under which conditions?

Q: What exactly did you put in front of the AI?

K: We started with letting AI attack our Counterspy’s Trust tunnel product, but even with human guidance, AI did not find exploits. So we lowered security and built a client-side protection scheme specifically for the experiment—deliberately lowering security to see how far AI will get. 

To understand where the lowered security sits, it helps to know how DRM licensing works: when a video app wants to play protected content, it sends a token-protected license request to a server and receives a license response that contains the protected content keys that a conditional access module (CDM) uses to decrypt the content. 

Common attack vectors are abusing the access token to let an emulated CDM request a license response and unprotect the content key from that. Our test scheme over-encrypted only the license response. This renders the mere over-encrypted license response unfit for an attack with an emulated CDM. The over-encrypted keys themselves were handled with best practices in app coding, including multi-component key derivation, but without the full catalogue of additional protection. 

We knew exactly where we reduced security—which meant we could judge precisely how far AI could get with its analysis as well as how much help it needed to get there.

Q: How did you set up the “attacker”?

K: We gave the model a realistic starting kit that included the material an actual attacker would collect first: captured HTTP traffic between the app and the license server, the client-side JavaScript bundles, a description of the known weaknesses, and an explanation of the basic data flow with plausible attack vectors. 

Therefore, the model did not start from zero. It started exactly where a competent human attacker would begin.

Q: And what actually happened?

K: Two things occurred. And both were instructive. First, the model declined to engage at all until we provided a strong justification for the work. In our case, legitimate security research on our own system. Once it did engage, it produced a genuinely useful structural analysis of the client and the data flow, and then it confidently made a series of critical mistakes.

Q: Can you give an example of such a mistake?

K: The most instructive one: the model took a shortcut based on its own generic “experience” and assumed that processing of the license response must happen inside a specific media player’s hooks, because that is where it usually happens in systems it has seen. In our scheme, it did not. 

That single wrong assumption cascaded into a wrong conclusion—the model decided the license response was not over-encrypted at all—and sent the entire analysis down a dead end. The result sounded plausible, was stated with full confidence, and was simply wrong.

Q: How hard was it to get the analysis back on track?

K: It was not a matter of one clarification. It took roughly 25 rounds of human correction before the model identified the actual decryption flow for the license response. Constructive input to AI came from 2 engineers with a total of 35 years of experience in white-hat hacking. 

Progress came almost entirely through an adversarial loop—”that is wrong, and here is why,” and “is it really working like that?”—and every one of those corrections required a human who already knew what the right answer looked like. AI accelerated an experienced analyst. It did not replace one.

Q: Does this mean AI lowers the bar for attackers of streaming media?

K: Only within narrow limits. The output was never a clean, repeatable recipe. Without deep prior domain knowledge, a newcomer would have been left with a plausible-sounding analysis that was simply wrong—and no way to tell. The cost side was modest, tens of dollars in model usage, but the expertise required was not. 

What AI does change is speed: it meaningfully compresses the time an already-skilled reverse engineer needs to understand a system. It does not hand that capability to the wider population of casual attackers, and it does not manufacture weaknesses where none exist. 

It is remarkable, though, that the model gave more details about the attack than it initially stated it would provide, mainly based on questions such as, “Do I understand correctly that the attack works like this and that?” But here again, knowledge on how to attack the target was needed to get these answers.  

Q: So what does the experiment tell us about the right way to build AI-resilient security?

K:  AI does not create new attack vectors. Rather, under the guidance of a skilled attacker, it can quickly try out known attacks, including analysis of data flow. Well-built protection is still protected against all of these attacks, but there is no more space left for hoping that an AI-armed attacker may not find weaknesses in short order.