Raising Your Compliance Ceiling as AI Raises the Stakes
Compliant doesn't mean secure. See how SecurityMetrics' 3-tier framework helps you raise your compliance ceiling as AI accelerates old threats.
Updated:
August 7, 2026
Compliant doesn't mean secure. See how SecurityMetrics' 3-tier framework helps you raise your compliance ceiling as AI accelerates old threats.
You can pass your PCI assessment and still be leaking cardholder data. In e-commerce, "compliant" and "secure" are not the same thing — and AI just made the gap between them a lot harder to ignore.In this episode of Practical Cybersecurity, SecurityMetrics Principal Security Analyst Jen Stone sits down with forensic investigator Aaron Willis and host Hef (SOC & threat hunting lead) for a real-world panel on what AI is actually doing to PCI compliance. No hypotheticals — just what auditors and forensic investigators are seeing in the field right now under PCI DSS 4.0.1.
What you'll learn:
Jen Stone: Hello and welcome back to Practical Cybersecurity. My name is Jen Stone. I'm one of the principal security analysts here at SecurityMetrics. I have a very special and exciting thing for you here today. I got to be part of a panel on a webinar all about artificial intelligence, and I thought, it's so great, let's present it to you as part of this podcast. I hope you enjoy it as much as I do.
Heff: On today's webinar, we have some very special guests. We have Jen Stone — needs no introduction. You're probably familiar with her. And if you've ever watched any of our forensic prediction webinars that we do, along with a lot of other stuff, we have Aaron Willis here from the forensic side of the house. I'm Heff, I'm your host. I'm on the cybersecurity side, running our SOC and our threat hunting teams. I know we spend a lot of time together, Aaron, with those forensic predictions. It's pretty good webinar.
Jen Stone: And I want to hear more about that. How are the results from your top four forensic and cyber predictions for 2026? How accurate are you so far?
Aaron Willis: We talked about AI as a force multiplier. Some, man. Have we seen an increase in the amount of AI-assisted attacks going on?
Heff: The good thing is, though, us good guys are fighting back. We are absolutely deploying AI in the field to try to stay ahead of the speed at which these attacks are having.
Aaron Willis: Half my day is spent building AI-assisted forensic tools.
Heff: That’s a lot of work!
Aaron Willis: Yeah, that's how much time we have to spend battling this AI stuff and staying ahead of all these attacks that we're seeing.
Heff: I love that we've got these four predictions, Jen. And we were so right on the money with all four of our top predictions this year.
Aaron Willis: We've got agentic AI that we're seeing now, bots that are going out, smart bots, things we've never seen in the past that can go out and drill holes through websites and e-commerce sites like we've never seen before.
Heff: I know the primary battleground — it seems like it's the e-commerce, it's the healthcare, we're still seeing that.
Aaron Willis: We're still seeing a lot of credential compromises happening. Some of the basic stuff, session hijacking, is still around, but all these things are being assisted by AI.
Heff: One of our other predictions that we got right was about the session hijacking, and the credential compromise and stolen credentials are still the thing that bad guys are going after. Session token theft is part of it. I know we've all seen a lot of the automated MFA attacks. We call it MFA fatigue because it really is.
Aaron Willis: MFA fatigue is a very real thing.
Heff: But one thing that I did want to call out — I'm blown away, guys, about in the news, the velocity of vulnerabilities being found and the number of zero days. It wasn't like just a month ago, not even a month ago, Microsoft, like 500 vulnerabilities announced in one week. That was insane. And then like a week before that was 200 vulnerabilities.
Aaron Willis: Well, there's also the humorous case of Claude mythos
Heff: Yes.
Aaron Willis: It was too dangerous for the public to get their hands on. And of course, that just made us all want it more. But it found — supposedly — how many exploits did it find?
Heff: I thought it was like 5000. There was some insane number. But, Aaron, in your world — before we get to Jen — inside your world, you're doing a lot of e-commerce, a lot of forensic data investigations. Something like how many cases this year alone?
Aaron Willis: Thousands of cases. E-commerce cases specifically are really what we've been focusing on — over 2000 of those in a year. And what we're seeing is that almost 100%, maybe even 100%, of all the attacks that are happening, all the successful breaches, are still happening on the merchant side. Even when they've moved over to iframes or things like that, the attackers are getting in on those websites — maybe they have a little bit less security because the merchant is depending on the security of that iframe. They're getting in and defeating those iframes through various clever techniques that are allowing them to pull the credit card data right out of the iframe.
Heff: So damaging. I know you guys have a lot of findings — there's a lot of things you're seeing from Shopping Cart Monitor, that product we have, and it's phenomenal, how it's evolved from my perspective, outsider looking in. Can you share some of the findings you're seeing from that?
Aaron Willis: Shopping Cart Monitor — we're monitoring tens of thousands of live, active e-commerce sites. We're finding over one skimmer a week right now, is our average.
Heff: And where is that skimmer being found — is it in the browser, is it somewhere else?
Aaron Willis: It's being found specifically in the browser, often on the checkout page itself — really hidden in third-party code quite often, or in merchants' scripts that they've included. But we're finding them so often now in third-party plugins, code included from the database. If you think about what that database is, it sits out on the server and it's not being scanned by anything, really. Scripts in the database can sit there for a long time and you can scan the server — you never see them till they're included on the checkout page in that rendered HTML page. And so if you don't have eyes in the browser at the moment of checkout, that script may come in at the very last second. It may be triggered just by somebody entering the credit card field, and then that script gets pulled from the database, runs for just a split second, and then vanishes into the ether.
Jen Stone: I'm glad we're going to dive into that in a little more later, because there are so many people who don't recognize how easy it is for this attack to execute — but you're seeing it all the time.
Aaron Willis: We're seeing stuff even in local storage on the browser — credit cards being stored there, malware being stored there.
Heff: Really wild.
Jen Stone: Crazy.
Heff: I know, SecurityMetrics — one of the really cool new pieces of tech that we introduced was Specter AI. I've heard from a lot of folks say, well, what is Specter, what does it do? Can you take a super brief moment to explain what that tool is and what it's doing?
Aaron Willis: Specter AI is kind of a derivative, or an enhancement, over our original Specter tool, which went out to millions of websites, would grab anything it could see on the landing page and do a quick analysis and send back any IOCs or things we found that were 100% associated with data breaches. Specter AI is an enhancement on that, where we actually use AI to determine — if we're seeing anything malicious on that page — it's really making those static looks a lot more intelligent. We can pick out things now that we just didn't have the time or the bandwidth to see. We can feed that data to AI and pick out the things that are hidden in code that a human eye just wouldn't be able to.
Heff: See, at volume, at scale.
Aaron Willis: Yeah, a volume at scale. And so we're going to share some of those findings too — just fascinating what Specter AI can pick up. We've recently found hundreds of different attack vectors and malicious actors moving in ways we've never been able to see before.
Heff: Before we get off this topic, I am dying to know — we don't always get a chance to talk and share some of the really amazing stuff that we find. But I know you've had a bunch of case studies just in the first six months of 2026. Can you take a brief moment to share maybe one or two things that just blew you out of the water, that our audience would love to hear about?
Aaron Willis: One of the craziest things we saw this year — and this is just recent, in the last few weeks — we found a skimmer running on a page that had all the security in place, including an agent running specifically to find JavaScript skimmers on the checkout process. And this is not a low-budget skimmer. This is one of the premier agents that —
Heff: Are, that missed it.
Aaron Willis: Yeah, that flat-out missed it. And it had to do with the way the merchant was processing how they were rendering HTML on the page. They were infecting a JSON object called Next Data, from the Next.js framework. In that framework, everything gets put together server-side, and then as it gets pushed to the client side, it hydrates and adds in all the little elements the customer needs to check out. And so they were able to bypass all of that. And they did the most crazy thing — instead of stealing a credit card, they logged the keystrokes, old-fashioned keylogging. And the security software that was running the agent missed it because they were just capturing it, putting it over in local storage, and then they didn't pull it out right away.
Heff: Whoa.
Aaron Willis: They didn't go grab it and reassemble it and say, "Oh, hey, we've got the credit card." They just — every once in a while — reached into local storage and pulled out a keystroke, pulled out another one, just a little bit at a time. So the software that was there, the agent, completely missed it.
Heff: So, if we had to summarize here — because I know we have a lot of folks in the audience on different sides of the business, some on the compliance side of the house, some on the cyber side, some really deep in the audit world — how has that threat landscape changed? It seems like compliance auditing does not stop at all, mixed with this new tech we're rolling out. What's that world like?
Aaron Willis: It's real time, is really what is happening. The threat landscape is active, it's dynamic, it's changing. We have agents on pages that we think are picking things up, but that agent got defeated. And we found it because we have an agentless solution — we were able to watch things happen, sort of after the fact. And the neat thing about an agentless solution, Heff, is the attackers don't know we're there. That's really what allowed us to find that breach we were talking about — they didn't know we were there watching. The moment they can see that an agent is there, that gives them a whole lot of information to work around. They can find the holes, the chinks in the armor.
Heff: Yeah. Your team has done a phenomenal job of finding these threat actors in the browser, in the shopping cart area — kudos, hats off to what you guys have been able to do for the previous six months. And what's left here going toward 2027 — I know in Jen's world, the auditing world — what's going on? I'm hearing rumors about confusion around PCI DSS.
Jen Stone: There is, because here we have this big artificial intelligence thing happening and people are saying, well, 4.0.1 doesn't say "artificial intelligence" and address it. But it doesn't have to. So instead of saying we need to address artificial intelligence, we say: in what ways are we using artificial intelligence that's already covered by PCI DSS? And it is. Let me give you a few examples and then you'll start getting the pattern. For example: who's allowed to see full PAN, who's allowed full access to cardholder data — who are you sharing that with? Well, if you're sharing it with AI, then you've got to have a business justification for that. Typically we're not going to want to share that — it better be internal, private, fully locked down if you are in some way having AI interact with it. So who's getting my data — AI is another one, you know, we've got applications and systems and human beings that need to be justified and protected in certain ways. AI falls right into that. And that leads right into requirements 7 and 8, access and authorization — those still have to run with least privilege, and still have to be fully justified and authorized. So all of the requirements fully apply to AI. Let's look at secure AI workflows in code — a lot of people are using AI to help develop code. Well, you still have to apply the secure software development lifecycle, all of the requirements in requirement 6, to whatever your AI is doing to help develop code. So I'm not going to dive into every single one of them, but I just wanted to show you a pattern: if AI is doing a thing and it falls into a certain bucket, you have to apply those requirements to that bucket. I really think where people got confused was it didn't start using the words "artificial intelligence" — but it doesn't have to.
Heff: There seems to be a lot of confusion around two requirements in particular. I want to take a brief moment to dive into what you're seeing out in the field — requirement 6.4.3 and requirement 11.6.1, script security, and FAQ 1588. What is going on in this world? Can you decipher and clarify?
Jen Stone: I'm so glad you brought up FAQ 1588, because — and my heart goes out to any merchants that have e-commerce — this was implemented in a confusing way, and it's critical, because this is where we're seeing data actually being lost. So let me run you through it. We care about protecting scripts on a page because the scripts on a page are what's stealing cardholder data. 4.0.1 came out, and originally the SSC said — SAQ A said — hey, you have to now protect scripts on a page. And then they said, oh no you don't. Or it seemed like they said, oh no you don't.
Heff: That's where the confusion hit.
Jen Stone: They didn't actually say that, because as we can see from FAQ 1588, this is still a problem and it's still something you need to address. It's kind of hidden — if you don't read the entire thing, you should. Go read the SAQ A eligibility criteria. The eligibility criteria say that you need to protect the scripts on a page as if it were 6.4.3 and 11.6.1. But it does it in a very lightweight — oh, and by the way, you got to do this — 1588 really locks this down for us. And the Council tells us you can meet the compliance requirements in one of two ways. Either get your service provider to say that your environment is not susceptible to these kinds of attacks, which is insane — although a couple of them did it very, very early, and then they suddenly went —
Heff: No.
Jen Stone: — we cannot, because they can't. Right? So that also confused people — like, well, last year they said they would do this for me, why aren't they doing it this year? Because they learned. So you either have to get a very well-documented, written confirmation from your payment provider saying that the embedded solution protects the merchant page, or you have to implement script management and tamper detection. And that is what every — here's why you should do it — it's where we're seeing the breaches. I have come to have a love-hate relationship with 6.4.3 and 11.6.1, because it's so important to protect your data, and at the same time it's really hard for a lot of merchants to understand. They felt a little bit of whiplash over how to accomplish this. So I get it, and it's frustrating, but it's real and you should be doing it. There's another aspect too — most of the time people are like, well, I have an iframe, that makes it SAQ A. Yes, that's a real clear use case for having 6.4.3 and 11.6.1 in place. But then there's, well, what if I do a full redirect? I'm going to tell you what the Council says so that you can pass your audit, and then Aaron's going to tell you why you shouldn't skip this. So pay attention: under SAQ A FAQ 1588, full URL redirects completing the SAQ A are exempt from requirement 6.4.3 and 11.6.1. However — so that you can pass your PCI — here's what you do if you actually want to be secure.
Aaron Willis: We've seen a 300% increase in merchants using payment redirects, because it's an easy way to get around all this.
Jen Stone: Absolutely easy.
Aaron Willis: And the hackers and attackers are all cheerleading it. Why? It's so much easier to defeat a payment redirect than it is an iframe. And we are seeing a corresponding increase in the number of attacks against payment redirects. Think about an iframe as a security box around that payment data — an attacker has to know what they're doing to get in and defeat that iframe. What's a payment redirect? Click, click — it's a link.
Jen Stone: That's all it is.
Aaron Willis: Is there anything around that link protecting it? No. The hacker just literally goes and changes the link, and now it stays — your customer doesn't go out where they should, it stays right on your site usually, or goes to an attacker's site that's duplicating, mimicking the real payment checkout. That's far, far easier. And we're seeing some pretty sophisticated attacks where the payment still completes.
Heff: That's wild.
Aaron Willis: So everybody's happy.
Jen Stone: That's the argument that I get from my merchants — they say, well, everything's fine, we're still getting payments. That does not mean you have not been breached. Just because the bad guys got your cardholder data doesn't mean you also didn't get it, right? That can be used for two purposes — the intended and the not so intended.
Heff: There are so many questions that have come in to us. At the very end today, we're going to take some time to try our best to answer all the questions — if we don't get to your question, you can always send it to us, pick up the phone and call us, and we'll do our best to make sense of the insanity that's going on right now in the last six months. Jen, help me understand the requirements that are impacted by AI — the PCI requirements impacted by AI, there's quite a few. I was actually kind of blown away that there's this many. If we could start with maybe 12.3.1, 12.3.4 — targeted risk analysis is a big buzzword right now.
Jen Stone: It is. A targeted risk analysis is intended to look at a specific thing you're trying to make decisions on. How often do we, for example, test for skimmers out in the wild? How frequently are we scanning a certain thing? So it's usually around the frequency of scanning that type of thing. If you haven't gone and looked at what you said before and then asked yourself, how does AI and the acceleration of the bad guys' activities affect this decision — then you haven't got your bases covered. So really, every targeted risk analysis should have you stop and say, does AI affect this? If it does, let's redo it.
Heff: So if I adopt a new AI tool in my business, should I do a TRA?
Jen Stone: If you adopt a new tool in your business, not only should you do a new TRA for all the ones that apply, you should also say to yourself, hey, this is a major change to my environment, and then review all of the things that a change to your environment would trigger. So new fee scanning, and potentially looking at your scope — AI could expand your scope, probably does. So making sure — where is my AI, where is my PCI network, and are those in any way related? Making sure you've updated all of the ways in which anything can interact with cardholder data, including AI — could trigger new network diagrams, new data flow diagrams.
Heff: Sounds like so much work, but it's worth it. It really is.
Jen Stone: But also, if you have AI help you, it can help.
Heff: Requirement 8 is the MFA — it's not just about knowing these new tools and having a risk analysis done, but MFA, the access to it — how has that been impacted?
Jen Stone: Multi-factor authentication is one of the most important things we see in helping people keep the bad guys out. And yes, we all kind of get tired of having to put in a code, or whatever it is we're doing for the MFA, but it's critical for us to be able to, in some way, lock down our environment. So MFA has to be everywhere across administrative and remote pathways. I recommend people do it everywhere — anytime you can get access to cardholder data, that's a place you need to apply MFA.
Heff: Requirement 12.6.3 is something near and dear to my heart, especially here at SecurityMetrics, where you're talking about updating your phishing training. There are so many different types of AI-generated phishing examples out there from the news that you could pull and share with your team, share with your employees. Could we spend just a quick moment on requirement 12.8? How is that impacted? Because I'm hearing a lot from my friends and business owners that that's a big deal to them.
Jen Stone: Third-party service providers — a lot of people aren't even thinking, "oh, this AI that I'm now using is another third-party service provider." Yes, it absolutely is. So you have to make sure you're taking that into account as you do all of the 12.8 sub-requirements.
Heff: Okay, Jen, summarize for us — give us a key takeaway. What would that be, about the changes you're seeing on the battlefield right now?
Jen Stone: PCI DSS is reactive to risk related to cardholder data. It's not that AI necessarily is creating different risks — it's accelerating the risks that exist, because AI can do all of the current and previous threats faster. So it has to be taken into account when you consider not just what the threats are, but are the threats accelerated, and then apply the right security controls that way.
Heff: We're going to switch gears for a moment — we're going to get to your questions here in just a moment at the end. But I think it's really important we address this concept of compliance as a security floor, not a ceiling. This isn't something new, folks, this has been around for a very long time, but from a practical cybersecurity strategy standpoint, it's really more important than ever when you talk about the persistence of these AI threats and how you stay compliant. And just because you're compliant doesn't mean you're secure. So let's dive into this — there are three tiers on this framework. What is tier one all about — continuous compliance, is that right?
Aaron Willis: It really involves real-time monitoring, watching. Compliance is not an event. You've got to be on top of it all the time.
Heff: Now tier two is about extending the controls coverage for AI, AI usage policies. Do you have a lot of conversations with clients about that?
Jen Stone: It's surprising to me how many people haven't updated their acceptable use policies to include whether AI is acceptable or not. A lot of people are kind of afraid of AI and don't want to consider it, so they don't — which is not a good way to think about a risk. Being willing to dive into something uncomfortable and say, how do I look at all of my policies and procedures, how do I look at all of my targeted risk analyses, how do I look at all of my training — and then modify it for the reality, which is AI.
Heff: Three or four years ago, all the rage of conversation was about, do you have an AI usage policy, do you have that in place? Now it seems like the conversation shifted more toward, are you doing deepfake simulations, are you testing for that kind of stuff? So tier one, continuous compliance; tier two, extending controls for AI; tier three shifts the conversation to getting a really nice baseline around PCI DSS 4.0.1.
Aaron Willis: Really about knowing what's in your browser — inventory.
Heff: Yeah, script inventory.
Aaron Willis: Know what's on that checkout page. In the old POS environments, we knew what was on that checkout server, and it was hard to get something in there — you had to go through all kinds of hoops to get something approved. Now we've found hundreds, three, four hundred scripts on a checkout page. That is a massive surface area on a single checkout. And if you think about that, that could be hundreds of thousands, if not millions, of lines of code that all have access to the credit card data on that page.
Heff: Wow. If you are not doing targeted risk analysis, scenario planning and simulations — I know it's sometimes a struggle when you're trying to run the business day to day — but knowing what the potential doorways are into your business, it's such a challenge. All right, let's talk about — before we start to wrap this up, I know we've had some really good questions come in all the time here, and I feel like this is the perfect venue to cover some of these. Let's talk about question number one. This one came in about redirecting customers, and we kind of briefly touched on it — maybe there's some good takeaways here. Redirecting customers to a hosted payment page, we're talking about SAQ A — are we legally required to comply with 6.4.3 or 11.6.1?
Jen Stone: I love this question, it's so good, because it has so much in it — because it used the word "legally," and a lot of people think that PCI DSS is a law. It's not a law, it is a standard that is required by the payment card industry. However, if you are a SAQ A customer/merchant and you're not fulfilling your obligations by meeting that, a lot of things can happen, including they'll take away your ability to accept credit cards. You don't want that as a merchant — you want the ability to accept credit cards. I'm not saying that's the first thing that happens, I'm saying that if you don't become compliant, eventually there is an end stop, and that's it. So, setting aside the legal thing — do you need to comply with 6.4.3 and 11.6.1 if you redirect? According to PCI DSS FAQ 1588, you are not required to. You can pass your PCI compliance without doing anything about 6.4.3 and 11.6.1. But I'm here to tell you it's a bad choice. Don't do this, because you don't want to lose card data, you want to be secure. But please use your judgment in this and implement these things.
Heff: This is a good segue — if our merchant site uses an iframe, how do we satisfy the script protection rule in FAQ 1588?
Jen Stone: Same realm, just do it. Either get from your payment service provider that you are not — here's the other thing, I want to add a little nuance. I had a customer say, "My payment provider said I am a SAQ A, so I don't have to do this." And I said, that's not what this says at all. Just because they told you that you're a SAQ A, which they were, doesn't mean you don't have to do this. They have to tell you formally, in a written statement, that you are not susceptible to the risks covered by 6.4.3 and 11.6.1. Nobody's doing that anymore. So you need to put in 6.4.3 and 11.6.1.
Heff: Okay, next question — I thought this was a pretty good one — does an agent-based protection tool fully satisfy the requirements of 6.4.3 and 11.6.1? What are your thoughts around that?
Aaron Willis: Agent-based tools are absolutely better than nothing, Heff. But in our example, we showed how an attacker knew the agent was there — it could monitor that agent's behavior, find its weaknesses, and make an exploit for it. They're not bulletproof. So absolutely, you want something in place, and an agent is better than nothing, but something like an agentless solution, where the attacker doesn't know what's happening — it gives them nothing to know, no behavior to see, to get around.
Heff: I like the concept — we've talked about this for decades, defense in depth. When you're pairing a client-side control with external agentless monitoring like Shopping Cart Monitor, I think that's a winning combination for answering this question. All right, another question that came in — what qualifies as a payment page script under PCI DSS 4.0.1? What is this — any script?
Payment fields, would you include analytic tools, marketing pixels, tag managers? I mean, the list goes on and on.
We had another question that came in here, and that's around the notification obligations — what am I to do under 11.6.1 if an unauthorized script change is detected? What's the step, what's the process, is there one?
Jen Stone: You have to immediately notify — that's part of 11.6.1, immediately. So whatever you're using for your tools to find out, it needs to give a notification right then, and then people need to dig into it, find out what's going on. That's also kind of tied to other notifications — who else needs to know besides the people digging into it right now? Is there a follow-on notification? Well, yes — there's merchant agreements on who they're supposed to tell and under what timelines, to let other people know either that there was an incident being investigated, or that there was a known breach of data. So it really depends on your agreements — knowing those contractual agreements is pretty important in this case.
Heff: It seems like it could get really messy really quickly, depending on what state — or what country — you're operating in.
Aaron Willis: And this is so important too, because oftentimes when we go into a forensic investigation, we find out there were tools running that caught things that would have ended it early, and we find out nobody was paying any attention. Of course, it went to an email account that nobody's reading, or they read it once a month. You have to read it!
Jen Stone: It has to be a full conversation. For it to be an immediate notification, right — not just to shout in the dark.
Aaron Willis: And you have to be watching every day, reviewing those alerts every single day.
Heff: Okay, we had a couple of AI questions that came in, and some regulatory questions — we have to get to these, I think they're so important for the audience. If I adopt an AI-powered chatbot or a search tool and I'm embedding it in my website, will that trigger a risk assessment if I start embedding those chatbots or search tools?
Jen Stone: Absolutely, because it changes your environment in significant ways that you have not gone through any kind of risk analysis for previously. So definitely, it triggers a risk assessment.
Heff: Doing that TRA before you deploy is so critical. All right, you've got to know the boundaries, the data boundaries. Let's talk about this question too — what specific evidence will PCI assessors look for to verify that your security training covers AI threats? What kind of evidence are you looking at?
Jen Stone: A lot of times we'll say, can you give us a summary of what's being taught, what are the modules — we want to know what those modules are, and then a little bit of detail in them, to make sure it's really covering AI-related things. And especially, we'll say, is this training applicable in ways that the person getting it can apply it in their job? So we try to look at not just are you throwing information at people, but is it something that's immediately applicable to the people receiving it? And then, did they actually do the training? Did they complete this training? So the best training out there has modules that are modifiable, and then there's usually some sort of a test associated with it — not just "I pushed play through all of these things," but something that tells us people are taking in the information that's necessary. And then, hopefully, some sort of phishing simulators — simulators for any kind of AI attacks.
Heff: Really good, great question, by the way. We're going to end with one final question here, and this is a toughie — you might need some time to think about it, for the audience and for us to answer it. Is there an operational risk difference between employees using public AI tools versus private, enterprise-level AI tools? Is there a difference? I think there is.
Aaron Willis: There's a massive difference.
Jen Stone: You mean it's not all just — Claude, what I'm using, Claude, my company says I can use Claude, what are you talking about?
Aaron Willis: There's so many options out there right now, from free ChatGPT — you can just go to a browser and start using AI now. But if you think about what's happening to the data that you're entering in — you are training that chatbot you're interacting with, so you can inadvertently share private data publicly, not necessarily directly, but things can leak out in indirect ways. We've seen cases of intellectual property leaking out through these public AI chatbots, where you're entering things that nobody should know about, and that AI is trained on it, and then somebody else in a different country can be asking that chatbot the same thing and it says, "Oh yeah, I know a solution for this" — and there goes your intellectual property.
Heff: I think that's so hard for a business owner to understand — how critical it is that you give people the tools they need that are approved, that are within your boundaries, of what risk you're willing to tolerate for your business.
Jen Stone: And I don't think it's a rational response either — "we will not use any AI in our business" — because if you don't give your people the tools that are locked down and governed by the enterprise, they're going to go use public tools. They're going to use what they can, because they want that boost in productivity, or that ease of understanding. So give them the tools that are locked down, and you're going to reduce your risk of them going to a public, non-lockdown tool.
Heff: So there you have it, folks. We have Jen Stone from the audit side of the house at SecurityMetrics, we have Aaron Willis on the forensic side, and got me, Heff, here from the cyber side. As we wrap it up today — it's fascinating, the world we're in — there's no brand-new compliance laws as of the recording of this video.
Aaron Willis: AI didn't change the rules. It just raised the stakes.
Jen Stone: Absolutely.
Heff: All right, well, there you have it, folks. Thanks for joining us, as always. Share your questions, give us a call, or email us, let us know. Stay compliant — that's what we do here at SecurityMetrics.
.svg)