The AI Security Tool You Already Own

Episode transcript

Transcript provided for accessibility and search. Minor transcription errors may remain.

Introduction

SPEAKER_01 0:04

This is AI Security Multipliers, AI Cybersecurity Governance with Steve. This week, the AI security tool you already own. AI is creating new security risks, and naturally, an entire industry is emerging to sell us new tools to manage them. But before adding another platform, another dashboard, and another agent to your security architecture. There may be a better question. How much of your AI security problem could you solve with the tools you already have? To discuss why securing AI might begin with some surprisingly familiar controls, here's Steve.

SPEAKER_00 0:51

Everyone gets excited. Then somebody discovers

Apparently We Need Another Tool

SPEAKER_00 0:54

it creates risk. And approximately 17 minutes later, there's a vendor selling a platform to secure it. Cloud, containers, SaaS, APIs, data, and now AI. We have AI security posture management, AI gateways, AI firewalls, AI runtime protection, AI red teaming, AI discovery, prompt monitoring, model security, agent security, AI governance platforms. And probably by the time you're listening to this, another category with a four-letter acronym nobody had heard of last Tuesday. Now some of these technologies are genuinely useful. Some are going to become important parts of enterprise security architecture. I'm not arguing otherwise, but I do think we're in danger of doing something cybersecurity has done many times before. Seeing a new problem. And immediately assuming we need a new tool. Because when you actually start breaking down many of the risks associated with enterprise AI, something interesting happens. A surprising number of them aren't completely new security problems. They're familiar security problems. With a very clever new interface. I'm Steve, and this is AI Security Multipliers. Today we're going shopping, or hopefully, not going shopping. Let's take a fairly ordinary enterprise AI scenario. An employee asks an AI assistant a question. The AI retrieves sensitive information they shouldn't really have been able to find. What's the problem? AI security? Possibly? But perhaps the actual problem is excessive permissions. That's identity and access management. Someone pastes confidential information into an unauthorized public AI service. AI security problem? Yes. But it's also a data loss prevention problem. An AI agent accesses a system using an overprivileged account. Agentic AI security? Certainly. But it's also privileged access management. An attacker compromises an employee's account and uses

Start With the Risk

SPEAKER_00 2:40

their enterprise AI assistant to rapidly discover sensitive information. AI attack? Absolutely. But the initial problem is still identity compromise. An AI application is deployed into the cloud with insecure configuration. AI security? Yes. Also. Cloud security. An AI generated script contains malicious code and somebody runs it on a corporate laptop. AI security? Yes. And point security might also have something to say about that. An AI agent starts behaving strangely and calling systems it normally doesn't use. AI security? Definitely. But that's also behavioral monitoring. Logging, detection, authorization, zero trust. The point isn't that AI introduces nothing new, it absolutely does. The point is that we shouldn't throw away everything we've learned about cybersecurity simply because somebody added a language model. Let's start with identity, because AI hasn't made identity less important. It's made it considerably more important. Who is using the AI? How are they authenticated? What information are they allowed to access? What applications can they reach? What privileges do they have? If an agent performs an action, what identity is it using? Can that identity be revoked? Does it have permanent access? Can it elevate privileges? Can it impersonate someone? Those are AI questions. They're also IAM questions. And organizations already have technologies designed to deal with them. Identity providers, multifactor authentication, conditional access, privileged access management, identity governance, access reviews, just in time privilege, risk-based authentication, zero trust policies. These controls don't suddenly stop working because AI arrived. In fact, they become foundational. If your AI assistant respects the permissions of the person using it, then fixing excessive access may be considerably more useful than buying something that simply tells you the AI found excessive access. That's

Identity Is Still Identity

SPEAKER_00 4:32

an important distinction. One control fixes the underlying problem, the other may simply describe it very nicely on a dashboard, and cybersecurity already has quite enough dashboards. Then there's data. AI consumes enormous amounts of information, which has suddenly caused everyone to become very interested in information governance. Funny how that happens. For years, security teams have been saying we should classify sensitive information. We should know where our data is. We should clean up excessive access. We should have retention policies. We should implement DLP. We should identify regulated information. We should understand data ownership. And the response was often something along the lines of, yes, absolutely, very important. We'll put that on the roadmap. Then generative AI arrived, and suddenly everyone wanted to know exactly where every sensitive document was by Thursday. AI has a remarkable ability to make 20 years of neglected information governance feel surprisingly urgent. But again, many organizations already own capabilities that can help. Data classification, sensitivity labels, DLP, encryption, rights management, data discovery retention, records management, cloud access controls, database monitoring, SaaS security controls. These aren't legacy controls that AI has made irrelevant, though some of the controls AI needs most. Because if AI can find information faster than humans can, you better be reasonably confident you've decided who should be able to find it. Here's another one that's easy to forget. AI still runs somewhere. People still access it from devices, agents still execute processes, browsers still download

Your Data Controls Still Matter

SPEAKER_00 6:04

files, code still executes, credentials still get stolen, malware still exists, the laptop hasn't disappeared simply because there's now an AI assistant sitting on it. So endpoint security remains important. EDR, device compliance, application control, browser security, patch management, credential protection, endpoint DLP, device isolation. These controls still matter. Imagine an employee uses AI to generate a PowerShell script. They run it. The script does something unexpected. The fact that AI generated the code is interesting, but when that code executes, your endpoint doesn't particularly care whether it was written by a developer in London, an attacker in another country, or an AI model sitting in a data center. It's code. Observe it. Control it. Detect malicious behavior. Stop it. Sometimes the AI security answer is surprisingly traditional. The same applies to cloud infrastructure. AI applications need compute, storage, APIs, databases, secrets, networks, containers, identity, logging. They get deployed into AWS, Azure, Google Cloud, SaaS

Endpoint Security Still Matters

SPEAKER_00 7:13

platforms, private environments, and occasionally into somewhere nobody in security knew existed until the invoice arrived. Again, very innovative technology, very familiar problems. Is the storage public? Are secrets exposed? Is the workload overprivileged? Are APIs authenticated? Is traffic encrypted? Are logs enabled? Are vulnerabilities being managed? Is the environment segmented? Can the workload communicate with systems it doesn't need? Do we know what data is leaving? Your cloud security platform doesn't become obsolete because the workload contains an AI model. Your CNAP doesn't suddenly say, oh, sorry, that's artificial intelligence, nothing to do with me. Misconfiguration is still misconfiguration. A leaked credential is still a leaked credential. An exposed API is still an exposed API. An excessive privilege is still excessive privilege. AI changes the potential consequences. But many of the fundamentals remain remarkably familiar.

Cloud Is Still Cloud

SPEAKER_00 8:10

Then we get to monitoring. Because AI systems generate activity. Users authenticate, agents call tools, applications access data, APIs receive requests, files move, permissions change, processes execute, network connections occur, security events happen. Which means logs. Remember logs? Before every security product apparently needed its own generative AI assistant? Those things. Your SIM, your XDR platform, your identity telemetry, your cloud logs, your endpoint telemetry, your DLP events, your application logs. They already provide an enormous amount of security context. The challenge is making sure AI activity becomes part of that visibility. What did the agent do? Which identity did it use? Which tools did it call? What data did it access? Where did it send information? Was that behavior normal? Did something change? Now there absolutely are AI-specific telemetry requirements. Prompts, responses, model

Your SIEM Would Like a Word

SPEAKER_00 9:06

activity, tool calls, agent reasoning paths, where available, model versions, guardrail events. Those may require new capabilities, but don't build an entirely separate security universe for AI if you can avoid it. Bring AI into your existing security operations model. Because the last thing your SOC needs is another console sitting in the corner that someone remembers to check approximately three days after the incident. Now at this point somebody from an AI security company is probably shouting at their podcast player. So let me be clear. Yes, there are genuinely new AI security problems. Prompt injection, model manipulation, jailbreaking, training data poisoning, model theft, insecure agent tool use, unsafe model outputs, AI supply chain risk, model provenance, agent orchestration, AI-specific runtime behavior, and security testing designed specifically around language models and autonomous agents. Traditional security products weren't designed to solve all of those

Do We Need AI Security Tools?

SPEAKER_00 10:02

problems. Specialized AI security technologies are going to be necessary. But here's the distinction I think matters. New AI risk doesn't mean every AI risk requires a new tool. Before buying something, map the risk. Then map the controls you already have. Then identify the gap. And buy technology for the gap. That sounds painfully obvious, but security architecture frequently works the other way around. Someone sees a demonstration. The demonstration is impressive. The salesperson explains that artificial intelligence is fundamentally changing everything. Everyone gets slightly nervous. We buy the platform. Then six months later somebody asks, What exactly are we using this for? And thus another dashboard is born. This matters because cybersecurity already has a tool problem. Large organizations can have dozens and sometimes hundreds of security technologies. Endpoint, network, cloud identity, data. Email, vulnerability management, threat intelligence, application security, SaaS security, CIM, SOAR, DSPM, CNAP, CASPI, CSPM, CIEM, and enough acronyms to make a bowl of alphabet soup look underqualified. Every new platform

The Tool Sprawl Problem

SPEAKER_00 11:10

creates operational overhead. Licensing, integration, training, support, data ingestion, alert management, access management, vendor management, renewals, architecture, and another place security analysts have to look. So AI security shouldn't automatically become another giant stack sitting beside the existing cybersecurity stack. Where possible, extend what already works. If your identity platform can govern agent identities, use it. If your DLP technology can inspect AI interactions, use it. If your SIM can ingest AI activity, send it there. If your cloud security platform can discover AI workloads, use that capability. If your existing security controls can solve 80% of the problem, maybe you don't need another platform to solve the same 80%. Spend your money on the 20% that's actually new. That's a much more mature way to build security architecture. And this is really the larger point. AI security shouldn't start with a product catalog. It should start with architecture. What AI capabilities are we deploying? What information do they use? Which identities interact

Start With Architecture, Not Products

SPEAKER_00 12:12

with them? What actions can they perform? Where do they run? Which applications do they connect to? What could go wrong? Then ask, what controls should exist? Identity controls? Data controls? Endpoint controls? Cloud controls? Application controls. Network controls, monitoring, incident response, governance. And only then ask, which technologies provide those controls? Some will already exist. Some may need extending, some may need configuring properly. And yes, some will need to be purchased. But now you're buying something because you've identified a security requirement. Not because somebody invented an acronym. That's the difference between security architecture and shopping.

The Multiplier

SPEAKER_00 12:56

So here's this episode's multiplier. Before you buy another AI security platform, take one AI use case in your organization. Just one. Map its risks. Then take your existing security stack and ask, what can identity already control? What can DLP already protect? What can endpoint security already detect? What can cloud security already see? What can your SIM already monitor? What can your vulnerability management program already assess? What can your existing governance processes already govern? Then identify what's left. That's your actual AI security gap. And here's the multiplier. Do this across your major AI use cases. And instead of building a completely separate AI security program, you begin extending the cybersecurity capabilities you've already spent years building. You get more value from the technology you already own, you reduce tool sprawl, you simplify operations, and when you do buy something new, you know exactly why you're buying it. AI is absolutely changing cybersecurity. There are new attacks, new architectures, new vulnerabilities, new ways of interacting

Closing

SPEAKER_00 14:01

with information, and new autonomous systems that require controls we've never needed before. We should take those risks seriously. But we shouldn't confuse new technology with the idea that everything we already know has suddenly stopped working. Identity still matters, data protection still matters, endpoint security still matters, cloud security still matters, logging still matters, least privilege still matters, zero trust still matters, good architecture still matters, and perhaps most importantly, knowing what technology you already own still matters. So the next time somebody tells you that you urgently need another AI security platform, maybe you do, but before you sign the purchase order, have a look in the toolbox. You might be surprised how much of the answer is already sitting there. I'm Steve. This is AI Security Multipliers, and remember, AI should multiply your capability, not your mistakes. I'll see you next time.