AI for Security vs. Security for AI: Two Problems, One Stack

Every vendor at every conference this year has an AI story. Most of them are telling one of two very different stories and using the same three letters for both.

The first one is AI for security : using machine learning and large language models to detect, triage, and respond to threats faster than humans can. The second one is security for AI : protecting the models, data, and pipelines that make those systems work, along with every other AI system your organization has quietly adopted.

They are not the same discipline. One makes your SOC faster. The other keeps you from having a very bad quarter. If you are the person responsible for both, it helps to keep the boundary clear.

AI for Security: The Defender's Force Multiplier

This is the side most practitioners have already touched, whether they realize it or not.

Behavioral analytics tools have been running unsupervised models for years. When a UEBA platform flags an account authenticating from a datacenter IP range at 2 AM, that is a model deciding the behavior falls outside a learned baseline. No one wrote a rule for that specific case. The same is true for network anomaly detection, which builds a picture of what normal traffic looks like on your subnets and surfaces the outliers.

What has changed recently is the layer on top. Language models are now doing the work that used to eat an analyst's afternoon:

• Alert triage and enrichment: Correlating a SIEM/XDR alert with identity signals, recent sign-in risk, and asset criticality, then producing a summary an analyst can act on in thirty seconds instead of twenty minutes.
• Query generation: Translating "show me all devices that contacted this domain in the last week" into working KQL, without the analyst needing to remember whether the table uses Timestamp or TimeGenerated.
• Phishing analysis: Reading headers, authentication results, and body content together, then explaining why a message is suspicious in language a help desk tech can relay to the user.
• Detection engineering: Drafting rule logic from a threat report and suggesting tuning when a detection is generating noise.

The honest assessment: these tools compress time, they do not replace judgment. A model that summarizes an alert is still working from the telemetry you gave it. If your logging has gaps, AI-assisted triage produces a confident summary of an incomplete picture which is arguably worse than no summary at all.

For a small team, though, the value is real. When you are the only security practitioner supporting over a thousand users, the difference between forty minutes per investigation and twelve minutes per investigation is the difference between closing the queue and drowning in it.

Security for AI: The Attack Surface Nobody Inventoried

Here is where things get uncomfortable.

Your organization is already running AI systems. Some you deployed deliberately. Many arrived through a SaaS vendor's feature release, or an employee pasting a contract into a chatbot to get a summary. The attack surface exists whether or not anyone has assessed it.

The failure modes do not map cleanly onto traditional categories:

Prompt injection: An attacker plants instructions in content the model will read a webpage, an email, a document and the model follows them. If the model has tool access, this becomes remote code execution with extra steps. The OWASP Top 10 for LLM Applications lists this first for a reason: there is no clean fix, only mitigations.

Data leakage: Employees paste sensitive data into external AI tools. This is a DLP problem with a new destination, and most DLP policies were not written with AI endpoints in mind. If your policies enumerate cloud storage and webmail but not AI assistants, you have a gap.

Training data poisoning: If a model learns from data an attacker can influence, the attacker can shape its behavior. This matters most for organizations fine-tuning on internal data, but it also applies to any system that learns from user feedback.

Model supply chain: Pre-trained models pulled from public repositories are executable artifacts. Some serialization formats can run arbitrary code on load. The same scrutiny you apply to a container image or an npm package applies here, and almost nobody is doing it yet.

Excessive agency: The interesting risk is not the model saying something wrong. It is the model being wired to an API that can create accounts, send mail, or modify records, and then being convinced to do so. Every integration is a permission grant.

Shadow AI: The aggregate of all of the above, happening in tools you did not approve and cannot see.

Where They Meet

The two disciplines converge in an uncomfortable place: the AI tools defending your environment are themselves AI systems that need protecting.

A security copilot with read access to your SIEM, your identity platform, and your endpoint telemetry is an extraordinarily attractive target. It has been granted broad visibility by design. If it can be manipulated through injected content say, a crafted phishing email that the copilot reads while summarizing an alert, an attacker has a path to influence your investigation from inside your own tooling.

This is not theoretical hand-wringing. It is the natural consequence of giving a language model read access to attacker-controlled input, which is exactly what security telemetry is.

Practical Steps

If you are trying to make progress on both fronts without a dedicated AI security team:

1. Inventory first: You cannot secure what you have not found. Start with your CASB or cloud app discovery data and identify which AI services users are reaching.
2. Extend DLP to AI destinations: Add AI service endpoints to existing policies. Start in audit mode and look at what people are actually sending before you block.
3. Set an acceptable use policy people will follow: Approved tools, prohibited data classes, a path to request exceptions. A policy that bans AI outright drives usage underground.
4. Treat model endpoints as external dependencies: Log the calls. Monitor the volumes. Alert on anomalies. The same discipline you apply to any third-party API.
5. Scope AI tool permissions tightly: Read-only by default. Human approval for anything that writes, sends, or changes state.
6. Validate AI-generated output: Do not push a generated detection rule to production without review. Do not act on a generated summary without checking the underlying evidence.
7. Map to a framework: The NIST AI Risk Management Framework and the OWASP Top 10 for LLM Applications give you shared vocabulary for conversations with leadership and auditors.

The Takeaway

AI for security is an efficiency play. It compresses investigation time and lets small teams cover more ground. Adopt it deliberately, validate what it produces, and remember it inherits every gap in your telemetry.

Security for AI is a risk management problem, and it is already lives in your environment. The tools are in use. The data is moving. The only question is whether anyone is watching.

The organizations that will handle the next few years well are the ones treating both as ongoing programs rather than one-time projects. Start with the inventory. Everything else follows from knowing what you actually have.