About this document

One reference for securing the whole modern AI stack - models, cloud, retrieval, agents, the protocols that connect them, and the governance forming around them - organized around a single idea: the decisive boundary is the path from untrusted content in to privileged action out.

It is compiled and maintained by Iaroslav Mezin as a living document, revised continuously as the field moves, and written for a technically literate reader: security practitioners, red-teamers, AI and platform engineers, and advanced students. It assumes comfort with security fundamentals and a working mental model of how machine-learning systems behave.

One idea organizes everything that follows. For modern AI systems the decisive security boundary is rarely the model’s raw output - it is the path from untrusted content in to privileged action out. Read the whole document through five recurring boundaries:

• Inputs - prompts, retrieved documents, tool output, protocol metadata.
• The model and runtime.
• Memory and context.
• Tools and actions.
• External assets and identities.

Retrieval, browser agents, coding agents, MCP, and identity all turn out to be variations on the same theme once those five are held in view.

How to use this

The sections run foundations → advanced, but each stands alone - start anywhere via the sidebar. Look up any term in the glossary; trace any claim in the reference library. The incident board (The 2026 incident board) and any dated vendor claim are point-in-time snapshots - verify specifics against primary sources before relying on or citing them.

Security, legal & privacy notice

This document is for defensive research, security assessment, and authorized testing only. Do not use its methods, prompts, or examples against systems you do not own or lack written authorization to test. It is not legal or compliance advice; privacy, security, and export-control obligations vary by jurisdiction and use case - obtain qualified counsel where required. Do not place real personal data, credentials, or regulated information into testing workflows without authority, a lawful basis, and a retention plan.

Diagram conventions

Every diagram in this book is Mermaid, rendered in the browser so it adapts to the theme, and it obeys one rule: restraint carries the meaning, color does not.

• One fill, one stroke weight. Nodes share a single fill and a single 1px stroke. Edges and arrowheads share one grey. This is set once in the renderer, not per diagram, so thirty figures look like one hand.
• Labels are set at body size, in the body face. A diagram should read as part of the sentence around it, not as an illustration pasted in.
• Decorative classDef lines are stripped at render time. Adding color to a diagram has no effect, which is deliberate.
• One accent per diagram, at most. Mark the single node under discussion with class SomeNode focus and it gets the brand amber. The style itself is injected by the renderer, so there is exactly one accent on the site and it is theme-aware. If a diagram needs two accents, it is really two diagrams.
• If it would read better as a table, make it a table. A flowchart that is just a list with arrows costs a reader more than it gives.

The type system follows the same logic: Inter for reading and headings, JetBrains Mono for code and metadata, on a strict 8px spacing grid.