In August 2025, independent security researcher Johann Rehberger published a new LLM or agentic AI exploit every single day. Rehberger, who goes by wunderwuzzi online, covered multiple avenues for prompt injection, sandbox escapes, data exfiltration, and more.
Rehberger’s bugs spanned numerous tools and platforms, amounting to a bolded, all-caps reminder that LLMs and autonomous agents are not secure by design. In the time since, he hasn’t slowed down, continuing to find and publicize new methods of getting AI systems to break bad on his blog Embrace the Red.
Rehberger got his start at Microsoft, first as a developer and then moving to security engineering, where he started a red team in Azure Data. He has additionally built and led red teaming groups at Uber and Electronic Arts. Rehberger is now an independent researcher who says he truly enjoys finding bugs — something the rise of AI has provided ample opportunities for.
In this condensed Q&A, Rehberger shares what he found during his month of bugs, the patterns he’s noticing, and why he thinks AI is the “security debt collector.”
It went back multiple years actually, when I realized that there is this fundamental weakness, which I now call automatic tool invocation, where an AI can be tricked by third party data to invoke a tool that it otherwise might not call. If vendors add a new plugin or capability, it makes this problem worse because you can create videos with AI, you can upload data, you can send emails and so on. And all these are just tool calls. So third party data could potentially invoke it.
When coding agents came out early last year, tool integration and the agentic loop just started exploding. And that's when I realized I wanted to publish a vulnerability report every day of the month to demonstrate how insecure these agents are. We give them way too much control, automatic control, where it might just be able to steal your passwords, send the password off to a different machine, there’s nothing there that is actually blocking it. There are often no, or easily bypassable, security controls that prevent external communication to a third party server that would receive credentials, for instance.
The project was also aimed at raising awareness of the lack of actual security downstream. Prompt injection doesn't appear to be something we can fundamentally solve by making models more robust alone. We need to assume models can be manipulated and enforce security boundaries independently of model behavior. It's like social engineering in a way. But what can be solved is limiting what an agent can do, having them monitored, observing them when something happens, and so on. So that downstream part is where a lot of investments need to happen.
I do. Every single time you find a security vulnerability and especially when it takes you a long time to figure it out, it's really exciting. It feels good.
I first always try to understand what the product is, and its actual use case. And then I try to figure out if you can misuse the features that an application normally has in unexpected ways.
This is interesting about cyber operational red teaming. It’s often just exploiting what everybody can do with the application. It’s not necessarily just about finding a zero day, because often all you need to do is find the password or authentication cookie of the person that is able to do something as part of their job, and then an adversary can just do the same thing.
Regular well-known security problems are common, sometimes with a bit of an LLM twist to it. Over the last few years I showcased some AI-specific vulnerabilities, like data exfiltration by having an agent render markdown syntax that turns into an HTTP request, or compromising agentic memory, exploiting agents with invisible Unicode characters or highlight how an agentic virus would propagate via Github repos. Those are attack patterns that are interesting to explore as a researcher.
When it comes to security hygiene, not using multifactor authentication is way too common still. And companies might have a directory system and service accounts that are exposed or usable from the internet. So if an attacker guesses the password of a service account (because automation accounts often don't use interactive MFA) they have a foot in the door. I think this is where companies have to continue to lock down environments. You need to have an inventory of accounts and what those accounts can do and make sure you have strong authentication and keep logs around. And that expands to agents as well.
For situations where you need to have a password, like with legacy systems, make sure that you have other controls. Even as simple as allowing traffic only to come from the IP address it should be coming from. Very practical stuff like this can help a lot. Generally, don’t expose stuff on the internet if there is no good reason for it. And for your production system you really need to have egress controls and only allow expected well-known binaries to execute.
So, it's important for a company to step back and look at the big picture because a lot of the nation states, or even just scammers have been successfully using the same playbook for a long time. And with the help of AI, the scale and velocity of attacks will increase.
I don’t necessarily know if there are going to be new threats, but I do know things will happen faster. Even two years ago I said that with the advent of the agentic hacker, the scale, the velocity, and the complexity, maybe even the sophistication of threats will just be higher. The time from discovery to exploitation to lateral movement will be much faster. And that’s already happening.
Even now we have automation that compromises computers quickly. But at the moment the automation cannot auto-adjust. That is the big difference with AI — it can adjust on the fly. And that's just going to happen. It's natural that adversaries eventually will move into that space. Maybe less sophisticated adversaries first, because I think the sophisticated adversaries don't necessarily need AI right away for attacks.
I often say that AI is the security debt collector. It's now going to come knock on everybody's door and it’s going to show your dirty laundry to everyone.
The biggest takeaway for me happened later. There's this concept called the normalization of deviance, which was coined after the Challenger space shuttle disaster. It’s very much an organizational problem where people got used to errors: seeing a small error rate, and that new error rate becomes the norm, and then it shifts more and more and so you would see more and more errors. As you normalize the deviance, the error becomes normalized.
I had this realization that something similar is happening in AI where we know we cannot trust it — everybody will tell you, every researcher will tell you the output of an LLM is not trustworthy. Every single chatbot tells you on the bottom to check for mistakes, right?
But we’re using it day to day. You kind of get to know it, so you trust it more and more. And once in a while, you're like, "Whoa, why did it make this big mistake?" And this is what I call the normalization of deviance in AI, where we start trusting it more and more, and then maybe not applying actual security controls and relying on the model being aligned and doing the right thing.
And that could mean at one point, something goes really, really bad if we’re not always keeping security protocols in place.
This Q&A is condensed and lightly edited from an interview with Johann Rehberger. Rehberger’s views are his own and do not represent the position of SecureW2.
SecureW2 is a leader in modern cloud PKI and certificate-based agentic AI security. Through its Signal blog, SecureW2 works with real human technology journalists to interview a range of top industry subject matter experts and thought leaders.
