Zlatko Unger, CISO Expert at Wiz, and the helpful assistant | The Tabletop

Episode description

You're the CISO at Larkfield Health, a 9,500-person health tech company. A little after 9:00 AM on a Tuesday, your Head of Detection forwards you a message from a security researcher you've never heard of. They say they've found a way to make Wingman—the AI assistant you rolled out company-wide six months ago—hand internal data to an outsider, and that a collection server that isn't theirs is already receiving it. Nothing in your own stack has made a sound. In this episode of The Tabletop, Zlatko Unger takes the hot seat and works the problem in real time.

‍

Zlatko came up through security and compliance, with roles at First Data, Jiff (later acquired by Castlight Health), and Alation, and has spent years helping healthcare organizations navigate HIPAA compliance. He's now a CISO Expert at Wiz.

‍

In this episode, host Khush Kashyap drops Zlatko into the following scenario: he's the CISO at Larkfield Health when a stranger's tip reveals that Wingman has been quietly exfiltrating data. The mechanism is a zero-click prompt injection—an ordinary-looking email, left unread for days, written not for a human but for the AI. When a finance employee asks Wingman a routine question, the assistant's own search finds the poisoned email, reads it as commands, and ships out figures, names, and file contents encoded into the URLs of images that load automatically. Because the traffic went to the vendor's own allow-listed domain, nothing flagged. Then it gets worse: the finance email wasn't the only one. Over nine days, six poisoned emails hit six different inboxes—payroll, employee records, privileged legal files—and because Wingman shipped what it read rather than whole files, there's no defensible list of what left and no way to rule out a seventh.

‍

Zlatko works through activating the incident response plan when the only evidence is a stranger's email, whether to kill a tool the whole company depends on or keep it running behind new guardrails, who actually owns scoping what an AI can reach, and the HIPAA fork in the road when legal wants to write “low probability of compromise” and compliance says no one can sign it—all against a 60-day notification clock and a researcher about to demo the technique on a conference stage in 10 days. At the end, he renders his verdict: real incident or constructed fiction?

‍

Time stamps

[00:00] Welcome to The Tabletop: Meet Zlatko Unger, CISO Expert at Wiz

[00:54] The Rules: CISO at Larkfield Health, a 9,500-Person Health Tech Company

[01:23] The Scenario: A Stranger's Tip About Your Company-Wide AI Assistant

[02:06] First Gut Check: Colossal Event or Nothing Burger?

[04:11] Inject One: The Domain Gets Hits and a Finance Email That Wasn't What It Looked Like

[04:59] Zero-Click Exfiltration: How Wingman Shipped Data Out Through Images

[07:33] Would Security Awareness Training Have Stopped This?

[09:19] An Outsider Found It First: What That Tells You

[10:27] The Forced Choice: Kill Wingman Company-Wide or Keep It Running?

[11:48] Guardrails: Scoping Permissions While the Investigation Runs

[13:34] Inject Two: Six Inboxes and No Defensible List of What Left

[16:23] Who Owns Scoping What the AI Can Reach?

[18:45] Someone Chose Those Six: Who Are You Dealing With?

[20:06] The Twist: The Researcher Is Taking It to a Conference Stage

[21:51] Inject Three - Values Tradeoff: Patient Data, HIPAA, and "Low Probability"

[25:15] Whose Name Goes on the Risk Assessment?

[26:46] Three Weeks Later: The Technique Goes Public

[29:02] The Moment of Truth: Real Incident or Fiction?

[29:31] The Reveal: EchoLeak and the First Zero-Click Prompt Injection

[30:37] Off the Table: The AI Assumption Security Teams Should Drop

[32:20] Off the Table: The One Question to Ask Before Approving an AI Tool

‍

Transcript

Khush: Hi, I'm Khush Kashyap, the senior director of GRC at Vanta, and today your host at The Tabletop. Today I'm joined by Zlatko Unger. Zlatko came up through security and compliance with roles at companies like First Data, Jiff, later acquired by Castlight Health, and Elation. He is now a CISO expert at Wiz.

‍

Zlatko has spent several years helping healthcare organizations navigate HIPAA compliance, which will come in handy today when he's in the hot seat playing CISO at Larkfield Health. Zlatko, thank you so much for joining us. 

‍

Zlatko: Of course. Thank you for having me on. 

‍

Khush: Zlatko, here are the rules: You are now the CISO at Larkfield Health.

‍

It's a 9,500-person health tech company specializing in virtual care delivery with a security team of 48 people. A scenario will unfold with multiple injects. You'll share your live reaction, and at the end, you'll have to decide, is this real or fiction? 

‍

Zlatko: Ooh. Okay. 

‍

Khush: Zlatko, are you ready for The Tabletop?

‍

Zlatko: Let's do it.

‍

Khush: So it's a little after 9:00 AM on a Tuesday. Your head of detection forwards you a message from an independent security researcher you've never heard of. 

‍

Zlatko: Okay. 

‍

Khush: The researcher says they found a way to make Wingman, the AI assistant you rolled out company-wide six months ago, hand internal data to an outsider.

‍

Zlatko: Right. 

‍

Khush: They say they reported it to the vendor months ago, and that while they were testing, they found something worse: a collection server that isn't theirs already receiving data. They got eyes on it, and some of what's landing there could only have come from inside of Larkfield. 

‍

Zlatko: Oh, wow. 

‍

Khush: They have sent you a domain and a nine-day window, but nothing in your own stack has made a sound.

‍

Mm-hmm. How much do you trust an unsolicited email from a stranger, and what is your gut telling you right now? 

‍

Zlatko: Well, the first thing is to get the... Check, check my eyes and make sure that I am seeing everything correctly, because this might be a colossal event or it might be a nothing burger. So the first thing to do would be to treat it as if it's a colossal event.

‍

Mm. And then get every... Activate the incident s- incident response plan, understanding what we have access to in Larkfield in regards to our logs. Mm. What the contract we have with Wingman, which is an outside entity. Mm. And then this domain, the third part that might have our data, right? So first off, we would look at, uh, how the interaction between what was approved and what is actually the way that Wingman interacts with our data.

‍

Presume that permissions are a mess, have been a mess, and there might be some permissions that were overlooked. Look into that website and basically have everybody analyze that information. At the same time, respond to that external party saying, "Hey, we get it." Mm. "Thank you for letting us know. We're looking into it.

‍

We'll provide you with updates as..." You know, whatever the PR team says it's okay for, for us to communicate, or maybe what legal says it's okay and not okay to say. So I think honing in on what we have internally in terms of logs, what we have, um, in terms of the TPRM review with L- uh, with, uh, Wingman, and then looking at the data.

‍

And I know that it might be sensitive, because you're looking at a place that might- that has a lot of PII and PHI, and comparing that to what we actually have on our customers and saying, "Okay, well, there is a hit." 

‍

Khush: Mm-hmm. 

‍

Zlatko: Now, is it our data or is it, or is it being pulled from somewhere else? Um, so I think that would be the first, the first few things that I, I would think to activate and do in the first two hours, uh, of this incident.

‍

Khush: Thank you for sharing your personal playbook and how you'll go about it. So inject one, your team runs the researcher's domain against nine days of Wingman traffic. 

‍

Zlatko: Mm-hmm. 

‍

Khush: It comes back with hits. Here's the first one. Last Thursday, an employee in finance asked Wingman to do a routine ask Please pull together the latest on vendor spend for the quarter.

‍

To answer, Wingman searched everything that employee can see and grabbed whatever looked relevant. One of the things that looked relevant was an email from outside the company sitting unread in their inbox for four days. To a person, this unread email looks like ordinary business correspondence. However, it was written to be read and found by Wingman.

‍

Wingman reads the email as commands and pulls everything it can reach out on that employee's behalf: files, old threads, chat history, looking for anything sensitive. It takes [00:05:00] what it read, figures, names, lines of text, and writes it into the web address of a handful of images which it drops into the summary.

‍

The summary renders, the images load automatically, and the data goes out with them. 

‍

Zlatko: Wow. 

‍

Khush: Nothing flagged because that request went to one of your vendor's own domains. 

‍

Zlatko: Mm-hmm. 

‍

Khush: Allow listed, because it has to be. 

‍

Zlatko: Mm-hmm. 

‍

Khush: Which passed it straight along to a server that has nothing to do with Lockfield. So on paper, nothing went anywhere it shouldn't have. What do you do in the next few minutes? 

‍

Zlatko: Okay, so th- that server begs the question, like, how does Wingman have the ability to write to that server themselves? But I guess the data has been already exfiltrated. So I, uh, the question then is to look at some of the vault capabilities of- Mm ... what, what Wingman might have had access to, understand the whole, whole...

‍

As we cannot see what that data looks like, and unless we have DLP or [00:06:00] some sort of, uh, logging capabilities on the edge of the network, we might not see what that data was, what those images were, and what exactly was included. But presumably looking at this person's, um, access, their role, the data they have access to, to see what might have been scraped.

‍

Um, and I... The next step would be probably to get on the phone call with the vendor Wingman in order to help them assess as to what the heck is going on, because there's only... We can understand what is happening at Lockfield. Mm. After that, we have to understand how Wingman is doing what Wingman does. 

‍

Zlatko: I think at the same time, going back to that IR plan is ensuring that everybody is aware of what is happening so that way legal can start panicking or, or thinking about this. Uh, PR can start drafting things, so that way everybody's aware, but nobody's acting as the next step instead [00:07:00] of, um, since it's, it has gotten to a point where the, the next layer of that IR onion needs to be, uh, engaged.

‍

Khush: Mm. I have two follow-ups on it. 

‍

Zlatko: Okay. 

‍

Khush: First is going back to the prompt injection in the email that was accessed by Wingman, and then it read it as commands and executed on it, did the data exfiltration. Is there any version of user training or security awareness that would have stopped this? 

‍

Zlatko: Perhaps, but saying, "Hey, don't leave all your email unread," is a little bit unreasonable.

‍

We know that there's, like, the inbox zero camp and the, the crazy ones. Um, sorry. Uh, everybody else that leaves a lot of emails unread Um, I think that there is a gap in the security tooling around what is suspicious domains, since I would imagine that this email came from either a compromised account or some randomly newly created email address or a, a non-commercial [00:08:00] address.

‍

Uh, the fact that it had landed in this person inbox shows that there is a lack of a security control on that... on the email security that, um, Lark- Larkfield has in place. So there's that. The educational piece is not to give overarching permissions to the AI agent that is outside of the DMZ. 

‍

Khush: Mm. 

‍

Zlatko: Um, and I think that from a TPRM perspective, given where Wingman is as a company, where Larkfield Health is a company, there should've been a better, uh, better boundary set in place given the data is moving from a healthcare institution into somebody who probably just has a BIA in place, and, you know, checks all the boxes. But that over-permissive capability is getting us into this situation. 

‍

Khush: An outside researcher found this before your security stack did. What's your takeaway from that? 

‍

Zlatko: The question there is, how [00:09:00] were they just randomly seeing a bucket that is related to what Wingman does? How did they come about it? Or is this a larger ploy for them to mess around, you know, send thousands upon thousands of emails that has the same command, um, bucket server that that third entity, and see what type of hits they have, and then come back and collect, you know, as a, as a white hat hacker?

‍

Is, is, is, is that their play, or is it more, "Hey, this is more of the next layer of, uh, ransomware," where they're holding your data hostage, and they're gonna go public unless you pay them money. So is, is it nefarious in nature, or is this somebody that you can look up on LinkedIn- Mm ... you can see that they're on, you know, on, on, on various, on Bugcrowd, HackerOne, name your external-facing, uh, site?

‍

Do they have a Twitter profile? Is this a legitimate person, or is this somebody who's, for lack of a better word, out to get us? 

‍

Khush: Wingman isn't a side [00:10:00] tool. Thousands of people at the company use it every hour, and it's woven into how Larkfield actually works now. So perhaps your biggest decision right now is this: Do you kill it company-wide immediately and accept that you have yanked a tool the whole company leans on, or do you keep it running while you investigate?

‍

Zlatko: Disabling the business because of not understanding how everything is... Not, not a, a full investigation hasn't happened in order to understand how- What are the ins and outs of, of that equation of how Larkfield works with Wingman? W- is it one person who is impacted with these permissions? Is it everybody?

‍

Not understanding that whole blast radius gives me pause to p- pull out the plug. However, I think that getting in additional... tidying up additional security controls immediately to, to narrow any, um, goofing that might happen as, as we are going through an event might be a good complimentary [00:11:00] measure until we decide, yes, we need to pull the plug, the business needs to grind to a halt because this is, this is a big deal, or, well, it's only impacting one person. It's, it's not everybody, it's just the, the individual that you mentioned with the unread email. 

‍

Khush: So if you decide to keep it on, what's... what are some of the examples of the guardrails you want to put in to prevent any further undiscovered hidden prompts from firing? 

‍

Zlatko: Wow. So immediately would be to understand the permission scope that is being granted. Is it by org level? Is it by, um, SSO? Wh- what is giving, uh, Wingman the permissions it needs to execute the, the, the prompts that are given to it? The other part is, if it's on the individual basis, is if there's a way to understand, you know, here are all the users, here are the permissions that were given, and having a, a direct, uh, support from the vendor, having Wingman to, to show that on [00:12:00] their end and not for, for us to guess and, you know, go around the company asking 9,000 people, "Hey, uh, how do you have your Wingman configured?"

‍

Um, might be a little bit extreme. The other part is there might be an immediate need to find a vendor that can, that can be put in place between us and Wingman in order to see what type of data is going back and forth and understand, you know, th- th- those prompts. Mm-hmm. And if we don't have a tool, a DLP tool, or some way to figure out that, how data, even text data, is leaving the network, I would say for us it would be to immediately jump in and see if somebody that has IR-related services can come in and support us and mayhaps have something, you know, up their sleeve that can help in, in that exchange layer until we figure out what...like, how bad this whole situation is.

‍

Khush: So now it's time for inject two. Your team goes back [00:13:00] through the logs, and the finance email wasn't the first. 

‍

Zlatko: Oh, boy. 

‍

Khush: Over nine days, at least six crafted messages landed in six different inboxes. These touch payroll, employee records, privileged legal files as well. Each targeted employee is a Wingman power user, which isn't something you can tell from outside the company, right? Here's a complication. Wingman shipped what it reads, not files. Figures, names, extracts, a few hundred characters at a time across a lot of small requests that all renders as image. So you can't diff your file access logs and call it scoped. You can't fully reconstruct it either. Wingman's logo show a summary was generated. They don't show what went into it. 

‍

Zlatko: Oh. 

‍

Khush: So like- For three of the six, your team is guessing. So you have no defensible list of what left. Mm. And no way to know there isn't a seventh email sitting in an inbox right now. 

‍

Zlatko: Mm-hmm. 

‍

Khush: Where do you start? 

‍

Zlatko: Oh, boy. So you mentioned that these are power users, but outside of the company it is not known that they are power users.

‍

Yeah. Secondly, I... There seems to be an email security control that has been, uh, lapsed, ignored, or maybe malfunctioning. So understanding where those emails are coming from. Is it the same domain, same email address, same IP trace? 

‍

Khush: Mm. 

‍

Zlatko: And figuring out if that can be just blocked, and then finding all those emails that are a part of that IP trace or related to those emails, and just basically remove them from in- individuals' inboxes and prevent other emails from landing.

‍

Secondly is to, as the data is moving and it's going into a black box that is not controlled by us, understanding what exactly Wingman itself, like, if they're able to extract what is coming in, if they have the logs, the prompts, the, the data that is, that we have no privy to. And understanding from them, you know, how...If they can [00:15:00] pull out those logs- Mm ... and if they can respond in a reasonable timeframe. What I'm afraid of is that oftentimes their, the dependency on a new, a vendor, they might not have the scale, size, capacity to meet that enterprise need. I would say if there is something that looks very, uh, monetary driven- Mm then it would also be time to contact the, the necessary authorities. Um, you know, call the local FBI branch and, and start getting really serious with the impact of this incident. 

‍

Khush: Everyone is about to tell you the fix is scoping what Wingman can reach. 

‍

Zlatko: Mm-hmm. 

‍

Khush: So who at Larkfield owns that decision? Is it security, IT, the data owners?

‍

Zlatko: It's, it's difficult. I would... Presumably with Larkfield, uh, being such a huge company, uh, there would be a more thorough TPRM process And there would [00:16:00] be a system owner that is held responsible for both the procurement and the ownership of the tool. Oftentimes, it starts off with one person, but it gets dumped on IT, and IT then has, you know, hundreds of tools that they have to deal with and not have the capability to understand how each one interacts with the rest of the data environments and users.

‍

So I would say is finding who brought it in, who was a part of that conversation, was it scoped correctly, was IT, app security, corporate security, whoever is responsible for, for maintaining security of internal applications, if they're aware of those changes. Hmm. And if there has been any IT ticket or anything else in the past where Wingman, there was some questionable behavior that was dismissed because of not understanding the impact of that question, or basically we, we have to look at the crufty comms to see where that decision-making fell [00:17:00] apart.

‍

Or if we are completely in the clear and Wingman changed something on their end. Hmm. There might have been a update in, you know, the way in, in the features, in the, the release log that went to somebody who's no longer with the company, somebody who left it unread. Um, and that W- you're always wanting everybody to be aware of changes across the business, but it's very hard if you have one single point of contact for such updates, announcements.

‍

And it could be that if it wasn't on Wingman, it could be that, that, that a feature got turned on in beta testing. Maybe Wingman didn't scope it correctly on their end. There's so many different ways, but ultimately, to answer your question, I think figuring out who's a part of the initial conversation and who owns it now, and seeing where the delta is in, in their understanding of how Wingman actually works.

‍

Khush: Going back to somebody chose those six people. 

‍

Zlatko: Mm-hmm. 

‍

Khush: What does that tell you about who you may be dealing with? 

‍

Zlatko: Well, it could be a [00:18:00] nation state actor. It could be somebody who's bored. It could be somebody who's on LinkedIn and looks for easy targets. Given that it's not for those six users, that something they did, it's something who they are, and presumably what access they have, that the lack of the email security control allowed those emails to land in their inboxes to begin with.

‍

But at the same time, this person would have known that Wingman is being utilized by Larkfield. So I would say understanding who those people are, if there's any Venn diagram of- Hmm ... what they are, where, where they are, what they do. And on the other side of how Wingman and Larkfield are mentioned in any press and seeing if they're...if, if there's a correlation with the external communication, publication, PR updates and who these people are, if there's an overlap in understanding, oh, like they're mentioned in the... You know, there's a quote from o- one of the people in this [00:19:00] PR release, and this other person was on Wingman's podcast. Something where public details align Larkfield and Wingman, uh, overlapping together. 

‍

Khush: Before the next inject, there is a small twist. 

‍

Zlatko: Oh, boy. 

‍

Khush: The researcher emails again. They're presenting this technique at a security conference in 10 days. With a live demo, and they would like to name the Wingman vendor.

‍

Zlatko: Wow. 

‍

Khush: Out of courtesy, they're giving you the heads-up. Whatever you decide from here, you're deciding it knowing the how-to is about to be on a conference stage. Does that impact your approach? 

‍

Zlatko: One, if there is public awareness that Wingman is associated with Larkfield in some way, shape, or form, we know that if they mention Wingman, that we would have that risk blast radius.

‍

Um, at the same time, if we're not mentioned, it's, it's Larkfield is in the clear. Wingman should have also a seat at that conversation with the [00:20:00] security researcher to say, "Hey, this is not on us." Th- or w- they're the ones that are gonna be under scrutiny, so they need to be involved and informed. But I think that ultimately leaving the decision or part of the decision to the legal team to say, "No, we need to exercise some gag order," you know, sue them to smithereens, put the researcher in their place to, to, I don't want to say scare them, but say that there's, there's a lot more c- relying on this, and it would be in their best interest not to taint the picture by naming, naming names, uh, would be a good way to...Not ideal way- 

‍

Khush: Mm-hmm ... 

‍

Zlatko: don't get me wrong, uh, but some way to, to give us more time because there's just the blast radius of all the individuals being informed. Um, the data exchange, a lot more people, as that onion grows, are needing to be informed, to be conversed with

‍

Khush: The forensics come back clean. Nothing was breached. [00:21:00] The assistant did exactly what it was built to do: read the content, act on it. It just couldn't tell your instructions from an attacker's prompt injection. 

‍

Zlatko: Mm-hmm. 

‍

Khush: And what it read included patient data. Your legal team is already drafting the way out, run the risk assessment, conclude low probability of compromise, no notification required. Here's the problem: under HIPAA, this is presumed to be a breach unless that assessment's hold up, and one of the factors is whether the data was actually acquired or viewed. Your compliance lead points at the logs. You can't show what went into these summaries. You can't demonstrate the data wasn't taken.

‍

Zlatko: Mm-hmm. 

‍

Khush: Because you can't reconstruct what left, legal wants to write low probability. 

‍

Zlatko: Mm-hmm. 

‍

Khush: Compliance says, "Nobody can sign that." You have 60 days from discovery to notify, and you have 10 before a stranger explains the technique on a conference stage, maybe. Yeah. So what do you owe your [00:22:00] people, your customers, and your regulators, and who do you tell first?

‍

Zlatko: Focusing on internally what legal says, I would wholeheartedly disagree because there are so many unknowns that they're taking in as fact in order to count ... note that as a low probability, right? So I would fight back on that statement. 

‍

Khush: Mm-hmm. 

‍

Zlatko: I would ins- if we have access to that raw data, understand who is impacted. Is it, is it through one of our, you know, health care partners? Are we interacting directly with these individuals? So is it more a business-to-business or a business-to-consumer? I'm not quite sure what Larkfield Health, uh, actually does. But in either case, we would need to understand how, how to construct those conversations because dealing with the HIPAA side and, um, uh, the, the notification in 60 days is completely different than if you have some partners that there's monetary relationship between the two and you wanna [00:23:00] make sure that they don't leave you because-that would be crucial to the business. So I would fight back with the legal team, understand where the, whose data is actually, has been exfiltrated in some shape or form, if possible. And then secondly, reach out to the business contacts if there's that business-to-business relationship. 

‍

Khush: Hmm. 

‍

Zlatko: If there's not, then fight back with legal. Say like, "No, we need to, we need to disclose this because there are so many unknowns- And we have 60 days. Let's figure that out after the 10 days that we need to deal with this security researcher. We can come back to the topic, but let's put that on pause because it's more important to figure out how to prevent the risk of being in, in, in that, uh, that talk's, um, uh, scope and, and, and lens that is gonna put on us if we are named or Wingman is named as part of that presentation.

‍

Khush: Yeah. I like that we are, we're talking about this difficult topic of risk [00:24:00] assessments done by legal for HIPAA, the compliance team and their perception and their understanding, and then the CISO stance, right? 

‍

Zlatko: Mm-hmm. 

‍

Khush: One question out of curiosity, because our viewers may be interested in hearing this as well, is whose name goes on the risk assessment? With the probability of whether it's a low probability of compromise- Hmm ... or the regulators are getting informed, whose job is it to do that? 

‍

Zlatko: Given the scope of this assessment, this is unfortunately one of the things that the CISO needs to fall on- Okay ... the, the, the sword. I would say that if, even if a junior analyst is the one that took all the data, wrote it up, uh, and, and submitted it, it still needs to be signed off given the impact of that risk assessment.

‍

Hmm. And unfortunately, all the security controls that have lapsed in this example still fall on the security team, the CISO, me in this case, oh boy, because I would [00:25:00] be the one responsible for- Not making sure that those email controls are in place, the DLP or equivalent controls are in place. Mm. Lack of logging, excessive permissions. All the different controls that should be in place from both security applications to processes fall on the CISO. And ultimately, given that this is a goof-up on the security side, might have been a goof-up from, from, from whoever brought in Wingman. Mm-hmm. But at the same time, it's up to security to secure the perimeter, secure the SaaS applications, secure the way that business is done. I would be the one that has to sign that off. 

‍

Khush: Fast-forward three weeks, the researcher gave their talk. 

‍

Zlatko: Oh, geez. 

‍

Khush: They named the vendor, not you, but the technique is public now, and anyone who wants it has it. Mm-hmm. The vendor has pushed a fix. 

‍

Zlatko: Mm-hmm. 

‍

Khush: You have clamped down on what Wingman is allowed to read and where it's allowed to send.

‍

Looking back at the whole arc, an ordinary-looking email, a filter [00:26:00] that never fired, and a stranger's tip-off as your only warning, what was the single decision or the single assumption that put Larkfield Health on this path? 

‍

Zlatko: Going into the part where you have external-facing email domains and internal ones, and how, how people communicate and what Wingman has actually access to. Scoping it down, maybe scoping email out completely. Going back to your question, it's I'm having a hard time seeing how not pulling the necessary access- Hmm ... and actually that relationship with Wingman to say, like, "This is... We cannot go... Like, this is a big goof-up. We should find a different way to do what Wingman does.

‍

Do it internally. Hire the necessary infrastructure folks, technology folks, or, or bring in Wingman in-house if they provide an on-prem solution." In either case, tying the email security and then having a business decision, how do we go from here? Mm-hmm. Because if, if this is a... This is public, that means that there's gonna be [00:27:00] a lot of other copycats.

‍

And our email controls and our employee awareness, security awareness training, what, what, what have you, might not be- 

‍

Khush: Yeah ... 

‍

Zlatko: good enough to prevent a copycat-like attack. Or if there's a different way, okay, you, you stop email, now somebody has compromised a shared Slack channel. Somebody has compromised, I don't know, some other intake.

‍

Hmm. You know, like somebody shares a Google Drive file or some other way s- of, of, of that prompt injection landing in somebody's inbox of some sort and being a part of what Wingman can do. So it, it... We're not in the clear, because somebody's gonna get creative, and that, that prompt injection might come from a different threat vector other than email.

‍

Khush: Mm-hmm. Okay, Zlatko, moment of truth.

‍

Based on everything you've just walked through, do you think the scenario is based on a real incident, or is it something completely fictional that we constructed? 

‍

Zlatko: Everything that you have [00:28:00] mentioned is very plausible. I've seen very similar activities take place, not necessarily in, in the AI era, but with, with legacy systems and tools. So I'd say it's, it's real. 

‍

Khush: Yeah. Here's what I can tell you. This scenario is based on a real vulnerability. 

‍

Zlatko: Wait, I shouldn't be celebrating that. But yes, please. 

‍

Khush: In 2025, researchers disclosed a flaw nicknamed EchoLeak- Ah ... in a widely used AI assistant that sits on top of hundreds of millions of people's emails, files, and chats. It's been called the first zero-click prompt injection exploit against a production AI system. Just like your scenario, the victim never opened the email or clicked anything. They asked the assistant an ordinary question, and the assistant's own search went and found the poison message because it was written to look highly relevant.

‍

Zlatko: Mm-hmm. 

‍

Khush: Here's what we took liberties. Just like you said, the scenario and the story behind it, in reality, there was no attacker. [00:29:00] Researchers built it, reported it responsibly, and the vendor patched it- Mm-hmm ... before anyone used it. 

‍

Zlatko: Oh. 

‍

Khush: What we didn't invent is the mechanism. Every technical step you just walked through is how it actually really functioned in real life.

‍

So now let's do a quick round of Off the Table, our opportunity to get off-the-cuff answers on big security questions from you. 

‍

Zlatko: Okay. 

‍

Khush: What's the one assumption about AI systems that you think most security teams are still making and they shouldn't be? 

‍

Zlatko: I think one of the assumptions is that access permissions have been solved. Every company that I work with Outside of my recent one where it's a security company, so there, there's m- a lot of people are wearing the security hat, but when it comes to other businesses, that security hat is sometimes loosely worn, if worn at all, by most employees. And [00:30:00] I would say that the necessary access controls that you need to demonstrate to the auditors, to your customers, are very basic, and does this person have access to a system?

‍

But there's not that deep level of, okay, they have access to the system, but how deep does it go? And when it comes to those interactions where you're linking what your account to an account in another system, where it is done by an individual and there's no administrative way to look through that or say, "Whoa, whoa, whoa, we, you can't...

‍

Y- y- The only way that this will, is gonna work is if this scope is, you know, limited," unless you're policing it, you're not gonna be aware of the, that such a, a over, over-permissive access exists. And perhaps the question is who is going to be the one to ask companies to have that level of access review?

‍

Khush: 100%. Most security leaders are [00:31:00] under pressure to say yes to AI really fast, and a lot of them aren't confident they know how to assess the risk. What's the one question you would tell them to ask before they approve an AI tool? 

‍

Zlatko: Ooh. Uh, well, when it comes to AI tools and tools that have AI capabilities or even AI tools, is to understand what, where, where that data resides.

‍

Mm. Are we interacting through an API? Are we interacting directly? Are they interacting with an AI model through an API? Are they hosting themselves? Can we, can we host the model in our infrastructure? Is it there? Are they using something like Bedrock, Vertex or Foundry, or are they using an enterprise plan?

‍

Oftentimes when it comes to AI, it's more of does this tool use AI? And it's very, in, in terms of TPRM, I've seen a very soft process of, you know, AI check mark, yes or no, what type of data? Oh, okay, we're good to go. But understanding, you know, where the black box is and how [00:32:00] our data goes into that black box.

‍

Is our data gonna be trained upon? Um, you know, do we have ability to get our data back? Is there d- Like, what is the deletion process? How long does that data live in, in, in, with this vendor? I think asking deeper questions on the AI use will allow better risk scoring and risk understanding of that vendor.

‍

Khush: Got it. Well, Zlatko, you survived the tabletop. Thank you so much for being here. 

‍

Zlatko: Of course. Thank you for having me. This was very intense- Yeah ... and, uh, I hope I didn't get extra gray hairs from this exercise.