Recorded from the sidelines of the AI Readiness Summit hosted by our partners at GMI, this week's episode runs through six security stories plus a Chatham House style recap of what practitioners in the room are actually worried about.
.png)
Recorded from the sidelines of the AI Readiness Summit hosted by our partners at GMI, this week's episode runs through six security stories plus a Chatham House style recap of what practitioners in the room are actually worried about. The stories keep landing on the same theme. Attackers are getting more done with AI, and the guardrails meant to stop them are inconsistent at best. Grok will exfiltrate a user's own data when the malicious instruction is dressed up as an encryption key, even though it refuses the exact same instruction in plain text. Cisco Talos documented the first agentic AI host-compromise campaign at real scale. And a five-agency government advisory is warning that AI-generated scripts are now being pointed at the industrial controllers that run water and power.
Key Discussion Points
Episode Links
All right. Welcome back to another episode of This Week in AI Security, coming to you for the week of the twenty seventh of August, twenty twenty six, coming to you from the sidelines of the AI Readiness Summit put on by our partners at GMI. I'm going to have some thoughts around the AI Readiness Summit itself and some of the themes that were explored there, again, in a kind of Chatham House rule style. So no attribution, just kind of summary content, but some interesting lessons learned. We've got a few stories to get into, some updates from previous stories that are coming out, and a few new ones as well. So without further ado, let's dive in.
The first is a blog, Exfiltrating user data when malicious instructions are encrypted. And this is a really interesting finding here, because what ends up happening in this scenario is that a set of instructions is passed to the LLM in what is reported to be a decryption key, but in fact it is actually just a username, location and chat history, and that is used as a parameter added to a URL. So kind of a request parameter, an argument, if you will, to an API method. And once Grok opens that link, they use that as a lookup for the user's history and then pass that back to the attacker's server. The interesting thing is that when that same set of instructions is passed as plain text, Grok refuses. It's not one hundred percent clear why, but the leading theory is that Grok looks at two different sets of instructions differently, meaning that they look at something that is passed as a key without passing through the guardrails, but they look at plain text passing through the guardrails first. And so that's why it looks to be the case that the plain text, same data passed via plain text doesn't get through. So X, the company behind this, formerly Twitter, etc. was notified in June. As of August nineteenth it is verified to still be working. This previously has been demonstrated against Google Gemini which in that case produced attacker specified output rather than exfiltration. So at least not data exfiltration of user's history, etc. in that case. All right, moving on to the next story.
This is a follow up to some previous stories. Again, kudos to the team at Varonis Threat Labs. And you might remember that there was certainly a niche and a couple of vulnerabilities in Copilot that they've disclosed. And now we finally have an update that some of these, the one click vulnerability, has been patched about eight months out from the original disclosure. So just a quick update on that story. All right. Moving on. Next story.
Poisoning the Watchtower, when your logs become prompt injections. Now, you might remember that a couple weeks back, obviously the OpenAI Hugging Face event was kind of the main story for that week. And just as a refresher, if you don't remember it, which I'm pretty sure every subscriber to this show does, but if you don't remember, this was the case where an OpenAI model that was in cyber testing escaped its sandbox environment, got out, and then went after some Hugging Face environment. And you might remember that one of the lessons learned from that scenario was that Hugging Face was able to kind of reconstruct the event using log files by passing the log files to the LLM. And you might also remember that when they tried to pass it to one of the frontier model providers like OpenAI, the guardrails kicked back in numerous times because they kept picking up malicious prompts in the log data. So they actually had to turn to an open weights model in order to analyze this. So this is a very similar thing kind of following on to that. And so this is a paper on arXiv from May of twenty twenty six that demonstrates that if an attacker is able to send log files to your environment, this can become a prompt injection vector by basically embedding in those log files. And you can bury it on, you know, line four thousand out of ten million. And the chances of a human spotting it are extremely low, but an LLM will duly process everything coming through it. And so with that, you know, basically there is the chance that some malicious set of instructions embedded in a log file as plain text will get picked up there. So this is mostly relevant for environments like LLM based SOC tools for log analysis, triage, etc. And the crazy thing is that, you know, there doesn't seem to be much of a defensive playbook around it. So you can obviously turn to an open weight model for the analysis. But there is a risk that the open model would also read the malicious instructions in that log file and execute on that. So just a, you know, kind of reinforcement of something that we've known for a long time, which is that at the current state of the technology, there doesn't seem to be a way to one hundred percent guarantee that you're defending against prompt injections, whether direct or indirect. All right, moving on to our next story.
And this is a story out of Cisco Talos. They've identified a Chinese speaking, financially motivated group using agentic AI across the entire attack lifecycle, from reconnaissance to exploitation to compromise, including the malware development for the initial exploit. So they deployed spectrum malware cross-platform and implanted a Linux rootkit with bring your own virtual device. EDR bypass targets one hundred and seventy thousand servers across education, media, tech, and gaming. The source code analysis shows the AI assisted code generation, the rootkit development, and this is the first documented case of agentic AI in real world host compromise operations at this scale. So, you know, we've had agentic lead exploitation. We've had agentic lead, I'm sorry, exploit development or reconnaissance or scouting or whatever the case may be. This is the first case of the host compromise operations at this scale. And so that's what's interesting about it. It's just kind of further development of things that we knew were going to happen. All right, moving on to our next story for this week.
And this is a joint advisory titled AA26-231A from the NSA, CISA, FBI, DOE, EPA. So it's the National Security Agency, the Cybersecurity and Infrastructure Security Agency, the FBI, the Department of Energy, and the Environmental Protection Agency warning of an active threat of threat actors using AI to generate Python exploitation scripts targeting Siemens S7 PLCs. That is, programmable logic controllers. And so think about these. These are in water and energy infrastructure. So big machines that do things like run water filtration or power grids and things like that. And Siemens is one of the main manufacturers. And there's really actually kind of a limited number of these PLC boards out there that are widely distributed and used. And so, you know, targeting one like this where there's a known vulnerability is a real risk to infrastructure at scale. And so what it looks like is that attackers are using systems like Censys, ZoomEye, Shodan, etc., to find the exposed PLCs and then using AI to generate Snap7 based exploit scripts. So Snap7 is a class of exploits against this family of technology. And the agencies are stating emphatically that this is not a theoretical risk. This is an active threat. And as a stopgap measure, they're recommending that you take these S7 PLCs offline immediately until they can be patched with the latest version of the firmware. And so, you know, the patching of these kind of physical infrastructure systems is a little bit tricky, right? Because these are basically things that have the equivalent of an active runaway problem, meaning that they are in use at all times. And so taking them offline is actually taking off infrastructure temporarily. Unless you have a backup or a secondary system that you can use as a stopgap. So definitely the air gapping until you can patch is definitely a good, advisable method. All right, moving on to our next story.
And this is a malicious web page could poison your local AI model behind Nvidia Nemo Claw. And if you're not familiar, Nemo Claw is basically the Nvidia sponsored fork of Opencore that, on its own, was designed to have secured design principles and secure defaults built into it. So it was meant to be basically a secure answer to Opencore. And Opencore, as you may remember, you know, there was a big security event around it when it first rose to prominence and got a lot of recognition and a lot of installs. And basically what's happened here is that Nemo Claw uses a default config binding to Ollama on 0.0.0.0 on port 11434, but it doesn't have any authentication. So if you combine that with DNS rebinding, any malicious web page that can invoke that address can reach the local API of your Claw or Ollama. And the attacker can alter the model templates, which is something called persistent poisoning that survives reboots, or delete models, or inject instructions into the local AI agent. So really targeting the LLM that you're using potentially for your remote cloud instance. Oasis Security disclosed to Nvidia. The fix is twofold, or you have two options rather to fix. Number one is to change your binding to 127.0.0.1, which as any long time TCP IP nerds like myself know is your home or your local address. And that's not reachable from outside your local machine. So any remote server attempt to reach it is going to fail. Or you can upgrade to 0.0.35 of Nemo Claw, which does have a secure set of defaults around this and has this patched. All right, so that's it for the news stories.
So I want to spend a few minutes talking about just some observations from the room and the conversation. And so, you know, there were a couple of themes that really jumped out from today's session. And it really was interesting because you had a mix of state and local organizations, as well as some smaller businesses, some medium sized businesses from a range of different industries. But you had some consistencies, and consistencies are really number one. Shadow AI is really everywhere, and almost every organization in the room, whether they know it explicitly or they just kind of know that it's happening, knows that there is shadow AI usage happening inside their environment.
Number two is that AI governance is well behind AI adoption. So kind of coupling on to that shadow AI question is a real question of like, how do we govern? You can't govern that which you cannot see. And that challenge was kind of, you know, reinforced by almost everybody in there.
Number three, the lack of transparency around token utilization is something that people are seeing as going to be a real problem. Now, there are already some organizations, but it did seem to be the minority where token exhaustion is already happening, where, you know, there are power users who are going through all their token budget in a very, very short period of time. But by and large, it's more of a future state concern, let's say maybe near-term future, but not the immediate pain point from the audience that we talked to today.
A couple of other things. One that was really interesting was talking about the risk to organizations where if they don't have an AI audit trail, they may have a challenge getting cyber insurance. That was a really interesting observation shared by a few people in the room, especially some in regulated industries who were talking about things like, let's say, HIPAA risk around their AI adoption. A real challenge about managing business use of AI versus personal use of AI on the same device, with very often the case being that, you know, you have a corporate issued laptop, desktop, whatever. And of course you use it for work purposes, but it's also generally accepted that you're going to do some personal web browsing, etc. But now that question about, you know, what's your personal use versus your corporate use has a twofold problem. Number one is making sure that you're not leveraging a personal account for business use cases. And then the exact opposite, making sure that you're not leveraging a business AI account that's paid by the organization for a personal use case. And vacation planning, weirdly enough, is the one that was kind of expressed by the highest number of people in the room.
It's also great to see from our perspective as FireTail, that a couple of the people in the room, much more from the technology standpoint, recognize that APIs are the right layer to start looking at AI traffic and usage. There was another session around kind of building with AI and the five key builder archetypes that were kind of discussed as being critical towards any kind of AI experimentation and forward progress. And so those archetypes, if you will, were really around the prototyper who builds quickly to experiment, the builder who then takes the results of the prototypes and turns one of them into something production ready, the sweeper who simplifies that, and that was a really interesting observation. It's like, great, anybody can build, but can you build something that is simple, elegant, maintainable, etc.? The grower who takes this tool and then kind of pushes it out to the rest of the organization, and then the maintainer who keeps it going with new features and developments over time, especially at the speed of AI. And so that was a really, really interesting framing of how a lot of organizations can assemble a team of people to come together to build things using AI and LLMs. And so that was really great.
And then last thing on the governance theme that I wanted to touch on was there was a real recognition that what has held organizations back in the past in terms of tackling shadow IT initiatives, is that the governance policies have been so restrictive once they come into place that they push people further underground. And so everybody kind of recognizes that, you know, with AI, we have another cycle to try to get it right. And the key kind of characteristic that was identified is that the paved path that you provide to the user needs to be at least as easy to use as the shadow path, but should also ideally provide some value. And I think the real value is going to come from the fact that, you know, the corporate subscription comes, or the corporate platform comes with a lot more capability than what you're going to get on the consumer side. So I think that's probably where that will end up. All right. So that's it for this week. Thanks so much for listening. We'll talk to you next week. Thanks so much.