AI Security vs AI Safety vs Cybersecurity: What's the Difference?

June 25, 2026 · Securing AI: How AI Gets Attacked — and Defended (part 2)

▶ Watch on YouTube & subscribe to The Stack Underflow

Every week a new “AI safety” incident makes the headlines, and every week the comment section splits into two camps that are talking past each other. One group is worried about prompt injection; the other is worried about hallucinated medical advice. They are both right — but they are naming different problems with the same word.

When you blur three distinct disciplines into the single phrase “AI risk,” a dangerous thing happens: the risk that falls between disciplines belongs to nobody. A security engineer closes the JIRA ticket because “that’s a safety thing.” A data scientist defers to legal because “that sounds like a compliance thing.” Meanwhile a real attacker — or a model that needs no attacker — slips through the gap. As a developer shipping AI in production, you need a map. Here it is.

The one-sentence version: AI security protects the AI from attackers; cybersecurity protects everything around the AI now that it is a new component in your stack; AI safety stops the AI causing harm even when nobody is attacking it — and a jailbreak lives in the overlap where all three collide.

The three cards

Think of each discipline as a card on a whiteboard. They share edges, but they are not the same card.

 ┌─────────────────────┐   ┌─────────────────────┐
 │                     │   │                     │
 │   AI SECURITY       │   │   CYBERSECURITY     │
 │                     │   │                     │
 │  Protect the AI     │   │  Protect everything │
 │  from attackers     │   │  else, now that AI  │
 │                     │   │  is in the mix      │
 │  (the pipeline      │   │                     │
 │   is the target)   │   │  (AI is a new door  │
 │                     │   │   into your stack)  │
 └──────────┬──────────┘   └──────────┬──────────┘
            │  A ∩ B: leaked secret   │
            │  via AI tool            │
            └─────────┬───────────────┘
                      │
            ┌─────────┴──────────┐
            │                    │
            │   AI SAFETY        │
            │                    │
            │  Stop the AI       │
            │  causing harm with │
            │  NO attacker       │
            │                    │
            │  (A ∩ C: jailbreak │
            │   is security AND  │
            │   safety)          │
            └────────────────────┘

Let us walk each card in turn.

Card A — AI Security

AI security is the practice of protecting your AI systems — models, training pipelines, APIs, inference endpoints, and all the data that feeds them — from adversarial attack. The adversary is a person or automated system trying to subvert, steal, corrupt, or weaponize your AI stack.

The attack surface covers the full ML lifecycle: training-data poisoning at Stage 0, supply-chain compromise of model weights at Stage 1, adversarial inputs at inference (Stage 3), prompt injection into deployed agents (Stage 4), and so on. If you have not yet mapped that lifecycle, see The AI Attack Surface Explained — it is the prerequisite mental model for everything else in this series.

Concrete examples: an attacker who embeds a backdoor trigger in a fine-tuning dataset; a researcher who reconstructs training examples using membership inference; a red-teamer who crafts an adversarial image that flips the classifier label with a single-pixel change.

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is the primary framework for mapping AI security techniques. As of early 2026, ATLAS v5.4.0 catalogs 16 tactics, 84 techniques, and 56 sub-techniques — expanded significantly in late 2025 to cover agentic AI attack patterns (MITRE ATLAS, 2026).

Card B — Cybersecurity

Cybersecurity — the traditional discipline of protecting networks, identity, endpoints, and data — does not disappear when you add AI. It changes shape. AI is now a component in your existing stack, and that component creates new entry points into infrastructure that existed before the model did.

An LLM plugin that calls your internal APIs can be manipulated into leaking database credentials. An AI coding assistant that has read access to your repository can be prompted to exfiltrate secrets. An agentic workflow that browses the web can be redirected to an attacker-controlled page that injects commands into your CI/CD pipeline.

These are traditional cybersecurity outcomes — credential theft, lateral movement, data exfiltration — but the vector is the AI layer. The OWASP LLM Top 10 2025 edition formalises several of these: Supply Chain (LLM03:2025) and Improper Output Handling (LLM05:2025) both describe how the AI component becomes a pivot into traditional infrastructure.

Card C — AI Safety

AI safety is the practice of preventing an AI system from causing harm even when no attacker is present. The system is behaving exactly as designed — and that is precisely the problem.

A content-moderation model trained on skewed data consistently flags posts from one demographic group at higher rates. A medical summarisation model confidently invents a drug interaction that does not exist (a hallucination). A customer-service agent escalates a distressed user’s mental-health crisis in the wrong direction because its reward signal optimised for call resolution time, not user wellbeing.

No exploit was needed. No credentials were stolen. The system did what it was trained to do, and harm resulted anyway.

The NIST AI Risk Management Framework 1.0 (NIST AI RMF, January 2023) formalises this distinction with seven trustworthiness characteristics — the properties a trustworthy AI system must exhibit:

Notice that Safe and Secure and Resilient are separate entries. NIST put them on different rows on purpose. That single table is the standards body’s answer to the people who say “safety and security are the same thing.” They are not — and the framework tells you which team owns which row.

The dangerous overlaps

Three clean cards would be convenient. Reality gives us three overlapping ones. The overlaps are where most real incidents live — and where ownership breaks down.

Overlap A and C: the jailbreak zone

A jailbreak is an attack where an adversary uses adversarial prompting to override a model’s alignment controls — making it produce content or take actions it was trained to refuse. The attacker is present (security), and the output causes harm (safety). One ticket. Two teams. Often neither responds fast enough.

In February 2025, researchers demonstrated a “chain-of-thought jailbreak” affecting models from OpenAI, Google, and Anthropic. By inserting adversarial instructions into a model’s own reasoning trace, they bypassed content filters and induced policy violations — a clean example of one event sitting squarely in the A∩C overlap (Startup House, 2025).

Overlap A and B: the leaked-credential zone

An AI tool that fetches external content and leaks an API key is an AI security incident (the AI was attacked via indirect prompt injection) and a cybersecurity incident (your infrastructure credentials left the building). The Adversa AI 2025 Security Incidents Report documented multiple real cases of agentic workflows being manipulated into exfiltrating credentials — $100K+ losses without a single line of exploit code beyond natural-language prompts (Adversa AI, 2025).

The triple overlap: the gap nobody owns

The most dangerous position is the center — a risk that touches all three cards. Imagine an agent that is jailbroken (A∩C) via an injected document it fetched autonomously (A∩B), and the result is that it calls a billing API with a user’s payment credentials (B∩C). No single team’s runbook covers this. The security team says the model misbehaved. The AI safety team says the model was attacked, not misaligned. The platform team says the agent’s tool grants are a product decision.

Naming the discipline is not pedantry — it is how you assign the incident owner before the incident happens.

How to defend against the gap

Defense here is not a list of technical controls; it is an organisational and architectural posture. Three layers:

1. Name the discipline in your threat model. Before you ship, write one sentence for each card: “The AI security risks on this system are X. The cybersecurity risks introduced by the AI component are Y. The AI safety risks are Z.” If you cannot write all three sentences, you have a blind spot. See How to Threat Model an AI System for the full framework mapping.

2. Assign an owner to each overlap. The A∩C overlap (jailbreak) needs someone who speaks both security and alignment. The A∩B overlap (AI as attack vector into infra) needs your security team to own AI-sourced incidents, not just platform incidents. The triple overlap needs a cross-functional incident response playbook that does not require consensus before acting.

3. Use the right framework for the right question. Each discipline has a primary framework:

Question                          Primary framework
"Can an attacker subvert my AI?"  MITRE ATLAS v5.4 / OWASP LLM Top 10 2025
"Is my AI a new door into infra?" Traditional NIST CSF / zero-trust controls
"Does my AI cause harm by itself?" NIST AI RMF 1.0 / EU AI Act (2026 in force)

Picking the wrong framework for the question you are asking is the most common governance mistake. The next tutorial in this series maps that selection explicitly: How to Threat Model an AI System: ATLAS, OWASP, MAESTRO and NIST.

Common misconceptions

• “AI safety is a research problem, not a shipping problem.” Production models hallucinate, exhibit demographic bias, and make consequential errors today, without any research lab involvement. If your model produces clinical, legal, financial, or safety-critical output, you have an AI safety obligation right now, not after AGI.

• “If I follow OWASP LLM Top 10, I’ve handled AI safety.” OWASP LLM Top 10 2025 covers security vulnerabilities in LLM applications — it is Card A and Card B territory. It does not cover bias, hallucination reliability, or harm from correct model behavior. You need the NIST AI RMF’s trustworthiness characteristics for Card C.

• “Jailbreaking is just a safety issue — my security team doesn’t need to care.” A successful jailbreak that causes the model to call a real API, send a real email, or modify a real database is an incident with blast radius in your infrastructure. It lives in the security-plus-safety overlap. Both teams need a runbook.

• “My model vendor handles cybersecurity; I just handle the application.” The AI component introduces new attack vectors into your stack that your vendor does not control: the prompts you send, the tools you grant, the external content you let the model read. The OWASP Supply Chain entry (LLM03:2025) is your responsibility as the integrator, not the model provider’s.

Frequently asked questions

What is the simplest test for deciding which discipline I’m dealing with? Ask: is there an adversary? If yes and the target is the AI itself, it is AI security. If yes and the AI is being used as a weapon against surrounding systems, it is cybersecurity with an AI vector. If no — the model is just behaving as trained and causing harm — it is AI safety. Many real incidents fail all three tests simultaneously; that is a sign you need all three teams in the room.

Does the EU AI Act address all three disciplines? Partially. The EU AI Act (fully in force from August 2026) focuses primarily on AI safety and transparency — risk classification, conformity assessments, and prohibited uses. It references cybersecurity obligations and security testing for high-risk systems, but it does not replace OWASP or MITRE ATLAS for adversarial threat modeling. Think of it as a governance layer that sits on top of all three cards, not a substitute for any of them.

Why do some companies have separate “AI Safety” and “AI Security” teams, while others have one? Org structure usually follows product maturity and regulatory exposure. Early-stage teams often merge them under a broad “responsible AI” function. At scale — especially in regulated industries or with agentic products — the disciplines diverge too much to share a team: safety needs alignment researchers and ethicists; security needs adversarial engineers and incident responders. The NIST AI RMF’s separate characteristics are a useful argument for splitting them before they split on their own during an incident.

If a model produces a harmful output after a jailbreak, who is liable — the developer or the model vendor? This is an active legal and regulatory question as of 2026, with no settled answer. Most enterprise AI contracts allocate responsibility via acceptable-use policies and indemnification clauses. Practically, liability follows control: if you granted the tool access, wrote the system prompt, and chose to deploy without output guardrails, you own a substantial portion of the blast radius regardless of who trained the model. Defense-in-depth is not just good engineering — it is your liability posture.

How does MITRE ATLAS relate to the traditional MITRE ATT&CK framework? ATT&CK covers adversary tactics and techniques against traditional IT systems (endpoints, networks, cloud). ATLAS extends that taxonomy specifically to AI/ML systems: it maps how attackers target training data, model weights, inference APIs, and agentic pipelines using techniques that have no ATT&CK equivalent — like “Craft Adversarial Data” or “Extract ML Model.” As of v5.4.0 (February 2026), ATLAS includes 84 techniques, many specific to generative AI and agentic attack patterns (MITRE ATLAS, 2026). Use ATT&CK for the B-card (infrastructure); use ATLAS for the A-card (the AI itself).

Where this fits in the series

This tutorial gives you the three-card map you need to orient every subsequent topic in the series. Before diving deeper, make sure you have the underlying attack-surface model: The AI Attack Surface Explained walks the six-stage ML pipeline that all three disciplines operate on.

From here, the natural next step is learning which framework to reach for: How to Threat Model an AI System: ATLAS, OWASP, MAESTRO and NIST maps each framework to a specific discipline and question type.

When you want to go deeper on Card A (AI security), Why AI Is Uniquely Attackable: The Four Properties That Break Security explains the structural properties that make ML systems harder to defend than traditional software.

For the Card C (AI safety) overlap with agents specifically — where a model doing exactly what it is told can still cause harm — see Excessive Agency: When an AI Agent Does Too Much.

Browse all tutorials to follow the full series from orientation through capstone.