Layer 4 — Agentic Security Specialization

This page is a map and a study strategy, not the content. The substance of each framework lives elsewhere on this site — Threat Landscape for the attack side, Governance & Compliance for the assurance side. What you need here is a clear view of which frameworks matter, what depth each one actually requires, and how to learn them so they stick. The most common waste of study time in this field is reading a standard front to back and retaining nothing usable.

The six you need

Depth calibration, framework by framework

For each: the minimum you must recall unprompted, and the detail that is a waste of time to memorize.

OWASP Top 10 for LLM Applications

• Recall unprompted: the categories and what distinguishes them; which ones apply to a system with tools versus one without; for any finding you write, which category it maps to.
• Do not memorize: exact identifier numbering across versions, or the example text. The list is revised, and quoting a stale number is worse than describing the risk correctly.
• Used in real work: tagging findings so they aggregate; giving engineers a shared vocabulary; structuring the risk section of a design review.

OWASP Agentic AI Threats & Mitigations

• Recall unprompted: the threat categories specific to agency — memory poisoning, tool misuse, privilege compromise, cascading failures across agents, identity and impersonation between agents, loss of human oversight. And, for each, one concrete mitigation you have actually implemented.
• Do not memorize: the full mitigation catalog verbatim, or every sub-variant.
• Used in real work: this is the one that maps most directly onto agentic design reviews. It is the vocabulary for saying why “it’s just an LLM app” understates the risk.

MITRE ATLAS

• Recall unprompted: that it is tactic-and-technique structured like ATT&CK, the tactic sequence at a high level, and how to look up a technique fast. Knowing the shape is what matters.
• Do not memorize: technique IDs. Nobody recites them; everyone looks them up. Fluency with the structure beats memorized identifiers every time.
• Used in real work: red team planning and reporting, detection coverage mapping, and giving a threat-informed narrative to an audience that already knows ATT&CK.

NIST AI RMF 1.0

• Recall unprompted: the four functions — Govern, Map, Measure, Manage — and what each is for. Govern is the organizational layer that makes the other three real; Map establishes context and risk framing; Measure is analysis and metrics; Manage is prioritization and response.
• Do not memorize: subcategory numbering. Know the functions cold and navigate to specifics.
• Used in real work: structuring an AI risk program, answering customer security questionnaires, and giving a governance backbone to a program that currently has none.

EU AI Act

• Recall unprompted: the risk-tier structure and that obligations scale with tier; that high-risk classification brings substantive requirements around risk management, data governance, documentation, logging, human oversight, and accuracy/robustness; that role matters — provider versus deployer obligations differ.
• Do not memorize: article numbers, annex contents, or the timeline of application dates. Those change, and legal counsel owns them anyway.
• Used in real work: scoping questions early in a project (“which tier is this, and are we a provider or a deployer?”), and justifying why logging and human oversight are requirements rather than nice-to-haves.

ISO/IEC 42001

• Recall unprompted: that it is an auditable management system standard — policy, roles, risk assessment, controls, internal audit, management review, continual improvement — and that it composes with ISO 27001 rather than replacing it.
• Do not memorize: the full annex control list.
• Used in real work: enterprise sales, certification programs, and any conversation where “we have a process” needs to become “we have evidence.”

Framework → question it answers → where it appears in your deliverables

Read that table as a workflow rather than six separate silos: ATLAS and the OWASP lists tell you what to test and what to fix, NIST AI RMF gives the program shape that decides what gets prioritized, and the EU AI Act and ISO/IEC 42001 determine what must be documented and provable. A finding that never reaches the register is not managed, and a control with no evidence does not exist to an auditor. Evidence automation is where the last hop stops being manual.

How to learn a framework so it stays learned

Do not read front to back. Map it onto a system you built.

1. Pick a system you own. Ideally one of the labs — Lab 2 works well because it has multiple agents, MCP tool exposure, and retrieval.
2. Skim the framework once for structure only. Categories, functions, tactic names. Twenty minutes, no notes beyond the outline.
3. Force a mapping table. One row per framework item, one column for “how this appears in my system,” one for “control I have,” one for “gap.” Empty cells are the point — they are your findings.
4. Write the gaps up as findings in the framework’s own vocabulary. This is the step that converts reading into recall, because you now have your own sentences attached to each item.
5. Fix two or three gaps in code, and record the evidence. Now the item has a memory of an implementation attached to it, which is what makes it retrievable under interview pressure.
6. Re-read the framework properly. It reads completely differently the second time, and takes half as long.

mapping-table.md
| Framework item | Where it appears in my system | Control I have | Gap | Evidence |
|---|---|---|---|---|
| <item>         | <component + data flow>       | <control>      | <y/n + note> | <link> |

Time budget that works: roughly one framework per week alongside building, in this order — OWASP LLM Top 10 → OWASP Agentic Threats → MITRE ATLAS → NIST AI RMF → EU AI Act → ISO/IEC 42001. Threat frameworks first because they are concrete and immediately usable on code you wrote; governance frameworks second, because they make far more sense once you have real findings to organize. Lab 5 is the bridge between the two halves.

Where the frameworks overlap, and where they do not

People assume these six say the same thing in different words. They mostly do not, and knowing the seams is more useful than knowing any one list in depth.

The gap none of them fully closes: none is a substitute for threat modeling your specific system. They are checklists of what other people found. Your architecture has properties nobody listed. Use Lab 5 and the STRIDE work from Layer 1 for the part the frameworks cannot do for you.

What “knowing it cold” actually looks like

Self-check

• For each of the six, I can state in one sentence what question it answers.
• I can name the four NIST AI RMF functions and what each is for, without notes.
• I can explain the difference between complying with a regulation, aligning with a framework, and being certified against a standard.
• I have a mapping table from at least two frameworks onto a system I built.
• I have fixed at least one gap that a mapping exercise surfaced, and I can point at the evidence.
• I can describe an agentic threat category and the control I implemented for it, in the same breath.
• I know which framework I would reach for first if asked “is this system legal for us to ship in the EU?”

Reference material and current versions are tracked in standards references; certification paths that formalize some of this are covered in certifications; staying current after the initial pass is the continuous learning loop.

Next: Layer 5 — Communication & Influence, which decides whether anything you found in this layer actually gets fixed.