SDS.WEB.RESOURCES // GRADUATE GUIDE · VERSION 0.1

A Graduate’s Guide to AI Cybersecurity

This guide is for students, recent graduates, and early-career practitioners exploring AI cybersecurity. That includes security students who have not yet worked with modern AI systems and AI/ML students who have not yet worked in security.

The complete guide is being developed as an educational resource for Cybersecurity Career Week 2026. This version sets out the terrain: what an AI-enabled system is made of, how those systems fail, and what to learn first.

You do not need to be an AI researcher to work in AI cybersecurity. You do need to understand what the system can do, what it is authorized to do, how it can fail, and where those boundaries are enforced.

AI cybersecurity is bigger than the model

Public discussion of AI security tends to focus on the model: whether it can be tricked, jailbroken, or made to say something it should not. Those are real problems, but they are only part of the field. A production AI system is a model connected to many other components. Each component is a security surface with its own failure modes, and many of them existed long before AI.

A deployed AI system commonly includes:

Foundation models
System prompts and instructions
Retrieval systems
Memory
Tools
APIs
Credentials
Plugins and MCP-style integrations
Agent harnesses
Orchestrators
Sandboxes
Execution environments
Logging and observability
Authorization mechanisms
Human approval processes
Other agents

The rest of this guide explains each of these. For now, the point is the boundary: when you assess an AI system, you are assessing all of this, not only the model at the center.

How AI systems fail

The list below shows how wide the field is. Prompt injection is one entry. Most of the others concern authority, delegation, state, dependencies, containment, evidence, and the people operating the system.

Prompt injection
Indirect prompt injection
Malicious tool output
Poisoned retrieval
Memory poisoning
Context poisoning
Authority confusion
Identity confusion
Confused deputy behavior
Privilege escalation
Excessive agency
Over-broad delegation
Stale authorization
Unauthorized persistence
Credential misuse
Cross-agent contamination
Unsafe retries
Runaway recursion
Resource exhaustion
Denial of service
Containment failure
Sandbox escape
Secret leakage
Logging gaps
Unverifiable execution
Evidence tampering
Compromised plugins
Compromised MCP servers
Compromised dependencies
Model substitution
Supply-chain compromise
Goal drift
Instruction collisions
Specification gaming
Deceptive compliance
Automation bias
Human approval fatigue
Irreversible side effects

For documented real-world cases, see the Agentic Security Incident Record. For architectural failure patterns in enterprise agent deployments, see Murphy’s Guide to Enterprise Agentic Architecture.

Five distinctions to keep

Many AI security failures come from treating two different things as the same. These distinctions recur throughout the field.

Capability is not authority.: A system being technically able to perform an action does not mean it is permitted to perform it.
Identity is not authority.: Knowing which user, agent, service, or process is acting does not settle whether the requested action is allowed.
Observability is not enforcement.: Being able to detect or reconstruct an action afterward does not mean the action was controlled when it happened.
Model behavior is not system behavior.: A security conclusion about the model alone does not automatically hold for the deployed system built around it.
Governance is not only policy documentation.: Once a system can take consequential action, governance has to show up in implementation: authorization, enforcement, evidence, and operational control.

What to learn

If you come from security, most of what you know still applies. If you come from AI/ML, you already understand the model; the next step is understanding the system around it.

A / TRANSFERS DIRECTLY

Security skills you already need

Most of the work is still security work. These skills carry over with little translation.

Traditional cybersecurity fundamentals: Threat modeling, trust boundaries, least privilege, defense in depth.
Identity and access management: Agents and services are principals too. Each needs an identity and scoped credentials.
Authorization and delegation: Who granted this action, with what limits, and does that grant still hold right now?
Application security: Untrusted input still flows into code paths. Some of that input is now natural language.
Cloud and infrastructure security: AI workloads run on the same networks, storage, and secrets stores as everything else.
Software supply-chain security: Models, packages, plugins, and tool servers are all dependencies, with provenance to check.
Logging, monitoring, and incident response: You need to be able to reconstruct what an automated system did, and why.

B / NEW WITH AI SYSTEMS

What you need to learn about AI

You do not need to train models. You do need to understand how they are assembled into systems.

Basic AI/ML system architecture: What a model call is, what goes into its context, and what comes back.
Retrieval and memory systems: How stored or retrieved content enters a model’s context, and who controls that content.
Agent architecture and tool use: How model output becomes a tool call, and how a tool call becomes a real-world effect.

C / WHERE THEY MEET

Controls for systems that act

These areas sit between the two. They are where much of the open engineering work is.

Runtime containment: Limiting what an agent can reach while it runs, and stopping it cleanly when needed.
Human-in-the-loop control: Designing approval steps that people can actually evaluate, not just click through.
Evidence and auditability: Records that show what was authorized and what was executed, and that cannot be quietly altered.

VERSION 0.1 · OCTOBER 2026

This page will be expanded at this address. Later versions add explanations and examples for each failure mode, a closer look at identity, authority, and execution in agent systems, career roles in the field, a suggested learning path, and further reading.

Published independently by Shadow Dynamic Systems. Questions and suggestions are welcome through the contact page.