Skip to content
AI Security
The AI security curriculum

Build your AI
security judgment.

Follow the mechanisms from identity and operating systems to models and agents. Study a diagram, test a decision, then explain the reasoning behind it.

147 lessons17 topics87 open to everyone
Browse the lessons Choose a starting route
Explore the curriculum

Learn a topic in order, or find the concept you need today.

147 lessons · 17 topics
Topic 01 / 6 lessons

Security Foundations

Learn to see a system the way an attacker does: what is worth taking, who can reach it, where trust changes hands, and which control fails first.
  1. 01

    Trust Boundaries, Assets and Adversaries

    Security reasoning starts with three questions: what is worth protecting, who could want it and with what ability, and where data or control crosses from one level of trust to another. A trust boundary marks a change in authority or trust. Reviewing the checks at those crossings helps explain failures such as SQL injection and prompt injection.    Free
  2. 02

    Confidentiality, Integrity, Availability and Authenticity

    Security controls exist to protect a small set of properties: confidentiality (only the right parties can read), integrity (nothing changes without authority), availability (the system works when needed) and authenticity (you know who or what you are dealing with). Naming the property a control protects is the fastest way to see what it does not protect, and AI systems put new pressure on every one of them.    Free
  3. 03

    Threat Modeling with Data-Flow Diagrams and STRIDE

    Threat modeling is a structured way to find what can go wrong in a design before it is built. Draw a data-flow diagram, mark the trust boundaries, and walk each element through STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. The output is a list of specific threats, each with a decision: mitigate, accept, transfer or remove the feature.    Free
  4. 04

    Least Privilege, Defence in Depth and Fail-Safe Defaults

    Three design principles do most of the work in secure architecture. Least privilege limits what any one component, person or agent can do, so a compromise stays small. Defence in depth layers controls that fail independently, so another control may still block the path when one fails. Fail-safe defaults deny access unless something explicitly allows it. Use them to identify which consequences remain possible after a component is compromised.
  5. 05

    Threat Modeling AI Systems

    Threat modeling an LLM application uses the same data-flow diagram and STRIDE walk as any system, with new elements drawn in: the context assembler, retrieval stores, the tool layer, memory, and the model and its supply chain. Two adjustments make it work. Annotate every input to the context with its author, because any author can steer the model. And classify every control as deterministic or probabilistic, because only deterministic controls can carry a boundary.    Premium
  6. 06

    Modern Security Platforms: Code, Cloud and Security Operations

    Navigate ASPM, CNAPP, CSPM, CIEM, DSPM, CWPP, CDR, EDR/XDR, SIEM and SOAR by the evidence and controls they provide. Follow dated vendor examples into concepts, worked questions and three applied courses.    Free
Topic 02 / 9 lessons

Systems & OS Security

How the kernel keeps processes apart, how privilege is granted and escalated on Linux and Windows, why memory bugs become code execution, and how to read a binary with a question in mind.
  1. 01

    How the Kernel Isolates Processes

    The CPU runs applications in an unprivileged mode and the kernel in a privileged one. Each process gets its own virtual address space through page tables only the kernel can change, plus credentials and handles the kernel checks on every request. Programs reach privileged operations only through system calls, where the kernel must treat every argument as hostile. Isolation is deliberately relaxed through debugging interfaces, shared memory and IPC, and it collapses entirely if the kernel itself is exploited, which is why containers sharing one kernel are a weaker boundary than virtual machines.    Free
  2. 02

    Secure Boot, Measured Boot and Remote Attestation in Depth

    Secure boot enforces: each stage runs the next only if it is signed and not revoked. Measured boot records: each stage extends a hash into a TPM register, blocking nothing by itself. Attestation proves that record to a remote verifier with a fresh nonce. A patched but still-signed boot component stays usable until it is revoked, which is why BlackLotus worked. PCR values break on every update, so policies use event logs or signatures. Confidential AI uses the same chain to release model weights only to attested machines.
  3. 03

    The Linux Privilege Model: Permissions, setuid, Capabilities and MAC

    Linux decides what a process may do in layers. Discretionary permissions (owner, group, others, plus ACLs) are set by the owner of each file. setuid and setgid executables run with their owner's identity, which makes every one an escalation surface. Capabilities split root into about forty separately grantable powers, some of which are nearly root on their own. Mandatory access control (SELinux, AppArmor) adds a system-wide policy no process can change. Hardening a service means working through all four layers, not just making sure it is not UID 0.    Free
  4. 04

    Linux Sandboxing Primitives: Namespaces, cgroups, seccomp and Landlock

    Linux has no single sandbox feature. Containers and sandboxes combine primitives that each answer a different question: namespaces decide what a process can see, cgroups how much it can use, capabilities which root powers remain, Landlock or a security module which files and ports it may touch, and seccomp which system calls it may make. no_new_privs ties them together by stopping privilege gain through exec. They must be applied in the right order, and all of them are enforced by one shared kernel, so they harden a process but do not isolate hostile code from a kernel bug.
  5. 05

    Memory Corruption and the Mitigations Against It

    Memory-safety bugs are spatial (out-of-bounds writes and reads) or temporal (use-after-free, double free, uninitialised use). They become code execution when corrupted memory holds control data or security decisions. Mitigations each block one step: stack canaries detect stack overwrites, non-executable memory forces code reuse, ASLR hides addresses until something leaks, control-flow integrity and shadow stacks restrict where execution can go. None removes the bug, and data-only attacks sidestep the control-flow defences, so the durable answer is memory-safe code for anything that parses untrusted input.    Free
  6. 06

    Windows and Active Directory Security for Interviews

    Windows decides access by comparing a process's access token (user and group SIDs, privileges, integrity level) with an object's security descriptor. Privileges such as SeImpersonate and SeDebug bypass object permissions and are often the real escalation. Active Directory authenticates with Kerberos: tickets protected by the krbtgt key and by service account keys, which is why weak service passwords can be cracked offline and a stolen krbtgt key forges anything. Most domain compromises use credentials cached where admins logged on, so tiering, LAPS, Credential Guard and gMSAs are the core defences.
  7. 07

    Active Directory Attack Paths and How Tiering Breaks Them

    Active Directory compromises usually follow a path: a phished user, a shared local administrator password, a privileged credential cached on a workstation, a relayable authentication or a misconfigured certificate template, and then control of the domain. Each step is an edge in a graph, and defence means removing edges: Windows LAPS for unique local passwords, Protected Users and Credential Guard for privileged credentials, signing, channel binding and EPA against NTLM relay, careful AD CS templates, and an administrative model in which higher planes are never controlled from lower ones.    Premium
  8. 08

    Reverse Engineering as a Security Method

    Security reverse engineering answers a specific question about software you are authorised to analyse: where a secret goes, what a check protects, what a binary does on load. Static analysis (formats, imports, strings, disassembly, decompilation) shows all paths but can be misled by packing and obfuscation; dynamic analysis (debuggers and instrumentation in an isolated environment) shows real behaviour on exercised paths. Good analysts alternate between the two, treat decompiler output as a hypothesis, and report findings by the strength of their evidence, separating a modified local check from demonstrated impact on a server or another user.
  9. 09

    Software Protection and Its Limits

    On a device the attacker controls, every check can be observed, hooked or patched. Obfuscation hides structure and constants until run time; anti-debugging and anti-tamper detect analysis and modification; guard networks make checks protect each other. Each is defeated by observing the program when it must reveal behaviour or by changing the code that checks. Their value is economic: higher cost per attack, detection at scale and time between releases. Security decisions and secrets belong on the server, backed by attestation and authorisation, so removing client protections gains an attacker nothing important.
Topic 03 / 8 lessons

Network Security

Where an attacker can sit between two machines, what that position buys them, and the authentication and segmentation that make it worthless.
  1. 01

    Attacker Positions on the Network

    Network attacks are best understood by the attacker's position: on the local link (ARP spoofing, rogue DHCP, evil-twin Wi-Fi), in name resolution (DNS spoofing, resolver compromise, registrar takeover), in routing (BGP hijacks and leaks), or as a trusted intermediary (an interception proxy or an installed root). Each position lets the attacker read or alter traffic that is not protected end to end. TLS with proper certificate validation defeats all of them unless the attacker can make the client trust their certificate, which is why the strongest network defences are authentication, plus controls that stop the attacker getting into position.    Free
  2. 02

    DNS Security: Resolution, Poisoning, DNSSEC and Encrypted DNS

    DNS resolution passes through a stub resolver, a recursive resolver and a chain of authoritative servers, with caching at each step. Attacks target each part: forged responses that poison caches, malicious or compromised resolvers, takeovers of registrar and DNS-provider accounts, and dangling records that allow subdomain takeover. DNSSEC signs records so validating resolvers can detect forgery but provides no confidentiality; DNS over TLS and HTTPS encrypt the client-to-resolver hop but trust the resolver. TLS certificate validation remains the backstop when DNS lies.    Free
  3. 03

    Trust on the Wire: HSTS, Certificate Transparency, Pinning and Interception

    TLS protects traffic only when the client correctly decides to trust the server's certificate. HSTS stops browsers downgrading to HTTP or letting users click through warnings; Certificate Transparency makes mis-issued certificates visible; CAA records restrict which CAs may issue for a domain; pinning narrows trusted keys for clients you control; and interception proxies deliberately insert a private root, creating a new trusted point with its own risks. Operating these well means automated certificate management, staged rotation, monitoring, and knowing which failures are attacks and which are configuration.
  4. 04

    Segmentation and Egress Control

    Network controls matter most after initial compromise. Segmentation divides the network into zones with explicit, default-deny flows between them, from coarse zones (users, servers, management, sensitive data) to per-workload microsegmentation keyed on workload identity. Egress control limits outbound connections to what each system needs, breaking command-and-control, tool downloads, exfiltration and SSRF. Both are designed from observed flows, rolled out in monitor mode, kept as code with owners, and turned into detection by alerting on denied traffic.
  5. 05

    How Tunnels and VPNs Work

    A tunnel carries one packet inside another; a VPN adds authentication and encryption so the inner packet crosses untrusted networks safely. IPsec negotiates keys with IKE and protects packets with ESP; WireGuard binds static public keys to allowed address ranges with a one-round-trip handshake; TLS VPNs ride over port 443. All of them authenticate who connected and then deliver packets onto a network, so what a client can reach is decided by policy behind the gateway. Leaks (DNS, IPv6, local routes), gateway vulnerabilities and broad post-connect access are where real failures happen.
  6. 06

    TCP/IP for Security Engineers

    IP does not authenticate source addresses, so spoofing is possible wherever networks skip ingress filtering, and spoofed UDP becomes reflection and amplification. TCP's handshake and sequence numbers stop an off-path attacker from blindly injecting data, but only probabilistically, and side channels have repeatedly narrowed the odds. Neither layer offers confidentiality or integrity against anyone on the path. Security engineers need these limits to reason about SYN floods, blind resets, off-path DNS poisoning and why every channel worth protecting needs TLS or another authenticated layer above.    Free
  7. 07

    Wi-Fi Security and 802.1X

    WPA2-Personal derives keys from a shared passphrase, so a captured handshake can be attacked offline; WPA3-Personal's SAE handshake removes that, though its transition mode and early implementations had flaws. KRACK showed that even WPA2's key handshake could be made to reuse nonces. Enterprise Wi-Fi uses 802.1X with EAP and a RADIUS server, and its security depends on clients validating the server's certificate and name: without that, an evil twin collects credentials. Certificate-based EAP-TLS with a private CA, WPA3 with protected management frames, and the same controls on wired ports are the current baseline.    Free
  8. 08

    External Exposure Management and Asset Attribution

    External exposure management discovers reachable assets and connects them to ownership and business impact. Separate an observed internet service from a verified vulnerability and an authorized test target.    Free
Topic 04 / 7 lessons

Cryptography & PKI

What each primitive guarantees and what it does not, how TLS and certificates build trust across the internet, and how keys are kept safe.
  1. 01

    Hashes, MACs and Digital Signatures

    A hash turns any input into a fixed fingerprint, but anyone can recompute it, so it proves nothing on its own. A MAC adds a shared secret key, so only key holders can produce a valid tag. A digital signature uses a private key that only the signer holds and a public key anyone can use to verify, which adds non-repudiation. Choosing between them is a question of who holds which key.    Free
  2. 02

    Symmetric Encryption and AEAD

    Symmetric encryption uses one secret key to encrypt and decrypt. On its own it hides content but does not detect tampering, which has caused real attacks. Authenticated encryption with associated data (AEAD), such as AES-GCM or ChaCha20-Poly1305, encrypts and attaches a tag that makes any modification fail to decrypt. Its one hard rule is that a nonce must never repeat under the same key.    Free
  3. 03

    Public-Key Cryptography and Key Exchange

    Public-key cryptography gives each party a key pair: a public key that can be shared and a private key that never leaves its owner. It enables signatures and key exchange, which lets two parties who have never met agree on a shared secret over an observed network. Protocols use it to set up a session and then switch to fast symmetric encryption. Its weak point is knowing whose public key you have, and its long-term threat is quantum computing.
  4. 04

    How TLS 1.3 Works

    TLS 1.3 sets up an encrypted, authenticated connection in one round trip. The client and server run an ephemeral Diffie-Hellman exchange to agree on fresh keys, the server proves its identity by signing the handshake with the private key behind its certificate, and both sides confirm with a MAC over everything exchanged. After that, data flows under AEAD encryption. TLS protects data in transit between two endpoints; it does not protect the endpoints, the data at rest, or decide who is allowed to do what.    Free
  5. 05

    PKI and Certificate Chains

    Public key infrastructure answers the question signatures leave open: how do you know a public key belongs to who it claims? A certificate binds a name to a public key and is signed by a certificate authority. Clients trust a small set of root authorities and validate a chain from the server's certificate up to one of them, checking signatures, dates, names and constraints at each step. Certificate Transparency logs make mis-issued certificates detectable.    Free
  6. 06

    Certificate Revocation and Certificate Transparency in Depth

    Revocation tells clients to stop trusting a certificate before it expires; Certificate Transparency makes every publicly trusted certificate visible. In 2026 browsers do not ask CAs online: Firefox checks a local CRLite filter covering all revocations, Chrome uses a small CRLSet, and many non-browser clients check nothing, so lifetime is often the real limit. CT logs are Merkle trees: an inclusion proof for a two-billion-entry log is 31 hashes. Monitors and witnesses make logs honest, and CT has exposed mis-issuance repeatedly, but only when someone watches.    Free
  7. 07

    Hardware Roots of Trust and Key Custody

    TPMs support platform identity and measured boot; TEEs, secure enclaves and HSMs can protect non-exportable keys and enforce usage policies. Their guarantees depend on the hardware, configuration and attacker access. Separate resistance to key extraction from authority to use a key. Add narrow caller permissions, authentication or approval where needed, and operation logs. Attestation lets a verifier evaluate key provenance and measured platform state against policy.
Topic 05 / 12 lessons

Identity & Access

Who is asking, on whose behalf, and with what authority: sessions, OAuth and OIDC, tokens, workload identity, and authorization that still holds when the caller is an agent.
  1. 01

    Authentication versus Authorization

    Authentication establishes who a caller is: a user, a service or an agent acting for someone. Authorization decides what that caller may do with a specific resource right now. They are separate checks that fail in separate ways. Most real access-control bugs are authorization failures on authenticated requests, and AI agents add a third question: on whose behalf is this action being taken?    Free
  2. 02

    Access-Control Models: RBAC, ABAC and ReBAC in Depth

    Every authorization model answers one question: may this subject perform this action on this resource, in this context? RBAC answers with roles and is easy to review but explodes when roles start encoding objects or context. ABAC evaluates attributes and is expressive but hard to audit. ReBAC follows relationships such as owner, member and parent folder, as Google's Zanzibar does at millions of checks per second. Real systems combine them, and the hard parts are deny semantics, list filtering, stale permissions and agents acting for users.    Free
  3. 03

    Sessions, Cookies and Tokens

    A session links later requests to authenticated state. Compare opaque identifiers, signed tokens, cookie protections and sender constraints, then test idle expiry, absolute expiry and revocation across caches and accepting services.    Free
  4. 04

    OAuth 2.0 and PKCE

    OAuth 2.0 is a framework for delegated authorization: a user lets an application access a resource on their behalf, with limited scopes, without sharing their password. The authorization code flow sends the user to the authorization server, returns a short-lived code, and exchanges it for tokens. PKCE binds code redemption to a per-flow verifier: someone who steals only the code cannot redeem it. This is not proof of an installed app's identity. Current best practice uses the code flow with PKCE for every client type.    Free
  5. 05

    OpenID Connect and ID Tokens

    OpenID Connect is an identity layer on top of OAuth 2.0. Alongside an access token for APIs, it returns an ID token: a signed JWT stating who the user is, who issued the statement, which client it is for, and when it expires. The client validates it and creates its own session. Confusing ID tokens with access tokens, or skipping audience and nonce checks, are the classic mistakes.
  6. 06

    The Confused Deputy

    A confused deputy is a program that holds authority and is tricked into using it on behalf of a less privileged party. The problem was named in 1988 and reappears in OAuth proxies, cloud services that act for customers, and, most sharply, in AI agents: a model holding a user's or a service's credentials can be steered by text from anyone. The fix is to make each action carry the authority of the party that requested it, not the deputy's own.    Free
  7. 07

    Validating JWTs Safely

    A JSON Web Token is a signed (sometimes encrypted) set of claims, whose safety depends on explicit verifier policy. Safe validation pins the allowed algorithm to each key, selects keys only from the configured issuer's key set, checks the token type, issuer, audience and time claims, treats header fields such as kid and jku as untrusted input, and keeps different token kinds mutually exclusive. Key rotation needs a schedule that accounts for cache lifetimes, token lifetimes and clock leeway.    Premium
  8. 08

    Sender-Constrained Tokens: DPoP, mTLS and Token Exchange

    A bearer token is honoured for whoever presents it, so a leaked token is a working credential. Sender-constrained tokens carry a confirmation claim naming a key, and the resource server checks that the caller proves possession: DPoP with a signed proof per request, mTLS with the client certificate on the connection. Binding stops replay of an exfiltrated token; it does not stop code that runs where the key is, or a forged token. Token exchange (RFC 8693) issues each hop a new, narrower, audience-bound token instead of passing one along.    Premium
  9. 09

    Passkeys, WebAuthn and Phishing Resistance

    A passkey is a WebAuthn credential: a key pair whose private key stays in an authenticator and whose public key the website stores. To log in, the authenticator signs a fresh challenge together with data the browser fills in, including the site's origin, and the credential only works for the relying party ID it was created for. A look-alike domain cannot obtain a usable assertion, unlike with one-time codes or push prompts. Synced passkeys are convenient and meet NIST AAL2; device-bound keys are needed for AAL3. Recovery, fallbacks and stolen sessions remain separate problems.    Free
  10. 10

    Workload Identity and SPIFFE: Identity for Services, Pipelines and Agents

    Services, CI jobs and AI agents have traditionally used long-lived stored keys, which leak and outlive their purpose. Workload identity replaces them with short-lived credentials issued after the platform attests what the workload is: Kubernetes projected tokens, OIDC tokens from CI exchanged for cloud credentials, and SPIFFE identities with X.509 or JWT documents for service-to-service mutual TLS. The design questions are which claims a trust policy pins, how attestation roots the chain, and remembering that identity is not authorization: every service still needs policy on what each identity may do.
  11. 11

    Delegated Authorization for AI Agents

    An AI agent acting for a user needs two identities at once: its own, to prove which software is acting, and the user's delegated authority, to decide what it may do. The standard pattern exchanges the user's token at each hop for a new token (OAuth token exchange, RFC 8693) that names the user as subject and the agent as actor, is bound to one audience, narrowed to the task with rich authorization details, bound to the agent's key, and expires in minutes. Resource servers still check ownership against their own data, and high-risk steps get out-of-band user approval bound to the exact action.    Premium
  12. 12

    Cloud Infrastructure Entitlement Management: Effective Permissions

    CIEM maps who can do what across cloud resources and trust relationships. Review effective permissions, unused access and conditional grants without treating permission analysis as proof of runtime activity.    Free
Topic 06 / 11 lessons

Application Security

Review application trust boundaries, then connect code-scanning findings to deployed services and repair owners through ASPM.
  1. 01

    Injection Vulnerabilities

    Injection happens when data from an untrusted source is combined with code for an interpreter, such as a SQL engine, a shell or a template engine, and the interpreter treats part of the data as instructions. The structural fix is to keep code and data in separate channels: parameterised queries, argument arrays instead of shell strings, sandboxed templates. Prompt injection is the same failure in an interpreter that offers no separate channel, which is why its defences look different.    Free
  2. 02

    Cross-Site Scripting and Output Encoding

    Cross-site scripting (XSS) is injection into a browser: attacker-controlled content ends up in a page as executable script, running with the site's origin and the victim's session. It comes in stored, reflected and DOM-based forms. The fixes are contextual output encoding (frameworks do this by default), sanitisation when HTML must be rendered, and a strict Content Security Policy as a second layer. Chat interfaces that render model output as HTML or Markdown are a new and common source.    Free
  3. 03

    Content Security Policy in Depth

    A Content Security Policy is a response header the browser enforces for one document: it decides which scripts, styles, frames and connections the page may use, blocks the rest and can report violations. Host allowlists failed in practice because allowed domains host code an attacker can reuse. A strict policy trusts scripts by per-response nonce or by hash, propagates trust with strict-dynamic, and adds object-src and base-uri. Trusted Types closes DOM sinks. CSP limits XSS impact; it does not fix XSS or stop data leaving.
  4. 04

    Server-Side Request Forgery

    Server-side request forgery (SSRF) happens when an application fetches a URL that an attacker can influence, letting the attacker use the server's network position to reach internal services, cloud metadata endpoints and admin interfaces. String checks on URLs are easy to bypass. Robust defences validate the resolved IP address, connect to that exact address, re-check redirects, prefer allowlists, and route outbound fetches through an egress proxy. LLM tools that fetch web pages are SSRF primitives by design.    Free
  5. 05

    Broken Access Control and IDOR

    Broken access control covers every way a user acts outside their intended permissions: reading other users' objects by changing an ID (IDOR, or broken object-level authorization), calling privileged functions directly, changing fields they should not (mass assignment), or crossing tenant boundaries. It tops both the OWASP web and API risk lists because authorization must be correct on every endpoint. Central policy, object-level checks in the data layer and two-user tests prevent most of it.
  6. 06

    Insecure Deserialization

    Deserialization turns bytes back into objects. Formats that can describe arbitrary objects, such as Python pickle, Java native serialization and unsafe YAML loaders, can be made to call functions during loading, so untrusted input becomes code execution. The fix is to never deserialize untrusted data with such formats: use data-only formats like JSON, safe loaders, schemas, and for machine learning, safetensors instead of pickle-based checkpoints. Signing proves origin, not safety.
  7. 07

    How Browsers Separate Origins: SOP, CORS and CSRF

    The same-origin policy lets a page send requests almost anywhere but stops its script reading responses from other origins. CORS is the server's way to relax that read restriction for chosen origins; it never stops a request being sent. CSRF is the attack that exploits sending: a cross-site page makes the victim's browser submit a request with the victim's cookies. The defences are separate: exact CORS allowlists for reads, and for writes a CSRF token, Fetch Metadata checks, strict content types and SameSite cookies as defence in depth.    Premium
  8. 08

    HTTP/2, HTTP/3 and Request Smuggling

    Request smuggling happens when a front-end and a back-end parse the boundaries of HTTP/1.1 requests differently, so bytes an attacker sends are treated as the start of the next request on a shared connection. HTTP/2 and HTTP/3 use binary framing that removes that ambiguity, but proxies that accept HTTP/2 and forward HTTP/1.1 reintroduce it, and the new protocols bring their own denial-of-service classes, such as Rapid Reset, which drove record attack rates in 2023. Defences are strict parsing that rejects ambiguous framing, HTTP/2 end to end, per-connection budgets for resets and headers, and care with QUIC's 0-RTT and visibility.    Premium
  9. 09

    AI Vulnerability Discovery and Remediation

    AI systems such as Google's Big Sleep and CodeMender, Anthropic's Mythos-class models, OpenAI's Codex Security and Microsoft's MDASH find vulnerabilities by ranking code, forming specific hypotheses and confirming them with an oracle (a sanitizer crash, a proof of concept, a failing test), then propose patches that must be validated beyond the scanner: the trigger stops, tests pass, fuzzing stays clean and a human confirms the root cause. Results are strongest for memory-safety bugs, weakest for logic and authorisation, and the bottleneck has moved from finding bugs to verifying, disclosing and fixing them.    Free
  10. 10

    Application Security Posture Management: From Findings to Owners

    ASPM connects repositories, builds, deployed services and owners so scanner findings can become verified repairs. Learn correlation keys, coverage gaps, exception expiry and how OX Security, Cycode and Apiiro approach the problem.    Free
  11. 11

    Code Scanning: What SAST, DAST and SCA Actually Observe

    Compare source analysis, dependency analysis and authorized dynamic testing by their inputs and blind spots. A useful result names the revision, scope, rule set and evidence behind the finding.    Free
Topic 07 / 6 lessons

Mobile Security

What the phone's sandbox protects and what it does not, how apps store secrets and talk to each other, and why every decision that matters ends up on the server.
  1. 01

    The Mobile Platform Security Model

    Android and iOS both isolate each app in a sandbox, identify apps by their signatures, gate sensitive resources behind permissions or entitlements, and offer hardware-backed key storage. Android isolates apps with per-app Linux user IDs and SELinux and allows sideloading and vendor-controlled updates; iOS uses a kernel-enforced sandbox profile, mandatory code signing and central distribution. Both models protect apps from other apps, not from a device owner with root or a jailbreak, which is why mobile security designs keep authoritative decisions on the server.    Free
  2. 02

    Protecting Data on Mobile Devices

    Mobile apps protect data by storing as little as possible, keeping keys in the Android Keystore or iOS Keychain and Secure Enclave, encrypting what must persist with those keys, and choosing protection classes that keep secrets out of backups and inaccessible while the device is locked. Hardware backing stops keys being copied off the device, but not their use by a compromised app. Most real leaks bypass storage entirely: logs, crash reports, analytics SDKs, backups, app-switcher screenshots, the clipboard, keyboard caches, URLs and notifications.    Free
  3. 03

    Mobile IPC, Deep Links and WebViews as Attack Surface

    Mobile apps expose entry points that other apps and web pages can reach: Android activities, services, receivers and content providers; deep links and custom URL schemes on both platforms; and WebViews with JavaScript bridges into native code. Each is an API with an untrusted caller. Typical bugs are missing authorization on exported components, intent redirection where the app forwards attacker intents with its own identity, content-provider path traversal, custom schemes claimed by malicious apps to steal OAuth codes, deep links that perform actions without confirmation, and WebView bridges reachable from untrusted pages. Fixes are the API-security basics applied on the phone: minimal exposure, verified identity, validated input and explicit confirmation.
  4. 04

    WebView Security: A Browser With Your App's Identity

    A WebView is a browser engine inside an app, with no address bar and whatever powers the app adds. Most WebView bugs come from three choices: a JavaScript bridge exposed to every frame, file and content access that let a page read local data, and loading content the app does not control, such as deep-link URLs and model-generated HTML. The defences: separate trusted and untrusted content, give local files a real origin, use origin-restricted message channels, and send external links and login to the system browser.    Premium
  5. 05

    Signing In From a Mobile App: OAuth for Native Apps

    A mobile app cannot keep a client secret, so OAuth treats it as a public client. RFC 8252 sets the pattern: run the login in the system browser or a platform authentication session, never an embedded WebView; receive the code on a redirect the OS verifies, such as an App Link or universal link; and protect the code with PKCE using S256. RFC 9700 adds that public clients must use PKCE and that their refresh tokens must be rotated or bound to a key, which on a phone can live in secure hardware.
  6. 06

    Trusting a Mobile Client: Pinning, Tamper Detection and Attestation

    Mobile client controls have different trust assumptions. Pinning narrows accepted TLS keys on an uncompromised client; root detection and anti-tamper checks raise effort but can be modified by an attacker who controls the app. Play Integrity and App Attest provide evidence that the server can verify and bind to an action, using different protocols. Good designs check request binding and freshness, combine attestation with fraud signals, and enforce authorization on the server. Hardware-backed keys and platform isolation remain useful within their own threat models.
Topic 08 / 13 lessons

Infrastructure Security

Cloud posture, sensitive data, workload sensors and container controls, connected to the identities and resources underneath AI services.
  1. 01

    What Containers Isolate, and What They Do Not

    Containers isolate processes using Linux namespaces, cgroups, capabilities, seccomp and security modules, but every container on a host shares one kernel. A kernel bug or a misconfiguration such as a privileged container, a mounted container runtime socket or a broad host mount lets code escape to the host. For untrusted code, including code written or run by AI agents, stronger boundaries such as gVisor's user-space kernel or Firecracker and Kata microVMs put a much smaller or separate kernel between the workload and the host.    Free
  2. 02

    Sandboxing Untrusted Code

    Agents that write and run code, notebooks that execute model output, and platforms that run customer code all execute code nobody reviewed. A sandbox makes that safe by combining a strong isolation boundary with an environment that has nothing valuable in it: no credentials, minimal files, no network or tightly allowlisted egress, resource and time limits, and disposal after use. Isolation answers whether code can escape; the environment answers what it can do without escaping.    Free
  3. 03

    Cloud IAM and Privilege Escalation Paths

    Cloud identity and access management decides what every user, service and workload can do, so it is the real perimeter of a cloud environment. Privilege escalation happens when a principal can use its permissions to gain more: attaching policies to itself, passing a powerful role to a resource it creates, changing code that runs under another role, or minting credentials. ML platforms are full of such paths because training and notebook roles are often broad. Least privilege, permission boundaries, organisation-level guardrails and path analysis keep them closed.
  4. 04

    Protecting Model Weights

    Trained model weights can represent enormous investment and, for the most capable models, real misuse risk if stolen. Theft needs only one successful copy, through compromised credentials, insiders, supply chain attacks, exposed storage or the serving infrastructure itself. Protection combines limiting where weights exist and who can access them, strong identity and encryption with tightly controlled keys, monitored and restricted egress, hardened serving, and insider-risk controls. RAND's 2024 study frames the problem as security levels matched to increasingly capable attackers.    Free
  5. 05

    The Inference Stack as Attack Surface

    An LLM inference service is a stack of components that all handle untrusted input: an API gateway, authentication and quotas, request and prompt processing, tokenizers, the model server, GPU drivers, caches, logging, and the management plane. Each layer has classic risks such as parsing bugs, exposed dashboards and broken tenancy, plus AI-specific ones: cost exhaustion, model extraction through the API, prompt leakage through shared caches, and data retained in logs. Threat-modeling the stack layer by layer turns 'secure the model' into concrete controls.    Premium
  6. 06

    Self-Hosted Inference Servers: A Secure Reference Deployment

    Teams increasingly run their own model servers, such as Ollama, vLLM, Triton, Ray Serve and llama.cpp. Most were designed for trusted networks: some have no authentication by default, expose model management next to inference, and rely on internal channels that deserialise data. Vulnerabilities and exposed servers followed. A secure deployment binds servers to loopback or a private segment behind an authenticating proxy, separates admin endpoints from inference, loads models only from an internal registry by digest, gives nodes no unnecessary cloud identity or egress and patches on a schedule.
  7. 07

    Multi-Tenant Inference Isolation: Caches, Batches, GPUs and Side Channels

    Serving models cheaply means sharing: prompt caches, response caches, batches, adapters, GPUs and network paths. Each shared resource leaks wherever it is keyed by something coarser than the trust boundary. Researchers found providers sharing prompt caches across customers, recovered prompts from scheduling order, read GPU memory left by other processes, and inferred chat topics from encrypted packet sizes. Scope every cache by a server-derived tenant key, pick GPU sharing modes by isolation guarantee, pad streams, and remember confidential computing removes the operator, not co-tenants.    Premium
  8. 08

    Infrastructure as Code Scanning and Runtime Drift

    IaC scanning checks intended infrastructure before deployment. Connect source templates, resolved plans and cloud observations so policy checks catch unknown values, exceptions and changes made outside the pipeline.    Free
  9. 09

    Cloud Security Posture Management and Public Exposure

    CSPM compares observed cloud configuration with policy. Understand public exposure as a reachable path through network and identity controls, and verify that a remediation removes every relevant path.    Free
  10. 10

    CNAPP: Connecting Cloud Posture, Workloads and Code

    A CNAPP combines cloud security capabilities with different evidence sources and enforcement points. Evaluate CSPM, CIEM, workload scanning and runtime controls by their actual scope, freshness and response authority.    Free
  11. 11

    Data Security Posture Management: Discover, Classify, Assess

    DSPM connects sensitive-data discovery and classification to access and exposure. Learn coverage limits, sampling uncertainty and how Cyera, Sentra, Rubrik/Laminar and IBM/Polar fit the data-security workflow.    Free
  12. 12

    CWPP and Runtime Sensors: Observation Versus Enforcement

    Cloud workload protection combines assessment and runtime controls for hosts and containers. Understand sensor health, eBPF collection, supported enforcement hooks and the difference between an alert and a prevented effect.    Free
  13. 13

    Container and Kubernetes Security Across the Workload Lifecycle

    Connect image assessment, admission policy, workload identity and runtime evidence. Learn why a clean image cannot compensate for a privileged pod, and why deployment controls need runtime verification.    Free
Topic 09 / 10 lessons

Supply Chain Security

Trace source, dependencies and model artifacts through builds and deployments. Bound pipeline authority and verify secret and dependency repairs.
  1. 01

    How Code Signing Works

    Code signing attaches a digital signature to software so that anyone installing it can verify two things: that it has not been modified since it was signed, and which key signed it, usually tied to a publisher by a certificate. Operating systems, app stores and package managers check these signatures before running code. Code signing does not prove the code is safe: a compromised build signs malware perfectly, and a stolen key lets attackers sign as the publisher. Key protection, timestamping and build integrity carry the real weight.    Free
  2. 02

    Sigstore and Keyless Signing

    Sigstore is an open-source signing system that replaces long-lived signing keys with short-lived certificates bound to an identity, such as a developer's email or a CI workflow, proven through OpenID Connect. Every signing event is recorded in a public, append-only transparency log. Verifiers check not just a signature but who signed and that the event was logged. It is used for container images, npm and PyPI packages, and model signing.    Free
  3. 03

    Unsafe Model Files: Pickle versus Safetensors

    Many machine-learning checkpoints have been saved with Python's pickle, a format whose loader can execute code chosen by the file's author, so loading an untrusted model can compromise the machine. Safetensors stores only tensors and a small JSON header, so loading cannot run code. It fixes that one problem: it does not detect backdoored weights, malicious custom code shipped alongside a model, or poisoned training. A safe model intake process combines safe formats, restricted loaders, scanning, provenance and isolation.    Free
  4. 04

    Package Ecosystem Attacks: npm, PyPI and Beyond

    Installing a package means trusting its maintainers, their accounts, their build pipeline and the registry. Attackers abuse each link: look-alike names, private names shadowed by public ones, phished maintainers, poisoned CI that publishes with valid provenance, and worms that steal tokens and republish. Most modern payloads target CI secrets. Effective controls are layered: one index or scoped registries, lockfiles with hashes, blocked install scripts, release cooldowns, behavioural malware detection and CI jobs that never hold secrets while installing.
  5. 05

    SLSA and Build Provenance

    Build provenance is a signed, machine-readable statement of how an artifact was produced: which source revision, which build platform and process, and with which inputs. SLSA (Supply-chain Levels for Software Artifacts) defines levels of assurance for that provenance, from simply existing to being generated by a hardened, isolated build platform that the build itself cannot forge. Verifying provenance closes the gap code signing leaves: a validly signed artifact built from the wrong source.
  6. 06

    SBOMs and AI Bills of Materials

    A software bill of materials (SBOM) is a machine-readable inventory of the components in a piece of software, with versions and identifiers, so you can answer 'are we affected?' when a vulnerability is announced. An AI bill of materials extends that to models, datasets, adapters, prompts and tools, and to the lineage between them: which base model, which training data, which fine-tuning run. Both are inventories, not protections; their value comes from being accurate, current and queried.
  7. 07

    Model Registries and Promotion Pipelines

    A model registry is the supply-chain choke point for AI systems: whatever is promoted there reaches production, and models are executable artifacts that have carried code. Securing it means separating the roles that upload, approve, promote and deploy; ingesting external models by pinned commit into quarantine; scanning with tools that fail closed, since scanners have been bypassed; converting to safe formats in isolation; evaluating and signing; and deploying only by digest through an admission policy that checks signatures and a revocation list. Lineage then lets a later finding be traced to every deployment.    Premium
  8. 08

    CI/CD Pipeline Security and Build Authority

    Pipeline scanning checks the system that builds and releases code. Map untrusted triggers, runner isolation, token scopes, third-party actions and artifact promotion separately from scanning application source.    Free
  9. 09

    Software Composition Analysis and Reachability Evidence

    SCA connects an artifact inventory to advisories and dependency paths. Learn why reachability, provenance, malware detection and licensing are separate assessments, and how to verify a dependency repair.    Free
  10. 10

    Secret Scanning and Credential Remediation

    Secret scanners locate credential-like material in code and delivery artifacts. Connect detection to revocation, session review, historical copies and preventive controls using GitHub, GitGuardian and Spectral examples.    Free
Topic 10 / 15 lessons

Detection & Response

Turn cloud and endpoint events into tested detections, scoped intelligence and verified response. Study SIEM, SOAR, EDR/XDR and historical hunting.
  1. 01

    Detection Engineering: From Hypothesis to Tested Alert

    Detection engineering turns knowledge of attacker behaviour into reliable alerts. Each detection starts from a behaviour attackers cannot easily avoid, depends on a data source that is confirmed to record it on the relevant assets, is tuned against history with narrow, owned exceptions, is tested by emulating the technique, and ships with a runbook and metrics. Managed as code, detections are reviewed, tested end to end, rolled out in shadow mode and retired when they stop earning their cost; ATT&CK is used to prioritise and to find gaps, not to colour a heatmap.    Free
  2. 02

    MITRE ATT&CK and Sigma: a Shared Language for Detections

    MITRE ATT&CK is a knowledge base of adversary behaviour organised as tactics (goals) and techniques (how), now linked to detection strategies and the telemetry needed. Its 2026 releases split Defense Evasion into Stealth and Defense Impairment, giving Enterprise 15 tactics, and added AI-focused techniques. Sigma is a vendor-neutral rule format: a detection is written once in YAML and converted for each SIEM, with correlation rules for counts and sequences. Coverage means tested detections on collected data, not coloured cells.
  3. 03

    Incident Handling: Declare, Contain, Scope, Recover, Learn

    Incident handling turns an alert into a controlled response: declare against written criteria, assign an incident commander, contain with the least evidence-destroying action that stops harm, preserve volatile evidence, scope across hosts, identities and cloud accounts, eradicate persistence, recover from trusted states, and review blamelessly with tracked actions. NIST SP 800-61 Revision 3 (April 2025) frames this inside the Cybersecurity Framework 2.0 functions, so preparation, governance and improvement are part of incident response, not separate from it.    Free
  4. 04

    Endpoint and Network Telemetry for Detection

    Endpoint telemetry (process creation with command lines and parents, network connections per process, file and persistence changes, authentication and module loads) shows what ran and why. Network telemetry (flow records, DNS, proxy logs and TLS metadata) shows who talked to whom, how much and how regularly, even when payloads are encrypted. Sensors collect these through kernel callbacks and event tracing on Windows, eBPF and audit on Linux, and Endpoint Security on macOS. Attackers try to blind sensors and blend into allowed channels, so telemetry must be shipped off-host quickly, watched for silence, enriched and correlated.
  5. 05

    Threat Hunting versus Detection Engineering

    Threat hunting is a human-led search for adversary activity that existing detections have not caught. Hunts start from a narrow hypothesis about a behaviour, from a baseline of normal activity where rare values stand out, or from a model that ranks anomalies; the PEAK framework names these three types and wraps them in prepare, execute and act phases. Hunts should aim at behaviours high on the Pyramid of Pain rather than sweeping indicators. Every hunt, whether it finds something or not, should produce an output: an incident, a new automated detection, or a documented data gap.
  6. 06

    Vulnerability Management by Risk: CVSS, EPSS, KEV and Context

    Vulnerability management decides what to fix first among thousands of findings. CVSS base scores rate theoretical severity; CISA's Known Exploited Vulnerabilities catalogue records confirmed exploitation; FIRST's EPSS estimates the probability of exploitation in the next 30 days. Combined with reachability (internet exposure, whether vulnerable code runs), asset criticality and attack paths, these produce tiers with remediation targets and documented risk acceptance. Programmes fix root causes such as base images and shared libraries, and measure exposure windows on exploited vulnerabilities rather than tickets closed.
  7. 07

    Infostealers and Session Theft

    Infostealer malware collects saved passwords, session cookies, tokens and developer credentials from a machine and uploads them as a log that is sold to people who specialise in breaking into organisations. Stolen session cookies represent logins that already passed MFA, so they can be replayed without a password or second factor. Defences make stolen secrets worthless (phishing-resistant MFA, short and device-bound sessions, no long-lived keys on endpoints), keep work access on managed devices, harden endpoints against lures such as ClickFix, and monitor stealer-log intelligence so sessions are revoked before buyers act.    Free
  8. 08

    SIEM Connectors, Normalization and Detection Evidence

    A SIEM turns collected events into searchable, correlated evidence. Trace connector permissions, parsing, event time, identity mapping and rule execution using Google SecOps and Elastic Security examples.    Free
  9. 09

    SOAR Playbooks and Safe Response Automation

    SOAR connects alerts to enrichment, approval and response actions. Design playbooks with scoped credentials, idempotency, timeout handling, audit evidence and explicit recovery criteria.    Free
  10. 10

    EDR and XDR: Endpoint Evidence and Cross-Domain Correlation

    EDR supplies endpoint investigation and response capabilities; XDR joins signals across domains. Evaluate identity joins, sensor coverage and response permissions using CrowdStrike and SentinelOne examples.    Free
  11. 11

    Cloud Detection and Response: From Audit Events to Containment

    CDR combines cloud control-plane, data-plane, identity and workload evidence. Investigate suspicious PII access without confusing a permission path with a recorded read or an alert with prevention.    Free
  12. 12

    Threat Intelligence Platforms, Sharing and Evidence Provenance

    Use MISP, OpenCTI, Google Threat Intelligence and SpyCloud for distinct intelligence workflows. Preserve source confidence, sharing restrictions, observation dates and local corroboration before acting on indicators.    Free
  13. 13

    YARA Rules, Live Hunting and Retrospective Search

    YARA matches content features; retrohunting applies a rule to a historical corpus. Learn rule validation, clean controls, corpus limits and why a file match is different from an endpoint-execution finding.    Free
  14. 14

    Malware Scanning, Sample Privacy and Verdict Limits

    Malware scanning combines signatures, content rules and other analysis under explicit handling limits. Understand public sample sharing, private analysis, hash lookups and why a clean verdict is not a safety proof.    Free
  15. 15

    Vulnerability Assessment Coverage and Verified Remediation

    Compare authenticated scanning, agent inventory, artifact analysis and external observations. Review Qualys, Tenable, Rapid7 and endpoint inventory by what they assess, then verify remediation on the affected asset.    Free
Topic 11 / 8 lessons

How LLM Systems Work

A working model of language model applications, read through one question: who wrote each input, and what can the model do with it?
  1. 01

    How LLM Applications Work

    An LLM application selects context, invokes a model and routes its output to readers, tools or stores. Review source and processor permissions, application or provider-managed history, and the actual consumers of each result. A model proposal and a completed authorized action are different observations.    Free
  2. 02

    Context Windows, System Prompts and Chat Templates

    Chat templates represent supported messages and roles in a model-specific format. Context limits constrain the current request, while stored history and trained parameters are separate assets. Preserve trusted role assignment, source permissions and required evidence; enforce consequential actions outside the model’s interpretation.    Free
  3. 03

    How LLMs Are Trained and Aligned

    Pretraining, supervised examples and preference or reward-based updates change a model’s parameters. Their objectives influence capabilities and behavior but do not establish current resource permissions. Review the data and exact model bundle, then measure the candidate and its application controls before release.    Free
  4. 04

    Retrieval-Augmented Generation as a Data Flow

    Retrieval-augmented generation supplies selected external evidence during a request, using vector, keyword or other search. Review source ingestion, current access, ranking, context and output consumers separately. Relevance is not permission, and access changes or deletion must follow derived records and reused answers.    Free
  5. 05

    Tool Calling and the Agent Loop

    Tool calling produces proposed operations for an application or provider-hosted executor. Inspect the input contract, trusted identity, resource permissions, task scope, resource admission and actual completion. Delegation and schema compliance help constrain the path but do not replace its remaining checks.    Free
  6. 06

    AI Gateways and Model Routing as a Security Control Point

    Model gateways can enforce provider policy, control request resources and record effective dispatches. Their assurance depends on path coverage, trustworthy request facts and controls that survive retries, queued work and concurrent admission. Work through a fictional route matrix and distinguish enforceable limits from delayed accounting.    Premium
  7. 07

    Third-Party Model Access: Relays, Routers and Model Substitution

    Third-party model access introduces recipient, routing and execution assumptions. Map the actual data and credential paths, distinguish task conformance from model identity, and evaluate attestation within its measured scope and trust model. Use an original supplier packet to make a bounded approval decision.    Premium
  8. 08

    The OWASP Top 10 for LLM Applications

    The OWASP Top 10 for LLM Applications (2026 edition, published in August 2026 by the OWASP GenAI Security Project) lists the most important risks in applications built on language models: prompt injection, sensitive information disclosure, excessive agency, supply chain, data and model poisoning, unbounded consumption, misinformation, hidden context exposure, vector and embedding weaknesses and improper output handling. The 2025 edition used the same risks with different numbers and called hidden context exposure system prompt leakage, so IDs need their year. This lesson explains each by mechanism, example and primary control, and how the items connect.    Free
Topic 12 / 9 lessons

Prompt Injection

The defining vulnerability of LLM systems, taught from its root cause and through to the designs that stay safe when the model is fooled.
  1. 01

    What Is Prompt Injection?

    Prompt injection attempts to turn lower-authority content into instructions that override a task or governing rules. Learn to separate legitimate requests, source influence, model proposals, application enforcement and observed effects, with a worked support scenario and scoped control claims.    Free
  2. 02

    Indirect Prompt Injection

    Indirect prompt injection carries attempted task redirection inside content an application processes. Map the source writer, ingestion path, model influence and effect policy. Learn to test retrieval and consequences separately, preserve unknown outcomes and account for derived copies without overstating risk.    Free
  3. 03

    Prompt Injection versus Jailbreaking

    Jailbreaking targets safety restrictions; prompt injection redirects behavior through material with insufficient authority. Definitions overlap across taxonomies. Classify the governing policy, source route and observed consequence, then assign model, product and application controls without assuming one label sets severity.    Free
  4. 04

    Jailbreak Technique Families

    Jailbreak families describe changes in framing, representation, supplied examples, conversation history and repeated attempts. Learn to choose coverage, distinguish generation from exposure, interpret research within its conditions and evaluate defenses without treating a benchmark score as a guarantee.
  5. 05

    System Prompt Leakage

    System prompt leakage exposes non-public instructions; hidden-context review also considers operational policy and tool definitions. Verify reported extraction against source revisions, distinguish guesses from restricted facts, minimize sensitive context and enforce resource and audience rules independently of model behavior.
  6. 06

    What Prompt-Injection Filters Can and Cannot Establish

    Prompt-injection filters can detect, block or route covered cases, but benchmark errors do not establish application authorization or production incident rates. Evaluate context, timing, joint detector behavior, allowed-work costs and the precise service rules that remain after a miss.    Premium
  7. 07

    Design Patterns That Bound Prompt Injection

    Compare six architectural patterns through a worked support-service design. Distinguish planner isolation, committed workflows, bounded outputs and data-flow permissions; examine branches, error feedback, retries and context reduction. Practice tracing source restrictions with an offline example and evaluate the useful work each design preserves.    Premium
  8. 08

    Multimodal Prompt Injection: Images, Audio and Screenshots

    Trace media from the original artifact through extraction and processing to the actual model input. Separate readable instructions, processing-dependent changes and non-text perturbations; evaluate source authority, task accuracy and the final audience with a practical review matrix.    Premium
  9. 09

    Evaluating Prompt-Injection Defences: Adaptive Attacks, Utility and Benchmarks

    Evaluate prompt-injection defenses with explicit tasks, source control, prohibited outcomes, versions, budgets and grading. Separate attempts from scenarios, proposals from effects, and measured rates from enforced properties. Use appropriate baselines and statistical assumptions, preserve unknowns and state the limits of a release recommendation.    Premium
Topic 13 / 6 lessons

LLM Application Security

Classic application security applied to a system with a probabilistic component in the middle: output handling, retrieval, data flows, guardrails and abuse.
  1. 01

    Insecure Output Handling

    Insecure (or improper) output handling, LLM10 in the OWASP Top 10 for LLM Applications 2026 (LLM05 in 2025), is passing model output to a browser, database, shell, template engine, URL fetcher or other interpreter without the validation and encoding you would apply to user input. Because output is shaped by every author in the model's context, an attacker who can influence the context can reach those interpreters, recreating cross-site scripting, SQL injection, command injection and SSRF.    Free
  2. 02

    Data Exfiltration Channels in LLM Applications

    An injected model that has read private data still needs a way to get it out. LLM applications offer many: explicit tools such as email or HTTP, URLs the model asks a tool to fetch, markdown images and links that clients load or users click, link previews, and content written somewhere the attacker can read. Closing these channels deterministically is one of the most reliable defences against prompt injection, because it works no matter how the injection was phrased.    Free
  3. 03

    RAG Security

    Securing retrieval-augmented generation means three things. Retrieval must enforce the asking user's permissions in code, with permissions copied into the index and kept in sync, tenants isolated and deletions propagated. Retrieved text must be treated as untrusted, because anyone who can write a source can inject instructions or misinformation. And the answer must be handled safely on its way out. Permission failures can expose data even when no prompt injection occurs.    Free
  4. 04

    Sensitive Information Disclosure

    Sensitive information disclosure, LLM02 in the OWASP Top 10 for LLM Applications (2025 and 2026), covers personal data, secrets, proprietary information and other users' data leaking through an LLM application. The leak paths include retrieval without authorization, context shared across users, prompt and response logs, caches, fine-tuning data, model memorisation, third-party providers and the answer itself. Controls minimise what enters each path and enforce access before data reaches the model.
  5. 05

    Guardrails and Their Limits

    Guardrails are controls placed around a model to check or constrain its inputs and outputs: schema validators, allowlists, PII detectors, topic and safety classifiers, injection detectors and LLM-based judges. Correctly implemented deterministic controls enforce their specified rules independently of model intent; probabilistic controls aim to lower the rate of bad outcomes and need honest measurement of both misses and false positives. A good architecture uses each where it fits and never presents a classifier as a boundary.
  6. 06

    Denial of Wallet: Cost as an Attack Surface

    LLM applications pay per token, so attackers can harm them by driving cost rather than taking them offline: long prompts, maximum outputs, inflated reasoning, routing to the most expensive model, agent loops and stolen keys used to resell model access. OWASP's 2026 list moved unbounded consumption to sixth and asks for hard caps that stop inference, not just alerts. Effective controls budget money per key, user, tenant and team, estimate and limit tokens before a call, cap reasoning and output, watch the share of expensive models, and plan a break-glass process that does not itself become the attack path.
Topic 14 / 9 lessons

Agent & MCP Security

Agents turn model mistakes into actions. Learn to bound what a manipulated agent can do with architecture, credentials and isolation rather than hope.
  1. 01

    Agentic AI Security

    Agentic AI security protects systems in which a model proposes actions through tools. Untrusted inputs and model errors can influence those proposals, so the host and resource services must enforce the task's authority independently: which data can be read, which actions can run, what requires approval and when execution must stop.    Free
  2. 02

    The Lethal Trifecta

    The lethal trifecta, a term coined by Simon Willison in 2025, is the combination of three capabilities in one AI agent: access to private data, exposure to untrusted content, and the ability to communicate externally. With all three, an instruction hidden in untrusted content can make the agent read private data and send it out. Use the combination to trace a possible disclosure path, then remove unnecessary capabilities or enforce restrictions outside the model. A narrower token alone does not revoke an older, broader token.    Free
  3. 03

    Excessive Agency

    Excessive agency, LLM03 in the OWASP Top 10 for LLM Applications 2026 (LLM06 in 2025), is when an LLM-based system holds more functionality, permissions or autonomy than its task requires, so that a manipulated or mistaken model can cause outsized harm. The fix works on all three dimensions separately: narrow tools, least-privilege credentials scoped to the requesting user, and human or policy gates on consequential actions.    Free
  4. 04

    MCP Security

    MCP connects an AI application to servers offering tools, resources and prompts. Review what the host puts into model context, what local processes can reach, and which identities and permissions govern remote calls. Metadata approval, transport authentication and authorization of a concrete operation are separate controls.    Free
  5. 05

    Tool Poisoning and Rug Pulls

    A server can place unwanted instructions in the tool metadata a host exposes to its model. Changed definitions can invalidate an earlier review, and one tool description can influence calls to another server. Review definition revisions before use, confine implementations and authorize each consequential action independently; a matching metadata hash does not prove unchanged behavior.
  6. 06

    Human Approval That Holds

    Human approval adds a person’s decision to an action that policy already permits. Trusted presentation, an authenticated approver, immutable action details and execution-side enforcement connect that decision to its effect. Review volume and usability matter, but a click, signature or second device alone does not establish informed consent or prevent duplicate execution.    Premium
  7. 07

    Agent Memory Security: Poisoning, Provenance and Forgetting

    Persistent memory can carry false claims or instructions into later agent tasks when those records are retrieved. Secure the write, promotion and retrieval paths with authenticated scope, source lineage, versions and expiry. Treat recalled content as data, keep resource authorization independent, and distinguish immediate retrieval denial from removal of derivatives, backups and copies already delivered.    Premium
  8. 08

    Multi-Agent Systems and Agent-to-Agent Trust

    Multi-agent security depends on the boundaries between cooperating workers. Authenticate peers, establish the user or service-owned task grant, authorize each resource and recipient, and constrain aggregate work. Structured handoffs and provenance support these checks but do not establish truth or permission. A2A provides interoperability; issuers and applications still define the authority and lifecycle of each operation.    Premium
  9. 09

    Agent and MCP Gateways Explained

    An agent or MCP gateway sits between agent runtimes and the tools or MCP servers they call. Because each call passes through it, it can authenticate the agent, apply default-deny policy to the tool name and arguments, swap in a credential issued for that tool, pin approved tool definitions, enforce budgets, route high-impact calls for approval and log every decision. It cannot control traffic that does not pass through it, cannot tell whether an allowed call serves the user's goal, and cannot clean instructions out of the data it relays. It works only alongside per-agent identity, sandboxing, egress control and authorisation inside the tools.    Free
Topic 15 / 6 lessons

Adversarial ML & Privacy

Attacks on the model itself: inputs that fool it, data that corrupts it, queries that reveal its training set, and copies made through its API.
  1. 01

    Adversarial Examples and Evasion

    An adversarial example is an input deliberately perturbed, often imperceptibly, so that a model makes a wrong prediction. Evasion attacks use them at prediction time against a fixed model, with or without access to its internals, and they often transfer between models. Defences such as adversarial training and certified robustness help within limits, and many published defences have been broken by adaptive attacks. The same idea appears in language models as optimised adversarial suffixes.    Free
  2. 02

    Data Poisoning

    Data poisoning manipulates training, fine-tuning or retrieval data so a model behaves as the attacker wants: degrading accuracy, causing targeted mistakes, or planting a hidden trigger. Models trained on scraped web data, user feedback or third-party datasets are exposed because attackers can influence those sources. Research has shown that poisoning web-scale datasets is practical and that small numbers of documents can implant backdoors in large language models. Defences rest on data provenance, curation, anomaly detection and evaluation, and none is complete.    Free
  3. 03

    Membership Inference Attacks

    A membership inference attack tries to determine whether a specific record was part of a model's training data, using the model's outputs. Models behave measurably differently on data they were trained on, especially when they overfit, and an attacker can exploit that gap. For sensitive datasets, membership itself is private information. Differential privacy is the principled defence; regularisation, limiting outputs and data minimisation reduce risk.    Free
  4. 04

    Training-Data Memorisation and Extraction

    Language models memorise part of their training data verbatim, and an attacker can sometimes make them emit it: personal data, secrets, copyrighted text. Memorisation grows with duplication, model size and prompt context, happens before overfitting, and survives alignment, which only hides it. Defences stack: deduplicate, scrub, train with differential privacy where it fits, filter outputs knowing approximate copies slip through, and measure with canaries and extraction tests. Fine-tuning on customer data is the highest-risk case.    Free
  5. 05

    Model Extraction

    Model extraction uses query access to a model to steal its functionality or parameters: training a substitute that imitates it, or recovering specific internals. It lets attackers avoid training costs, bypass usage terms, and build better attacks against the original. Rich outputs such as probabilities and log-probabilities make it easier. Defences combine rate limits, restricting output detail, monitoring for extraction-like query patterns, contractual terms and, where useful, watermarking.    Free
  6. 06

    Backdoors and Trojaned Models

    A backdoored model behaves normally except when a specific trigger appears in its input, at which point it does what the attacker chose. Backdoors are implanted through poisoned training or fine-tuning data or by directly modifying weights, and they reach victims through shared pre-trained models and datasets. They are hard to find because testing rarely includes the trigger, and research has shown some backdoors survive later safety training. Provenance, controlled fine-tuning, evaluation and architectural containment matter more than detection.
Topic 16 / 5 lessons

Red Teaming & Response

How to find what breaks before users do, measure it honestly when results are probabilistic, and respond when something breaks in production.
  1. 01

    What AI Red Teaming Is

    Design an authorized AI assessment around a specific requirement, actor and consequence. Compare exploratory and repeatable methods, interpret partial outcomes and produce actionable findings without treating a benchmark score or a single test label as complete assurance.    Free
  2. 02

    Scoping an AI Red Team Engagement

    Turn a release concern into an authorized assessment brief: actors, assets, permitted actions, observable failures and operating limits. Preserve the real control path before substituting safe effects, record environment differences and define who stops, amends and resumes the work.
  3. 03

    Attack Success Rate and Probabilistic Findings

    Define attack success by a specific event, actor and trial unit, then report the cases that actually ran and the outcomes that remain unknown. Learn when rates and confidence intervals support a claim, why retry budgets need their own protocol and how findings differ from frequency estimates.
  4. 04

    Statistics for AI Security Evaluations

    Choose an evaluation target and analysis that match the sampling process. Work through clustered and paired results, weighted judge audits, repeated-trial estimators and selection effects, while keeping statistical uncertainty separate from required security boundaries.
  5. 05

    AI Incident Response

    Learn to separate incident reports, confirmed effects, causal hypotheses and unresolved actions. Build a protected evidence record, contain the real execution path, scope exposure and make a recovery decision that covers repaired controls, retained state and useful permitted work.    Free
Topic 17 / 7 lessons

AI Governance & Risk

Connect AI inventories, risk frameworks, control evidence and acquisition decisions to the authority and data the organization actually manages.
  1. 01

    The NIST AI Risk Management Framework

    The NIST AI Risk Management Framework (AI RMF 1.0, January 2023) is a voluntary framework for managing risks from AI systems across their lifecycle. It organises the work into four functions: Govern (culture, policy, roles), Map (context and risks of each system), Measure (analysis and testing) and Manage (prioritising and treating risks). It describes characteristics of trustworthy AI, including security and resilience, and has companion profiles such as the Generative AI Profile (NIST AI 600-1). It does not certify anything; its value is a shared structure that engineering controls can hang from.    Free
  2. 02

    The EU AI Act for Engineers

    The EU AI Act regulates AI systems by risk. A short list of practices is prohibited; high-risk systems, such as those used in employment, credit, education or critical infrastructure, must meet requirements including risk management, data governance, logging, human oversight, accuracy, robustness and cybersecurity; some systems carry transparency duties; and providers of general-purpose AI models have their own obligations. It applies to providers and deployers outside the EU when their systems are used in the EU. Dates have shifted: the 2026 Digital Omnibus moved most high-risk deadlines to December 2027 and August 2028.    Free
  3. 03

    ISO/IEC 42001

    ISO/IEC 42001:2023 specifies requirements for an AI management system: the policies, roles, processes and controls an organisation uses to develop, provide or use AI responsibly. It follows the same structure as ISO/IEC 27001, so organisations with an information security management system can extend it. It requires AI risk assessment and AI system impact assessment, includes a reference set of controls, and is certifiable by accredited bodies. Certification shows a functioning management system, not that every AI system is safe or legally compliant.    Free
  4. 04

    Assessing an AI System's Risk

    A practical AI risk assessment turns frameworks into a repeatable intake: register the use case, ask a small set of questions that decide risk (purpose and affected people, data, autonomy and actions, exposure to untrusted input, model source, regulatory category), assign a tier, apply the controls that tier requires, and record owners, residual risk and review dates. Done well, it is fast for low-risk uses and thorough for high-risk ones, and it produces the evidence that the NIST AI RMF, ISO/IEC 42001 and the EU AI Act all ask for.
  5. 05

    AI Security Posture Management and AI Asset Inventory

    AI-SPM connects AI assets to data, identities, tools and deployment controls. Build an inventory that supports security decisions without confusing discovered AI usage with verified resistance to prompt injection.    Free
  6. 06

    Security Control Evidence and Compliance Reporting

    Build compliance reports from scoped observations, control ownership and exceptions. Preserve the difference between a passing technical check, effective operation over time and an audit conclusion.    Free
  7. 07

    Security Integration After an Acquisition

    Integrate an acquired company through verified ownership, bounded identity and network trust, data handling and evidence collection. Use discovery and posture tools to inform each step without granting blanket access.