The just-released OWASP Top 10 for LLM Applications includes some interesting changes. It opens with a sentence that frames the rest of the document:

Stop trying to build a model that cannot be fooled. Build the system around it, so that when the model is fooled, and it will be, nothing important breaks.

That’s a new stance, one overdue in hindsight, because it follows from a very specific technical fact. A language model reads its system prompt, the user’s question, a retrieved document, and a tool’s output as one token stream. Current architecture doesn’t separate an instruction from data. That’s just how it’s built.

So that means that you don’t close prompt injection in the same way as SQL injection. You need to limit or bound what a successful injection can reach. There are three general boundaries that do work.

The first is what tools the model can call. On its own, a model produces text. It can’t read a file, send an email, or query a database until a developer gives it a function to call or invoke. So a list of registered tools is essentially the complete set of actions that a model can take. Which means that anything not on the list is out of the reach of an agent.

So the tool list is essentially an authorization decision, and falls into CISSP domain 5. Here, the agent is the subject, and the tools are its permission set. The traditional rule is to grant the minimum necessary to do the job.

What changes is how much weight that rule carries. Since the agent can be talked into doing things, whatever it’s permitted to do, anyone who can get text in front of it is effectively now permissioned. Least privilege stops being hygiene to follow, and becomes the only thing standing between a successful injection and what is within the agent’s reach.

That’s the “confused deputy” problem, named by Norm Hardy in 1988, after a compiler that would overwrite the system’s billing file. The user didn’t have permissions to touch that file, but the compiler did. And the compiler had no way to tell its own business from a file a user had handed it. The user passed a filename. A filename indicates which file, not who’s allowed to touch it. So the compiler had to supply the authority itself, and its own was the only authority it had. Hardy’s fix was to make the deputy act with the caller’s authority, and OWASP arrived at the same place.

Their mitigation is to execute tools in the user’s context, and preserve that context across chained tools and agent calls, never falling back on the agent’s own broader service account. Essentially, the agent should use the user’s permissions, and it should ensure the next agent uses that same permission set.

Note that deciding which tools should be used, and how much authority each has to operate, are important and separate decisions. Reducing the number of tools but leaving their elevated permission scope doesn’t reduce the risk.

What the agent remembers between sessions is important. Agents can carry long-term memory forward between sessions via RAG or vector store, and these memories get pulled back into the context window each session and read as trustworthy. Because the model has no way of telling a memory it formed from one that someone else planted, one poisoned entry can be used in a subsequent session.

This idea relates to traditional data storage handling as defined in CISSP Domain 2. In this case, a memory needs to be classified with a retention limit, and controls placed over who can access and modify it. Typically in this context, a memory is treated like a product feature, which is why it ends up as an asset in your environment with no owner or associated retention policy.

Read more

Most people studying for the CISSP in 2026 have at least tried using AI to help them learn. It makes sense because the technology is everywhere and it feels like a cheat code. You request a detailed study plan and a dozen CISSP-like practice questions, and within seconds you’re off and running. Why not? The exam has a reputation for being difficult, and it can be hard to evaluate any prep platform without spending time with it.

I want to make the case that while AI can be useful in some areas for exam preparation, relying on chat tools to generate adequate exam-level practice questions may increase your risk of problems on exam day. These risks may not be obvious. AI is good at producing questions based on technical criteria but misses the mark on the type of questions you’ll likely see on the exam.

The CISSP isn’t really testing what you know

A CISSP question doesn’t normally use simple recall or fact-only formats. You’re often provided a short scenario and four options that all seem reasonable, asking which is the BEST answer or which one you’d do FIRST. People call the exam “a mile wide and an inch deep”, but the deeper truth is that its goal is to test judgment. Weaving together sometimes disparate technical, safety, cost, and business goals, a scenario can force you to make choices in the face of ambiguity. CISOs face the same sort of judgment daily.

That’s part of what makes the CISSP difficult, and what a good practice question needs to reproduce. A question that only checks whether you memorized a definition helps you train just some of the required muscle. The actual exam gives you two or more plausible answers, and your job is to pick the one that best fits the criteria. If you don’t use practice tests that reinforce that process, you’re not preparing well.

And this is exactly the part that trips AI models up.

Where AI breaks down

When you ask a model to write CISSP questions, it can fail in a few very specific and sometimes subtle ways.

AI tends to reuse words from the stem (the core part of a test question that sets up the problem) in the correct answer. In other words, it leaves fingerprints. It also makes the right answer more complete: usually a bit longer, and more qualified because it’s trying to make the correct answer airtight. These fingerprints can be subtle. Many candidates may learn to pick the most complete, familiar-sounding option and get the answer right more often than they should. That trains pattern-matching, a habit that doesn’t work well on the real exam.

The most obvious version of the AI fingerprint, where the right answer is simply the longest, is the easiest to catch. A harder one is the answer that is the same length as other options, but still gives itself away by adding more complete conditions. Of course, a word count misses this. Finding this fingerprint means examining the option to see if it is doing more work than others.

As we also know, AI makes up shit, usually with complete confidence. Ask enough questions, and the chat model will eventually invent a framework, miscategorize a control, or assign a requirement to the wrong standard. If you don’t catch it, you end up memorizing the wrong thing and carrying that error into the exam.

One of the most important issues is that AI can’t reliably understand or judge the more complex business-integrated, multi-component (or multidimensional) scenarios. It even trips on the terms FIRST versus BEST. It’s great at “which encryption algorithm fits this requirement.” It struggles with “the company just discovered x, what do you do first.” Especially where three or four options are defensible, and the answer depends on business alignment AND the right order of operations. The model will revert to the technical fix because that’s how it was trained.

This last issue is the one I’ve spent the most time on.

Teaching a machine what “CISSP-worthy” means

While building the Academy, I’ve developed an AI rubric, or “AI judge,” to rate questions like a human examiner. I write a question or a model drafts one, and the judge scores it. Is the right answer truly the single best one, or is there a defensible tie? Does it rely on judgment or a technical detail? Does it carry any fingerprints or tells?

The judge isn’t all-knowing, and it often doesn’t get it right. Current “frontier models” (Opus, Gemini, GPT-5x) all make very similar grading mistakes. They rate more technically oriented answers as harder, so a question loaded with technical distractors looks difficult to them. Even when, to a human thinking like a CISO, the answer is obvious. This is basically “hard by technicality, easy by judgment.” If AI wrote the question and then also tried grading it, it’s usually blind to its own fingerprints in the answer.

So the judge never has the final say. I use it as a detector, not a decision-maker. It surfaces suspects (“this one smells like a tell,” “these two options might both be right”), and it’s a human’s job to make a judgment call. I also pay attention when the judge expresses uncertainty. I ask it to run multiple iterations, and when its answers split, that split is something to evaluate. A question the judge can’t decide on is usually right on the border. And again, a person needs to review and make a decision.

As an example, I recently reviewed a question about securing a software supply chain, with plenty of “technical machinery.” The kind of question that feels hard. The keyed “best” answer was reasonably based on a component that was authentic and unaltered. But from a security manager’s perspective, the real question wasn’t “is the component authentic.” It’s “do we trust the source at all?” The judge rated it fine. Only reading it as a manager, not an engineer, caught that the better answer.

There’s an underlying reason and a term for this. AI is fluent at the lower rungs of Bloom’s Taxonomy: remembering and understanding. But the CISSP lives in the higher ones: applying, analyzing, evaluating.

Once you reach a certain level of technical competence, the technical distractors stop being tempting, and the correct question becomes obvious. It still may look like a CISSP question, but it doesn’t really behave like one.

None of this came together in a single clean formula. It took many versions of the rubric, and I still tune it by hand because “what makes a question CISSP-prep-worthy” is a craft, and one you can only partly automate. The judge narrows it down. But a person makes the call, and that division of labor is important to how the Academy operates.

Why I built the Academy

The trouble I kept running into, with both linear question banks and the AI-generated kind, is what led me to build a CISSP study platform called the Academy.

That “judge narrows it down, but the person makes the call” split isn’t a slogan. I use AI as a tool, but the real decisions, such as “Is this the single best answer? Is this judgment or trivia? Does this train the muscle the exam tests?” rest with a human who has taken the exam. That’s the line AI models can’t cross yet.

I looked for a single product that did all that but couldn’t find one, so I started building it. Every question is crafted to be worthy of the test bank and to build your readiness as the end goal.

Every question comes with a full explanation, not only why the key is right but why each distractor is wrong, since understanding why the tempting answers are incorrect helps build judgment.

None of it’s magic. It’s work done by hand where it must be and helped by AI where it’s safe.

The shortcut that isn’t there

The CISSP is hard because it tests judgment, and judgment is the one thing that still doesn’t get generated from a prompt. The tools got better. The people who write good questions became faster. But the shortcut, the one where you generate a stack of questions and grind them until you pass, still isn’t there, because question creation that is truly exam-prep worthy needs a human.

Use AI. It’s a great study partner. Just don’t hand it the one job it can’t yet do.

I’ve seen a lot of CISSP study plans that are basically a reading schedule in a costume. Start with the Official Study Guide chapter one in week one, chapter two in week two, and so on until exam day. It feels organized. It’s also one reason why capable people walk out of the test center surprised.

A calendar tells you what to read. It doesn’t tell you where you're weak, and the CISSP exam is good at finding weak spots: it’s adaptive. It finds the edges of what you know and keeps pushing there. So a plan that treats all eight domains as equal, and treats “I read it” as “I know it,” is preparing you for a version of the exam that doesn’t exist. If you want the fuller picture of why strong candidates come up short, I covered the six most common traps. Let’s talk about how to build a plan that avoids them from day one.

Here’s the approach I’d use, and it starts before you open a book.

Step 1: Set a real runway, then take a baseline

Two questions before you schedule anything.

First, how long do you actually have? For most people with a few years of security experience, three to six months of consistent study is realistic. Less experience, or a big gap in one domain, pushes you toward the longer end. For a candid look at what actually makes the exam hard, I've broken it down here. Set the runway to your life, not to a template.

Second, where are you starting? Take a diagnostic before you build anything: a set of practice questions across all eight domains done cold. You’re not trying to pass. You’re finding the floor. If you have the Sybex Official Study Guide, you already own a clean way to do this. Its 40-question Assessment Test covers all eight domains. Take it directly by hand in the book, or register the book on the Wiley Efficient Learning portal, answer a quick question to confirm you own it, and take it online to see how you scored.

If your score comes back low, don’t sweat it. It just flags the domains that need the most focus first. Score above 90 percent, and you’re working from a strong base already. Either way, that result is what the plan gets built around.

The core idea: study by weak concept, not by domain

This is the part most plans get backward. CISSP questions are multidomain by design. A single scenario can pull from risk management, cryptography, and network security at once, so a shaky concept in one area quietly drags down your performance across several. That means “study Domain 3 this week” is the wrong unit of work. The right unit is the concept you keep missing.

So the plan isn’t a march through eight domains in order. It’s a loop. Surface your weak concepts, study those specifically, then confirm they’re fixed. The domains are the map. Your misses are the itinerary.

The three-phase plan

Phase 1: Anchor

Before you can find weak spots efficiently, you need a spine: a structured first pass that gives you the shape of all eight domains so nothing is a total blank. Weight this pass the way the exam weights the domains. Domain 1 is 16 percent and touches everything, so it earns more of your early attention than the 10 percent domains. Work through each domain enough to grasp its structure. My domain walkthroughs are built for exactly this pass, Domain 1 through Domain 8, each mapped to the ISC2 outline, with the CBK explainer as the one-page overview if you want it first.

Anchor is the shortest phase. Its only job is to get you to the point where a practice question makes sense, so the real work can start.

Phase 2: Diagnose and target

This is where most of your time goes, and it’s the loop that moves the needle.

Take practice questions in small batches, twenty to fifty at a time. As you go, keep a running list of every question you got wrong, didn’t recognize, or felt shaky on, regardless of which domain it came from. Study everything on that list. Then take another batch and do it again. Each round rewrites your list toward the concepts you haven’t locked in yet, and pulls your time toward your weak areas without you having to guess where they are.

The discipline is boring, and it works. Rinse and repeat until your list stops filling up with the same concepts.

Phase 3: Simulate and sharpen

In the final stretch, shift from learning to performing. Take full-length, CAT-style practice sessions under real-time pressure so the format becomes a constant. Practice the pacing, roughly a question a minute, and practice the mindset the exam rewards: answering as a risk-aware manager, not as the hands-on technician who wants to go fix the box. That question-reading skill has its own step-by-step method, and it’s worth drilling on its own. Anything that still surfaces here goes to final cleanup.

Use your practice questions the right way

A practice question is worth far more than a right-or-wrong score if you work it correctly. For each one:

• Read the question first, without the answers, and try to answer it in your head.

• Read all the choices, then reread the whole thing to look for the qualifier you missed.

• Before you pick, explain to yourself why the right answer is right and why each other option is wrong.

That last step is the whole game. If you can land the correct answer but can’t say why a distractor is wrong, that distractor’s topic is a weak concept hiding inside a question you got right. Most people run through hundreds of questions chasing a percentage. You’ll get more from fifty worked this way than five hundred clicked through on autopilot.

How to know you’re ready

Ready isn’t “I finished the book.” It’s a pattern: your scores hold steady across mixed full-length sets, and you can explain your reasoning, including why the wrong answers are wrong, on a consistent basis. When your weak-concept list keeps coming back nearly empty, and your timing is comfortable, book the exam. If you’re planning a second attempt rather than a first, the retake has its own strategy built around your score report.

If you’re short on time

Working full-time while you study is the normal case (even if that means full-time on a job hunt). If your runway is tight, protect Phase 2. Trim the Anchor pass to the heaviest domains, shorten Phase 3, but do not skip the diagnose-and-target loop. It’s the phase correlated with passing. An hour a day spent on your real weak spots beats a weekend re-reading what you already know.

The plan on one page

I put the three-phase structure into a blank weekly template you can fill in for your own runway. Grab the free template on the CISSP resources page and adapt it to your timeline and your baseline.

This plan is a method, and the method is manual. You run your own diagnostic, keep your own miss list, and re-sequence your own weeks as your weak spots move. That’s doable, and plenty of people pass doing exactly this with free resources. My study notes on GitHub are always free and a fine place to start.

If you’d rather not run the loop by hand, that’s the problem the BalancedSec Academy was built to solve. It does the diagnosing for you: an adaptive engine and a real question bank that find your weak concepts and rebuild your schedule as you go, plus the book, CISSP: A Balanced Approach. Same basic method as above. The Academy just runs it for you, and founding-beta access is open if you want it.

Either way, start with the diagnostic. The plan follows from what it tells you.

People fail the CISSP for several common reasons. Examples include choosing the technically perfect answer over the business-aligned one, misreading the adaptive format, and failing to prioritize studying weak domains. Failing the CISSP is more common than the celebratory LinkedIn posts would have you believe. The exam is broad; the Computerized Adaptive Testing (CAT) format can be challenging, and plenty of sharp, experienced practitioners walk out of the testing center disappointed on their first try. If that’s you, you’re in good company. The failure doesn’t define you or your abilities; it points you in the direction you should grow and spend your time.

A retake adds a few new parameters and reframes the focus on your next steps. The first time, you’re building coverage across eight domains. The test format and cadence are new. The second time, you already have a map of the terrain and a new guide to weak areas provided directly from ISC2. The job now is to read that map correctly, understand how the exam actually scores you, and pick a timeline that matches how close you came.

Your new playbook

Before you plan anything, let’s get the boundaries straight. ISC2 enforces mandatory waiting periods between attempts (isc2.org/exams/after-your-exam):

• After your first failure, you can retest after 30 test-free days.

• If you need a second retake, you have to be 60 test-free days from your most recent attempt.

• For a third or subsequent failure, there must be a 90-day test-free gap before trying again.

• You can attempt any ISC2 exam up to 4 times in a rolling 12-month period.

Don’t confuse that mandatory cooling-off period with your study runway. They’re two separate clocks. That first 30-day window is only the earliest ISC2 will let you back in the chair. How long you actually take to prepare is your call, and it should depend on how far off you were, not on how fast the rules allow.

One money-saving note. If you bought ISC2’s Peace of Mind Protection before your first attempt, you have a second voucher already, valid for 180 days from purchase with a 30-day gap between sittings (isc2.org/landing/exam-peace-of-mind). If you didn’t buy it up front, you can’t add it retroactively. The exam itself is a meaningful cost (check ISC2’s current pricing page for the exact figure in your region), so factor that into your budget and timeline.

Read your diagnostic report before you touch a book

If you fail the exam, ISC2 provides a diagnostic breakdown of the eight domains. There’s no numerical score. Instead, you get three proficiency tiers per domain: Below Proficiency, Near Proficiency, and Above Proficiency, plus a rank ordering of domains by how well you did. That ranking is really useful in planning your strategy for the next attempt.

Work it in this order:

Below Proficiency first. A “below proficiency” mark isn’t a verdict on how hard you worked. The Common Body of Knowledge is enormous, and it’s easy for a domain to get less time than it needed, or for some threads to come loose on exam day. Treat the label as a signal for where focused effort pays off most. Here are some ideas on a few approaches that tend to work better than rereading the domain cover to cover (which may be part of the reason the threads slipped the first time):

• Narrow before you dig. Use ISC2’s exam outline as a checklist and rate each objective in the domain: solid, shaky, or new. The “below” score almost always traces to a few specific areas, not the whole domain, which turns a mountain into a short list.

• Get the shape first, then the details. Sketch the domain’s structure so that concepts have a frame to hang on to. They stick better on a structure than as a flat list of facts.

• Hear it explained a different way. If one pass through the OSG didn’t land, a second identical pass may be doomed to the same fate. A video or a different author on that one topic can frame it in the way that finally clicks.

• Explain it out loud. Try teaching the concept in plain language to a study partner or just to the room. Wherever you stall is the precise spot to study next.

• Anchor it to something real. Tie the concept to a breach, a control you’ve actually used, or a situation from work. That’s also the shape the exam asks it in, so it does double duty.

• Then bring practice questions back in. Once the concept is back in place, questions become the way to test it and to study the reasoning behind every option. Spend as long on why the wrong answers are wrong as on why the right one is right.

Near Proficiency second. A Near mark means you’re already close to the passing line, so these are the cheapest points to win. Close them with targeted practice rather than a full rebuild.

Above Proficiency last. Light passive review to keep it warm. Don’t spend your best hours here out of comfort.

One factor cuts across all three tiers: domain weight. A weak mark costs more in a heavy domain. Domain 1 leads at 16%, and four more tie at 13% each (Security Architecture, Communication and Network, IAM, and Security Operations), together two-thirds of the exam, so a gap there is worth closing first. The same gap in Asset Security or Software Development Security (10% each) moves your overall score less. Spend your best hours where weak meets heavy.

Reading the report is the easy part. The real work is turning that ranking into a sequenced, time-boxed plan you’ll actually follow, and then holding to it.

How the CAT actually scores you (and the myth that wastes retakers’ time)

This is where a lot of retake advice goes wrong, so it’s worth reviewing.

CISSP CAT scoring is compensatory. There is no per-domain pass mark. Your pass or fail comes down to a single overall ability estimate measured against one standard (700 on a 0 to 1000 scale) across all the operational items you answer. Strong performance in one area genuinely offsets weakness in another. ISC2’s scoring FAQ says it directly: its exams are “compensatory,” so “a higher number of items answered correctly in one domain [can] compensate for a lower performance in another domain,” and “a single pass/fail result is calculated on the total of all operational items” (ISC2 exam-scoring FAQ).

Why does Domain 1 keep coming up? Not because the engine “targets” it or because fixing it cascades into your architecture score. It’s simpler: at 16%, Domain 1 is the largest single block of the exam, so it gives you the most compensatory headroom. Nothing more mystical than weight.

The engine picks each question to sit near a 50% chance you’ll get it right, tuned to its current read on your ability. Answer well, and the estimate climbs, and the questions get harder. Miss one and it eases off. So the harder your items feel, the higher the engine currently rates you, which means difficulty isn’t meaningless.

The trouble is you can’t read it reliably from the chair. Every item is aimed at your personal edge, so it feels punishing whether you’re passing or failing. About a quarter of the items aren’t even scored. They’re pretest questions being trialed for future exams, and you can’t tell them from the real ones. And you never see your own estimate. Expect it to feel hard, take that as the format doing its job, and don’t try to grade yourself mid-exam.

Where the exam ends, though, is a signal. It stops early once it’s 95% confident you’re clearly above or clearly below the line (after a 100-item minimum), and runs to its 150-item maximum only when you’re close enough that it can’t reach that confidence. So a fail at the short end means the algorithm got sure quickly, and a fail near 150 items means you were sitting right on the boundary. Both tell you how hard to push next time.

For reference, the current CISSP CAT is 100-150 items over 3 hours, post-April 2024 (see the ISC2.org exam outline).

Pick your timeline from where you landed

Match your study runway to your diagnostic, not to the calendar minimum.

The 30-day sharpen. For candidates who ran near the 150-item ceiling with mostly Near ratings, you were close. Spend the first week on frameworks and mindset, the middle two weeks drilling your two or three softest domains, and the final stretch on timed practice and pacing. Rest before exam day.

The 90-day reset. The right choice for most retakers. Month one, rebuild your weakest domains from primary sources and draw the connections between technical controls and the governance behind them. Month two, shift to applied practice with a running error log (what you missed, why your reasoning failed, what the better answer protects). Month three, full-length timed simulations to build stamina.

The 180-day rebuild. For candidates sitting below in four or more domains, or anyone fitting study around a demanding job (and life). Treat it as a fresh cycle through all eight domains, then layer in study-group discussion and heavy simulation in the back third. Explaining a concept out loud to another candidate is one of the fastest ways to find out whether you actually know it.

The mindset shift that decides most retakes

The most common reason strong technical people fail the CISSP is answering as an engineer when the exam wants a manager or owner perspective. I wrote a full method for working on hard questions in “Strategy Guide for Answering Difficult CISSP Questions”, so I’ll keep it short here. The engineer reaches for the immediate technical fix. The exam usually rewards the governance move: assess the risk, follow the process, align with the incident response plan, and the organization’s risk tolerance.

Treat that as a tiebreaker, not an iron law. Plenty of questions have a correct technical answer. What decides the right path is the qualifier in the question. Watch for MOST, LEAST, FIRST, and BEST, because they can completely change the answer. A useful habit under a wall of technical detail: read the final sentence first. CISSP items often bury a high-level policy question at the end of a paragraph of noise.

One retake-specific warning. If you’re reusing a question bank you’ve seen before, you’re now testing your memory of answers, not your understanding. Force yourself to state the principle behind each answer before you pick it. If you can’t explain why the other three options fail, score it as a miss even if you “knew” it was C.

How my resources fit

Everything above works with any good materials. Here’s how mine fit—one is free for good, and one is free for now.

Always free: the BalancedSec GitHub study notes. They condense the ISC2 Study Guide domain by domain along the exam outline, so they double as a distilled primary text and the checklist for your rebuild. No signup, no cost, and they stay that way. If you use nothing else of mine, consider these.

Free for now: the BalancedSec Academy (founding beta). This is the piece for the hard part: turning your weak domains into a plan you actually work. It runs CAT-style practice that surfaces weak areas, builds a study plan that adapts to them and your exam date, drills the owner/manager mindset through scenario questions, and includes my book, CISSP: A Balanced Approach, in-app (organized around ISC2 exam objectives). It’s in founding beta, so it’s free while that lasts.

A retake isn’t a verdict on whether you belong in this field. It’s a measurement, and this time you aren’t starting from a blank page. You have the report. Read it, respect the timeline, and go take it back.

Many people fail for the same short list of reasons, and almost none of them stem from not “knowing enough about security.” They come down to your prep, your in-exam thought process, and how you handle the pressure. That’s a gift because predictable mistakes are avoidable. Knowing the traps before you sit down is one of the biggest advantages you can bring into the exam room. Here are the most common reasons people fail, and how to beat them.

Six traps, and how to beat each one

1. The technical trap

This is the big one, and it can catch even the strongest candidates. Experienced practitioners want to answer questions from, well, their experience. If much of that experience is “hands-on,” it can very well mean applying a technician’s lens to the questions. You really know your stuff, and you’ve been doing it for a hot minute. You see a problem, and your instinct is to reach for the hands-on fix: block the port, patch the service, contain the threat.

But the CISSP isn’t testing that instinct. The exam wants you to view risk, governance, and security from an organizational perspective. The technical fix may disregard the root problem, and we need to treat the organization holistically. We’re striving for a balance between driving security to reduce organizational risk and not standing in the way of goal achievement. And it can be a tricky stance to take. We want to view security programmatically, thinking like a CISO or a senior risk advisor. Answering questions from that higher-level policy, governance, and organizational risk perspective. People fail because they pick the technically perfect option over the one that fits how a business actually makes security decisions. The better you are at the technical job, the more likely this is to trip you up, because your instincts are well-trained for the work and misaligned for the test.

There’s a second version of this trap that’s easy to miss. Years on the job build habits, and some of those habits quietly disagree with the standardized answer the exam wants. If your shop handles something a certain way, that doesn’t make it the CISSP-correct way. Passing means being willing to set aside how it’s done at your desk and answer the way the Common Body of Knowledge defines it. Experience is an asset here, right up until it argues with the exam.

How to beat it: think like the CEO or owner. When you read a scenario, separate the business problem from the technical symptom before you look at the answers. A few habits keep you on the right side of it:

• Risk and policy first. Look for the answer that establishes governance, reviews the business case, or runs a risk assessment before deploying a technical control.

• Pick the answer that covers the most ground. When several options are technically correct, choose the one that protects the organization’s overall risk posture rather than the narrow fix.

• Human life wins, every time. In any physical security, business continuity, or disaster recovery scenario, personnel safety comes before equipment, money, and data.

• Be able to explain it. A security manager has to justify decisions to people who don’t live in security. Some questions test whether you can pick the answer a non-technical executive or board would understand and back, not just the one that’s technically sharpest.

Then read the question like a lawyer. A law degree is, of course, not required, but put on your “attorney hat” and read carefully and purposely:

• Find the qualifier. Words like MOST, BEST, FIRST, PRIMARY, and NOT change the whole question. They tell you whether it wants your first action (usually an assessment or a policy step) or the ultimate goal (reducing risk). Remember that there are also processes that work best when followed in a particular sequence (I’m looking at you, Incident Response).

• Read it twice. Once for the scenario and to catch the qualifier, once to strip away the noise and find the actual problem. Try to read the question without looking at the potential answers.

• Eliminate hard. Two of the four options can usually go fast. Cut the answer that jumps to a technical fix when the question asks what to do first, because the first step is almost always to assess, analyze, or get management’s buy-in. Cut absolutes (always, never, eliminate all risk), since security manages risk rather than erasing it. Cut a control that costs more than the asset is worth. And cut the option that treats the symptom instead of the root cause. What’s left is usually a real 50/50, and now you’re choosing between two answers instead of four.

Rehearse this with scenario-based questions until the business-first answer no longer feels unnatural.

2. Cramming and memorizing

Plenty of candidates treat the CISSP like a vocabulary quiz. They memorize definitions, ciphers, port numbers, and checklists, then walk in and find almost none of it being asked directly.

The questions are likely situational. You may not be asked to define a preventive control, but you will likely be handed a messy scenario and asked which control type fits the budget and the value of the asset in front of you. Experience and cross-domain reasoning help you navigate these beyond mere memorization.

How to beat it: study for understanding, not recall.

• Learn how concepts connect, not definitions in isolation. If you can explain why a control exists and when you’d choose it, the scenario questions will seem a lot more natural.

• Practice on scenarios, not just flashcards. Work questions that hand you a situation and make you choose.

• Active learning over silent reading. Teaching a concept to someone else, mind-mapping a domain, or working through it in a study group exposes the gaps that rereading may miss.

• Real examples, not just definitions. Read about ways AI is failing and succeeding, real examples of actual breaches, and case studies. It helps tie concepts together.

3. Studying without an anchor

This one is about structure. You can study a lot and still walk in underprepared, because volume is not the same as a plan. Without a spine for your prep, an anchor to measure new material against, and a clear sense of how you learn best, the hours may not yield the retention or substantive coverage you need. It can be difficult to judge whether you’re covering the right material, in enough depth, at the right pace.

Going wide can be a good thing, and if you have the time, do it. Breadth builds perspective, and perspective is what lets you notice when a resource is off-base or out of step with the exam. Breadth becomes a problem only when there’s no baseline to judge it against, because without an anchor, five slightly different explanations turn into noise instead of a fuller picture.

How to beat it: anchor first, then go wide on purpose.

• Build a small core, then read around it. Anchor on one trusted primary text (the official ISC2 CISSP Study Guide, or OSG, is the common baseline) and one solid question bank (the Official Practice Tests, or OPT, its companion, with around 1,300 questions). That core is your spine, and everything else supplements it.

• Map everything to the exam outline. Use ISC2’s official CISSP exam outline as your checklist for what’s in scope, so you can place each new resource against it and study the test that actually exists.

• Go wide for perspective. With an anchor in place, more viewpoints can help, however, the exam is already wide, so judge the best use of your time accordingly. A second guide for the concepts that won’t click, a video series for framing and priority. Being widely read is what gives you the judgment to spot a resource that’s off.

• Match the format to how you learn. Some people internalize by reading and writing concepts out. Others are best reinforced with audio or video. Figure out your own modalities and weight your stack toward them, because the best resource is the one that is easy to actually absorb.

• Cross-check against the authority, not against each other. When two sources disagree, the exam outline and official materials are the tiebreaker.

4. CAT panic and bad pacing

The English CISSP uses Computerized Adaptive Testing. You get between 100 and 150 questions within a three-hour window, and the difficulty is likely to increase as you answer correctly.

That last part can feel like a trap. As the questions get harder, candidates assume they’re failing, when a hard question can mean the opposite. Panic can make it harder to answer questions you would otherwise be able to reason through, creating a sense of urgency and leading to second-guessing, and ultimately running out of clock.

How to beat it: work with the format, not against it.

• Reframe the hard stretch. When the questions get brutal, that’s often a sign you’re doing well. Expect it, and don’t read difficulty as failure.

• It’s one-way. The format serves your next question based on your last answer, so you can’t skip or go back. Make a decisive, educated choice on every item and move on.

• Hold a pace. Aim for roughly 50 questions an hour, and glance at the clock every 20 to 25 questions. That’s enough to stay on track without feeding the panic.

• Expect the unknown. You will hit topics you never studied. That’s normal. Stay calm, fall back on core principles you’ve learned, cut the distractors, and pick the most organizationally sound answer.

5. Leaning on your strong domains

Most of us live in one or two corners of security at work, say cyberthreat response, or identity and access management, and we get comfortable there. Candidates can lean on that real-world experience and neglect the domains they touch less often. The exam covers all eight, so a lopsided prep produces a lopsided score, and the weak domains drag the whole thing down.

There’s a subtler version of this. The domains aren’t islands, and some of the hardest questions live where they overlap, like identity feeding a business continuity plan or cryptography showing up inside a network design.

How to beat it: study all eight, and target the weak ones.

• Find your weak domains and pour time there. Use the practice tests from your stack for diagnostics. Treat every miss as a signal about where to study next, then spend your hours on the uncomfortable domains, not the comfortable ones.

• Study the seams. Deliberately work the places where the domains overlap, since that’s where the hardest questions live.

• Bring every domain to a baseline, even the ones you think you own.

6. The language tax

The CISSP is as much an English reading test as a security test, and that’s a real headwind if English isn’t your first language. The jargon is dense, the vocabulary is heavy, and plenty of questions turn on a subtle distinction between two words. Every item you have to translate in your head costs time and focus you can’t spare. The exam is offered in only a handful of languages (English, Chinese, German, Japanese, Korean, and Spanish), so for most non-native speakers, English is the only option.

How to beat it: prepare for the language, not just the material.

• Immerse in English. Do your prep in English rather than translating from your first language, so exam-day reading feels familiar.

• Practice on English questions. Get used to how the exam phrases things, including the qualifiers that carry the whole question.

• Build vocabulary alongside the content. Keep a running list of the terms and turns of phrase that slow you down.

None of this is a wall. People clear it every year with prep aimed squarely at the language, not just the material.

The resources I’ve built

Everything above works with any good materials. Here’s how mine fit -- one is free for good, one is free for now.

Always free: the BalancedSec GitHub study notes. My notes condense the OSG and are organized domain by domain along ISC2’s exam outline, so they double as the spine and a distilled version of the primary text. No signup, no cost, and they stay that way. Readers have told me the notes were the backbone of their prep, and there are testimonials on balancedsec.com if you want to see what people got out of them. If you use nothing else of mine, use these.

Free for now: BalancedSec Academy (founding beta). It runs CAT-style practice exams to surface your weak domains, builds a study plan that adapts to them and your exam date, drills the owner/manager mindset through scenario questions, and includes my book, CISSP: A Balanced Approach, in-app (organized along the same outline). It’s in founding beta right now, so it’s free while that lasts. Use it if it helps, or stick with the free notes.

Passing the CISSP has never been about being the smartest person in the room. It comes down to studying your weak spots, learning to think like the owner/manager the exam is written for, and keeping your composure when it pushes back. All of that is learnable, and you now have a map of exactly what to practice. Trust your preparation, believe you can do this, and the exam becomes a challenge you’re ready for instead of one waiting to surprise you. Knowing where the traps are is your advantage: go use it.

Part 1 of this series was about governance and risk: who’s accountable for an AI system and how you decide what could go wrong. Part 2 was about the data: how to classify and protect the information a model learns from. Part 3 was about the build: the architecture and pipelines that turn that data into a finished model. Every part so far has been about getting a model ready. None of them touched what happens once you switch it on.

That’s where part 4 picks up. The model is now live, taking real traffic from real people, sitting behind APIs and inside your network. That changes the attack surface, and four CISSP domains answer the change: network security (Domain 4), identity (Domain 5), testing (Domain 6), and security operations (Domain 7).

You don’t need to be an ML engineer to follow this. The goal, as in the earlier parts, is to recognize a new category of risk and determine which kind of control addresses it. Most of these controls are ones you already know. They just point at something new.

Network Security and Endpoint Protection (Domain 4)

A live AI system talks to many things: APIs, cloud services, and clusters of GPUs that provide the actual compute. Every one of those connections is a door. Two of them lead somewhere you don’t want an attacker to go.

Model Extraction: Stealing the Model Through the Front Door

Imagine someone who can’t see your recipe but is allowed to taste the dish as many times as they want. Taste it enough, vary the orders enough, and eventually they can reproduce it at home. That is model extraction. The API is the tasting spoon.

In a model extraction attack, someone repeatedly queries your public endpoint, observing which inputs produce which outputs. Each answer tells them a little more about where the model draws its lines. Given enough queries, they can train their own local copy that behaves like yours. They walk away with your intellectual property without ever touching your database. This isn’t theoretical: researchers extracted production models from BigML and Amazon’s ML service with near-perfect fidelity using only the public prediction API (Tramèr et al., USENIX Security 2016), and the technique is now cataloged as Exfiltration via AI Inference API (AML.T0024) in MITRE ATLAS.

You don’t need the math to get the point. The more queries an attacker can fire at your endpoint, the better their copy gets. If nothing caps the number of queries, nothing caps the quality of the clone. So the fix is simple: limit how many queries any one caller can send, and you limit how good a copy they can build. That’s what rate-limiting does, and it’s the main defense here.

The Controls

Protecting a model endpoint is mostly familiar network security pointed at a new target.

• TLS 1.3 with mutual authentication (mTLS). Encrypt everything in transit, and use mTLS (both sides prove who they are with certificates, no passwords) for internal calls between your application services and the AI engines behind them.

• Micro-segmentation. Put the GPU clusters in their own Virtual Private Clouds, block direct inbound traffic, and force every query through an authenticated API gateway. This is the same network segmentation from Domain 4 you already know, pointed at compute instead of subnets.

• Rate-limiting and query baselining. Set a normal range for how a human interacts with the endpoint. When something blows past that range, the way an extraction attack has to, block it automatically. This is the direct counter to the model-theft problem above.

Identity and Access Management (Domain 5)

Access control in an AI environment splits the same way it always has. Authentication asks, “Are you who you say you are?” Authorization asks, “Are you allowed to touch this model or this dataset?” The twist is that more and more of the things asking for access aren’t people.

Least Privilege, Need-to-Know, and Just-in-Time Access

The old principles still hold. They just apply to model weights and training jobs now.

• Lock down the model registry. Treat read, write, and modify rights on model weights like you’d treat write access to production code, because that’s what they are. Only your automated build tools should be able to promote a model. People shouldn’t be editing neural parameters by hand any more than they’d hand-edit a production binary.

• Just-in-time retraining access. Don’t hand engineers a standing permission to retrain. Make them request it when they need it, and revoke it automatically when the job finishes. This is the same just-in-time privilege you’d use for admin access, applied to the training pipeline.

Identity for Autonomous Agents

Here’s where the familiar model starts to crack. AI workflows are moving toward autonomous agents: software that queries databases, calls APIs, and takes actions on an employee’s behalf without a human in the loop for each step. User-based identity wasn’t built for that.

• Give every agent its own identity. Each autonomous agent needs a unique cryptographic machine identity (a service account or OAuth client credentials of its own). Without it, you can’t prove which agent did what, and non-repudiation falls apart the moment something goes wrong.[5]

• Use ABAC, not just RBAC. Role-Based Access Control checks who you are, like a badge at a door. Attribute-Based Access Control checks who you are and what you’re doing, what you’re touching, where the request came from, and how risky it looks right now, all before it says yes (NIST SP 800-162 is the canonical definition). For an agent whose job changes minute to minute, the badge alone isn’t enough.

Security Assessment and Testing (Domain 6)

Your existing tools have a blind spot here. A vulnerability scanner reads code. A static analyzer reads code. Neither one can tell you that your model will happily ignore its own safety rules when a user phrases the request the right way. There’s no buggy line of code to find. The weakness lies in how the model handles language, so the only way to catch it is to deliberately attack it with words.

The AI Red Teaming Program

AI red teaming is testing a live model the way an attacker would, hunting for inputs that cause it to misbehave or reveal what it shouldn’t. According to a recent NIST post, you can’t lock a model down once and walk away. NIST senior scientist Apostol Vassilev published a 2026 proof that no finite set of guardrails is universally robust against adversarial prompts, and his takeaway, in a sentence, is the case for red teaming: “You have to commit to a constant search for weaknesses and stay ahead of attackers.” It’s an offensive mindset aimed at a system that traditional testing treats as a black box.

Red teaming goes after three main things. Model hijacking is taking control of how the model behaves, bending its outputs, or repurposing it for something it was never meant to do. Model extraction, the theft attack from Domain 4 above, reverse-engineers the model itself. Prompt injection abuses the input channel to override the system prompt and the rules baked into it. A good program probes for all three.

Run it as a real program, not a one-off. AI red-teaming is one of the testing methodologies that NIST formally recommends in the Measure function of its Generative AI Profile (NIST AI 600-1), which also provides the Govern/Map/Measure/Manage structure for handling what you find. Document those findings in a central risk register and fix things in the order that business impact dictates, not the order you found them in.

Security Operations (Domain 7)

Your SOC can’t defend what it can’t see, and a live AI system generates a kind of traffic the SOC has never had to watch before: prompts going in, generated responses coming out, agents acting on their own. Domain 7 is about getting eyes on it all.

The Defensive Tooling Got an Upgrade Too

The same AI that opened new attack surfaces is now built into the tools that defend them. In four categories of security tooling, AI was once an optional add-on. Now it comes built in, and it’s worth knowing what each one does:

• SIEM aggregates and correlates logs. The AI layer spots anomalies across event streams and reduces alert fatigue by separating real signals from the noise.

• SOAR automates the response once a threat is detected. Agentic AI is what’s driving it now: systems that take defined actions without waiting for a human to push the button.

• XDR ties detection together across endpoints, networks, clouds, and apps. The AI connects dots across data sources that no human could correlate by hand at that volume.

• UEBA monitors behavior and flags deviations from a baseline for users and service accounts alike. It catches the slow compromise that never trips a single alarm, the drift that signature-based detection sleeps right through.

These extend your existing Domain 7 controls; they don’t replace them. For the exam, know what each one does and where AI augments the analyst rather than replaces their judgment. UEBA is the answer worth memorizing: it’s the canonical “anomaly over time” pick when a scenario rules out signature-based detection.

Watching What Goes Out: Continuous Monitoring and DLP

The everyday risk here isn’t an attacker. It’s a well-meaning employee pasting source code or customer PII into a public chatbot. This already happened at Samsung: within weeks of allowing ChatGPT, engineers leaked semiconductor source code and internal meeting notes into it three separate times, and the company banned the tool outright (TechRadar, 2023).

• Inline DLP and CASB. Put Data Loss Prevention gateways and Cloud Access Security Brokers (a CASB sits between your users and the cloud service, inspecting what crosses) in line with outbound prompts. When sensitive strings show up, a credit card number, an internal code header, the payload gets blocked or tokenized before it leaves the building.

• Semantic logging. Normal logs record events: who logged in, what ran. AI auditing needs more than that. Record the actual prompt strings and the model’s responses, then run automated analysis over them to flag data leakage, social engineering, or an attack in progress. You’re logging meaning, not just events.

Watching the Model Itself: Model Drift

Even with no attacker anywhere near it, an AI model gets worse over time. Picture a guard dog trained on last year’s burglars. The burglars changed their methods. The dog didn’t. On paper, it’s the same deterrent. On the street, they are less effective. That’s model drift: production data slowly stops looking like the training data, and accuracy bleeds away. A threat-detection model trained on old attack patterns gets weaker every time attackers change their tactics.

For Domain 7, drift is a continuous-monitoring problem with three parts:

• Detection. Compare live performance against your baseline numbers (accuracy, precision, recall, false-positive rate). A statistically real drop triggers a look.

• Indicators. Shifts in the input feature distribution, a sudden change in the confidence-score histogram, rising false positives, and outputs drifting away from ground truth (when you have it) all point the same way.

• Response. Decide your retraining trigger in advance. Some teams retrain on a schedule, others when drift crosses a threshold. Either works, as long as it’s a written playbook and not a judgment call made in a panic.

Drift is the quiet sibling of data poisoning. Poisoning corrupts the model on purpose. Drift happens because the world moved on. Both give you wrong answers, both need monitoring, and both live in the Domain 7 playbook.

When It Breaks: Incident Response

Your IR plan needs a few AI-specific moves.

• Model quarantine. Write the playbook for isolating a model you think has been poisoned. The moment it’s suspect, pull the container offline and route inference to a clean cold-standby copy. Treat it like isolating any other compromised host, just faster, because the model keeps answering until you stop it.

• Automated guardrails. Put rule-based limits around the inference API that act as a circuit breaker. When an output looks wrong in shape or content, the guardrail catches it before it ever reaches the user.

The Part That Stays Human: Context and Critique

There’s one risk in this whole series that no control in any domain can fix for you. AI is taking over the routine middle of knowledge work, the everyday analysis that used to be how people built their expertise in the first place. As it takes that work over, people stop checking its output. And when you stop checking the machine’s work, you slowly stop understanding it. The skill hollows out from the inside. This isn’t a hunch. Human-factors research has documented “automation complacency” for years: when a system is usually right, people stop scrutinizing it, miss its failures, and the effect hits experts as well as novices and doesn’t wash out with practice (Parasuraman & Manzey, Human Factors, 2010).

That’s a security problem, not just a career one. A tool can’t be held accountable in a courtroom or an audit. You can. So the human has to stay in the loop on purpose, through a discipline we can call the Context and Critique Rule. It adds a little friction back in, on purpose, in three steps:

• Evidence. Treat every AI output as raw, unverified data. Not an answer yet.

• Cognition. Check it against what you actually know: the business rules, the compliance lines, the security frameworks in your head.

• Discernment. Take the “Human Pause.” Stop, think, and decide. Because the liability falls on you no matter what the model says, you sign off on accuracy and security before anything moves forward.

The shift this series has been building toward is from doing the work to directing it. As a professional, you’re more valuable the better you understand and orchestrate these systems. The technology is a tool. It isn’t a teammate, and it can’t carry the blame when something breaks.

Pulling the Series Together

Across four parts, the throughline has been the same: AI doesn’t get its own CISSP domain, it lands in all of them, and the controls you already know mostly still apply once you see where they point. To put it in one map:

1. Secure the pipeline (Domain 3). Isolated, multi-tier MLOps architecture with cryptographic checks on datasets and model weights.

2. Protect the weights in use (Domain 3 & 8). Confidential Computing enclaves and polyinstantiation (separate, isolated copies so one tenant can never read another’s data) to keep model weights safe while they’re running.

3. Lock the interfaces (Domain 4). TLS 1.3, VPC micro-segmentation, and rate-limiting against model extraction.

4. Tighten access (Domain 5). Least privilege and need-to-know on the registries and training jobs, with ABAC for anything autonomous.

5. Verify continuously (Domain 6 & 7). A real AI red teaming program alongside semantic monitoring, inline DLP, and automated output guardrails.

6. Keep the human in charge. The Context and Critique Rule and the Human Pause, on every team.

Get the first five right, and you’ve got a defensible AI security posture. Get the sixth right, and you’ve got people who can still tell when the first five have failed. That last one is the whole point. Every other control in this series protects the system. This one protects your ability to know whether the system is lying to you.

Introduction

Part 2 was about the assets: naming them, classifying them, protecting them. This article is about the machinery that produces and runs them, and it sits in two CISSP domains. Domain 3 (Security Architecture and Engineering) is where you design how a model gets built so it can’t be quietly corrupted. Domain 8 (Software Development Security) is where you keep the software, external components, and model files themselves from being used to carry an attack into production.

You don’t need to be a developer to follow this. The goal is to recognize a new category of risk and know which kind of control answers it. Here’s why it’s new: these attacks don’t trip the tools you already run. A firewall doesn’t catch a tampered training record. A vulnerability scanner doesn’t flag an input that looks perfectly normal but makes the model misbehave. And a model file you download can run hidden commands on your system the moment a program opens it. Ordinary security reviews miss all three, which is why they must be built into the architecture and the build.

A quick definition carried over from Part 2 that we’ll lean on: a model’s weights are the numbers it learned during training. They are the model’s “brain,” and the file that holds them is the asset everything below is trying to protect or abuse.

Building the model safely (Domain 3)

Ordinary software is predictable. The same input gives the same output every time. A model is different. It is built by feeding it large amounts of data and letting it learn patterns, so whatever goes into that training quietly shapes how it behaves later. That one fact, a model is only as trustworthy as the data and the process that produced it, is the heart of Domain 3 for AI.

Think of building a model as an assembly line with a few stages: collect the data, clean it, train the model, test it, and release it. The security goal is to keep those stages separate and under control so that a problem at one stage can’t slip downstream unnoticed. The controls map to things a CISSP already knows:

• Keep data collection walled off from training. The systems that pull in external data reside on their own network segment, so untrusted material never sits alongside the model being built. This is network segmentation applied to the assembly line.

• Check data before it is used. Incoming data is validated against what you expect, and anything malformed or out of place is rejected rather than trained on. This is input validation.

• Lock down the finished models. Store completed models where they can’t be quietly swapped or altered, and digitally sign each one so you can prove you’re running the version you approved. This is integrity and change control.

If you want the authoritative catalog of how these attacks actually play out, MITRE ATLAS is the one to know. It documents real-world attacks on AI systems and is the AI counterpart to the MITRE ATT&CK framework your SOC analysts already use.

Attacks that target the model, not the network

The next two attacks don’t break in through a port or a credential. They corrupt how the model learns, or they manipulate what it sees when it runs, and both slip past firewalls and signature-based detection because there is nothing obviously malicious to catch.

Poisoning: corrupting what the model learns

Poisoning is tampering with the data a model is trained on. An attacker slips bad records into the training data so the model learns the wrong lesson. The most concerning version is a backdoor: with a small number of planted examples, the model behaves normally almost all the time but flips to an attacker-chosen behavior whenever a specific secret trigger appears in the input.

This is not just an image-recognition problem. Many organizations take a ready-made model and adjust it on their own examples (this is “fine-tuning,” from Part 2). If that example data is poisoned, the trigger goes in with it. Systems that answer questions by first looking up your internal documents, often called retrieval-augmented generation, have their own version: poison the documents being searched, and you change the model’s answers without ever touching the model.

The defenses are about provenance (knowing where data came from) and inspection:

• Chain of custody for training data. Track and verify where every batch of data came from. “We scraped it from the web” is not provenance.

• Screening before use. Statistical checks flag records that look nothing like the rest of the set, so they can be pulled before training.

• Trimming influence. Periodically remove records that carry an outsized effect on the model, which limits what a small poisoned batch can do.

Evasion: fooling the model at the moment it runs

Evasion happens when the system is live. The attacker crafts an input that looks ordinary to a person but pushes the model to the wrong answer. The classic example is a stop sign with a few carefully placed stickers that a self-driving car’s vision system reads as “Speed Limit 45,” a real safety failure.

For the language models most organizations are adopting, this same idea has a name you’ve already met: prompt injection. A cleverly worded input that doesn’t look like an attack talks the model into ignoring its instructions, and it sits high on the OWASP Top 10 for LLM Applications (LLM01 in the core list). Part 1 introduced it as a concept. In Domain 3, it becomes an architecture problem: you have to assume some inputs are hostile and design the system so that a model that gets fooled can’t do much damage.

The defenses sit on both sides of the model:

• Screen inputs and outputs. Treat every prompt as untrusted, and check the model’s responses before anything acts on them. Open-source guardrail tools (such as Protect AI’s llm-guard) do exactly this, watching for injection attempts, leaked secrets, and unsafe output.

• Train it to resist. Deliberately train the model on tricky and manipulated inputs so it holds up better against them.

• Limit the blast radius. The fewer systems and permissions the model can reach, the less a successful trick is worth. Part 4 returns to this.

For the full map of these threats and their controls, the OWASP AI Exchange is the deeper reference.

Securing the software and the model files (Domain 8)

Domain 8 is where AI development meets the software supply-chain security you already know, with one twist that surprises people: an AI model file can be a program in disguise.

When a model file is really a program

You’d reasonably assume a saved model is just data, a big set of numbers. The catch is that the industry’s most common method for saving models (Python’s Pickle serialization (.pkl or .pt) allows arbitrary code to be tucked inside the file. When the wrong tool opens it, those instructions run automatically on your computer. So a model downloaded from a public sharing site can carry an attack, and loading it is like running a program handed to you by a stranger.

Three controls address this:

• Scan a model before you open it. Tools such as Protect AI’s ModelScan and Guardian inspect a model file for hidden malicious instructions before any program loads it.

• Prefer the safer file format. A newer format called safetensors stores only the numbers and has no way to carry instructions, so it can’t run anything when opened. Favor it over the older formats.

• Only accept models from sources you trust, confirmed by a valid digital signature, the same way you’d treat any other software you bring into the environment.

Know what’s in your software (supply chain)

AI applications are built on large toolkits and pre-trained models created by others, and any of those outside components can be a way in. The control is the one you already apply to software: keep an inventory. A Software Bill of Materials (SBOM) lists every component you depend on. Extend that idea to AI by tracking the models and datasets too, sometimes called an AI Bill of Materials, and scan those dependencies continuously for known weaknesses.

Run a new model as if it can’t be trusted

Until a downloaded model has been scanned and cleared, treat it like untrusted software. Run it in an isolated container with the least access it needs, so even a malicious model can’t reach the rest of the system. And while the model’s weights are loaded in memory and used, protect them with the hardware-based enclaves described in Part 2 (Confidential Computing), which keep the data readable only within a protected boundary.

Keep tenants apart (polyinstantiation)

When a single model or data store serves multiple customers or classification levels, a lower-privilege user can sometimes infer sensitive details about another user from the shared state. Polyinstantiation is the classic Domain 3 database control: it involves creating multiple versions of the same data object based on classification levels. In AI, this means giving different classification levels or tenants their own distinct instances of models or data stores, ensuring a lower-privilege user cannot infer sensitive training data from a shared model state.

In the next article

The pipeline is built, and the model is defended. Part 4 moves to running it in production: Domains 4 through 7, where network controls, identity and access for both people and machine accounts, red-team testing, and day-to-day security operations keep the deployed system in check, and where the AI-powered tools in your own SOC start working for you.

Intro

The first article in this series covered Domain 1: governance, policy, and the risk structures that decide who’s accountable for AI. That’s the part where you write the rules. Domain 2 is where the rules meet the assets.

Asset Security is about the things you actually own. You can’t protect an asset you haven’t named; you can’t apply the right control until you know how sensitive it is, and you can’t claim it’s destroyed unless you can prove it. AI doesn’t change that logic. It changes the inventory. Training datasets, prompt histories, fine-tuning inputs, and model weights are now corporate assets that carry real value and real exposure, and likely postdate many asset registers. Fine-tuning inputs are the proprietary examples a company supplies to adapt a pre-trained model to its own work, the tagged support transcripts or annotated documents that teach a general model a specific domain.

ISC2’s Exam Guidance for Artificial Intelligence (April 2, 2026) points in the same direction. The guidance maps AI security into the existing eight domains, and for Domain 2, that means extending the asset-security work you already do to this new inventory. Part 1 walked through the mapping. (See AI Security for the CISSP: What’s Changed.)

Here’s the shift in one line.

Classifying AI Assets

You can’t protect what you can’t see. Classic asset security grew up around structured databases, physical media, and discrete files, things with an obvious shape and an obvious owner. AI assets break that mold, and the value sits in unexpected places.

Foundation models are commoditizing fast. Capable base models are cheap or free to get, many with downloadable (open) weights, so the base model itself is rarely where a company’s advantage lives. That advantage sits in the data you fed the model and the resulting weights. If a competitor walks off with your refined training set or your final model weights, the damage is immediate, because they get the full benefit of your work without paying to build it.

That leads to the rule to anchor on, whether you’re studying or doing the work: classify AI assets by the impact of their compromise, not by their file format or where they happen to sit. A 4 GB weights file and a spreadsheet look the same to a storage system. They’re nowhere close in value.

One complication: AI assets are hard to value precisely. A model’s capabilities can emerge during training in ways the team didn’t plan for, so a standard benchmark won’t always tell you what the thing is really worth, or what you’d actually lose. When the value is fuzzy, classify for the downside. Ask what a competitor or a regulator could do with the asset if it walked, and price the protection against that.

Who Owns What: Data Roles in an AI Pipeline

Most asset-security failures in AI aren’t exotic. They come from blurred roles. In a machine learning pipeline, the people who own the data, the people who run the infrastructure, and the systems that process the records all start to overlap, and accountability quietly evaporates. Keeping these roles straight matters as much in production as it does in study.

• Data Owner. A senior leader, accountable for the asset. The Owner sets the classification, approves access, and authorizes any corporate data going into a training pipeline. Accountability stops here and can’t be handed off to a technician.

• Data Custodian. The technical role that implements what the Owner approved: backups, encryption keys, access lists, the hosting environment.

• Data Controller. A privacy role under GDPR. The Controller decides the purpose and lawful basis for processing personal data and makes sure training inputs comply with privacy law.

• Data Processor. Processes personal data only on the Controller’s instructions. A third-party AI summarization or translation API is the textbook example.

• Data Subject. The person whose data is being processed or trained on.

• User. The employee who actually operates the system to get work done.

It almost always plays out the same way. A data scientist or DBA, acting as a Custodian, uploads a corporate dataset to a public AI service to get a quick result, and nobody cleared it with the Owner. Outside the company’s control, that service might store the data, keep it indefinitely, or train its models on it, and any of those outcomes leaks intellectual property and creates third-party privacy risk. Only the Owner has the authority to accept that risk, and a Custodian who makes the call alone has broken the asset-security policy. The GDPR definitions of controller and processor exist to keep exactly that line from blurring.

The fix is administrative, not technical. Separation of duties so the engineers who train models can’t also push them to production or rewrite access controls. Job rotation and mandatory vacations so quiet tampering, poisoned data, or unauthorized parameter changes have a chance to surface.

Protecting Data in Three States

Every asset lives in one of three states, and each one needs a different control. Apply the wrong one, and you either leave a hole or break the system.

Read more

I’m Jeff Moore, a security practitioner, educator, and builder. Over the last 25+ years, I’ve worked across technology and security leadership roles, and today I write about security architecture, AI security, risk management, certification preparation, and the practical realities of defending modern systems.

People typically subscribe for one of three reasons:

Path 1: You’re Studying for CISSP

If you’re preparing for the CISSP exam, start here.

You’ll find content on:

• CISSP study strategies

• Domain-specific guidance

• Practice questions and exam preparation

• Security architecture fundamentals

• Common mistakes candidates make

Recommended reading:

• How difficult is the CISSP exam?

• Strategy Guide for Answering Difficult Questions

• AI Security for the CISSP: What’s Changed and How to Prepare

• CISSP CBK Explainer

• Security Control Frameworks Explained

Path 2: You’re Already a Security Professional

Many readers already hold certifications and work in security, engineering, architecture, governance, risk, compliance, or leadership roles.

Topics include:

• Security architecture and governance in the age of AI

• Cloud security

• Risk management

• Security leadership

• AppSec and development

• Security Credentials

Recommended reading:

• Strap In (with harness engineering)

• MITRE ATLAS: The AI Threat Framework Every Security Leader Needs to Know

• ISACA’s AAISM: The First AI Security Management Certification, Examined

• The CISSP Holder’s Guide to AI Security Credentials

• Inside the NIST AI Risk Management Framework

Path 3: You’re Exploring Security

AI is rapidly changing how organizations build, operate, and defend systems.

Here you’ll find content covering:

• Overviews of specific security topics, including governance and risk management

• Security & risk management frameworks

• Security implications of AI adoption (including AI-driven dev, supply chain, and model security)

Recommended reading:

• Guide to Security Governance

• NIST AI RMF or ISO 42001?

• Six Things Adversaries Are Doing With AI

• Inside the NIST AI Risk Management Framework

• Exploring Claude Code and AI-Driven Development

What I’m Building

In addition to writing, I’m currently building the Academy, an AI-powered learning platform for CISSP candidates and security professionals.

As founding members, participants receive access to my new CISSP book, available exclusively on the platform as an interactive learning experience.

You’ll also receive 30 days of Pro access and an opportunity to help shape the platform through direct feedback.

If that sounds interesting, learn more here.

Say Hello

One thing I enjoy most about this platform is meeting other people in the field.

Hit reply and tell me:

• What brought you here

• What you do

• What you’re working on

• What you’d like to learn next

I read every response.

For decades, information security worked on a simple assumption: software is deterministic. Input parameter A into system B, and you’ll get result C every time, bounded by the strict logic a programmer wrote. Security controls (whether static code analysis, input validation, or access control matrices) were built around that predictability.

Artificial intelligence breaks that assumption.

Generative AI and autonomous agent architectures move enterprise systems into probabilistic, non-deterministic, and increasingly autonomous territory. ISC2 acknowledged this on April 2, 2026 by publishing Exam Guidance for Artificial Intelligence, which maps AI security topics across the eight existing CISSP domains. (For more on that guidance, see AI Security for the CISSP: What’s Changed.)

This article, the first in a series, covers the Domain 1 material: foundational concepts, governance frameworks, and the administrative controls a CISSP candidate needs.

Concept Coverage

To evaluate AI risk on the exam (or in practice), you need the vocabulary. Questions may test whether you can place a specific risk at the right point in the system lifecycle.

What is Generative AI?

Generative AI or Gen AI is ubiquitous and you’ve probably been using many associated services for a couple of years. Gen AI refers to AI systems that create new content (text, images, code, audio) rather than just analyze existing data. Examples span many aspects of our digital lives: text (Claude, ChatGPT, Gemini), images (DALL-E, Stable Diffusion), video (Sora, Runway), music (Suno), voice synthesis (ElevenLabs), and code (Cursor). When a vendor says their platform is “powered by GenAI,” they mean it produces output, not just classifies or scores inputs.

What is an AI Model?

An AI model is a mathematical structure trained on a dataset to recognize patterns, make predictions, or generate outputs, without being explicitly programmed with step-by-step rules. After training, the model is the brain of the AI system. It holds everything the system “learned” as numbers (the weights and biases) that determine how it responds to any new input.

While traditional software uses code written by human developers to process inputs (Input → Rules → Output), an AI model uses statistical weights and biases derived from training data to produce its output (Input → Statistical Weights → Output).

What is a Large Language Model (LLM)?

A Large Language Model (LLM) is a specialized subset of generative AI built on a deep neural network architecture (specifically the Transformer architecture) that uses “self-attention” mechanisms to model relationships between words in a sequence.

LLMs are trained on internet-scale text to understand, summarize, translate, predict, and generate “human-like” language. The training data is measured in tokens: a token is what the model treats as a unit of text, usually a word or a piece of a word. Modern LLMs are trained on trillions of them.

What is a Prompt?

A prompt is everything you (or the system) hand to the AI on a single request. That includes the user’s question, any instructions the application has added behind the scenes, and any documents or chat history the model is pulling in. It’s also the only entry point an attacker has, which is the entire basis of prompt injection (see below).

Training vs. Inference: The AI Lifecycle

You need to distinguish the two operational phases of an AI model’s life:

• Training is how the model gets built. The system shows the algorithm a big dataset over and over, and each pass nudges the weights and biases until the model gives the “right” answer often enough to ship. The dataset used is the training data, and if it’s biased, missing important cases, or just bad, the model can never outperform what it was shown.

• Inference is what the model does once it’s running. Every time someone asks a chatbot a question or a fraud detector scores a transaction, that’s inference: one run of the trained model. Almost everything a CISSP encounters in the enterprise is inference. Training is a much heavier, much rarer event.

Each phase has a different attack surface and calls for different controls.

The Training Phase (Development Lifecycle):

• The Process: The algorithm is exposed to a training dataset and adjusts its internal parameters (weights and biases) until it can perform its target task.

• Secure SDLC Focus: A sensitive supply-chain and development phase. The priority is the integrity of the training dataset.

• Primary Threat: Data poisoning. If an attacker injects malicious or biased records into the training pool, they can permanently alter the model’s behavior or implant hidden backdoors.

The Inference Phase (Production Operations):

• The Process: The trained model runs in production (API endpoint, web application, autonomous agent) and processes live inputs.

• Operational Security Focus: The priority is validating inputs and sanitizing outputs.

• Primary Threat: Prompt injection and model hijacking, where attackers manipulate live runtime inputs to execute unauthorized commands or bypass safety boundaries. Simon Willison coined the term “prompt injection” in September 2022. The Samsung ChatGPT IP-leak incident in April 2023 was its first widely-reported corporate consequence.

Why It’s Hard to Secure

AI systems introduce three architectural properties that legacy security frameworks can’t fully manage:

Non-Determinism

Generative AI models don’t produce identical outputs for identical inputs. LLMs are the clearest example: each next token is picked from a probability distribution, so the same prompt can produce two slightly different answers on two different calls. Image, music, and video models work the same way. Traditional security testing depends on reproducibility: find a bug, baseline behavior, confirm a fix. Non-determinism breaks all three.

The Black-Box Problem

A trained neural network has millions or billions of internal parameters. Decisions emerge from those parameters all at once. There’s no sequence of if-then rules a human can follow. When a model denies a credit application or flags a transaction as fraud, no one can point to the specific reason. The model just produces an output.

In terms of the CISSP, that hits Traceability: the ability to verify, audit, and recreate why an action was taken. After an incident, reconstructing what the AI “saw” and “decided” requires specialized logging of the inputs that went in (prompts, retrieved documents, prior context) plus the outputs and confidence scores that came back. Without that logging, you can’t answer what every regulator, auditor, and exec will ask after an AI incident: “Why did it do that?”

Hallucinations

A hallucination is when a generative model confidently produces false information that looks plausible. The model generates output based on statistical patterns in its training data. There’s no internal step that checks whether that output is true. So it can invent names, citations, statistics, or quotes that don’t exist.

The CISSP implication is direct. AI outputs are unverified data. The professional who acts on them is the one who answers for it, in court and in the boardroom.

Frameworks and Regulation

Governments and standards bodies are still catching up to AI. Domain 1 expects you to know how the major frameworks fit into a compliance posture.

Standardized Security Frameworks

NIST AI Risk Management Framework (AI RMF 1.0) is the most cited voluntary framework for structuring an AI security program. It organizes work into four core functions:

• Govern: Establish a culture of risk management, policies, and organizational alignment.

• Map: Contextualize the AI system, identify boundaries, and map specific risks.

• Measure: Quantify, analyze, and track identified risks through empirical testing.

• Manage: Allocate resources to respond to mapped and measured risks dynamically.

These aren’t sequential steps. Govern sits across the whole framework as the policy and accountability layer, while Map, Measure, and Manage form a continuous feedback loop on top of it. In practice, Govern is also the function organizations may underinvest in the most.

The 40-page framework gives you the principles. The companion NIST AI RMF Playbook is where the operational guidance lives. If you’re implementing rather than briefing, you need both. NIST has also published a Generative AI Profile (NIST AI 600-1) that applies the four functions to GenAI-specific risks like hallucinations, data exposure, and misuse.

ISO/IEC 42001 (Artificial Intelligence Management System) is the certifiable counterpart to the NIST framework: a third-party-auditable management system that adds an outward-facing AI System Impact Assessment (consequences for external individuals and groups) on top of an ISO 27001-style structure. It also aligns with EU AI Act compliance expectations, which makes it the more useful choice for companies with European exposure. The most common pattern is to deploy NIST first to build taxonomy and lifecycle discipline, then layer ISO 42001 on top for external attestation. The common failure mode is starting both at once and finishing neither.

Global AI Regulation

CISSPs don’t need to be lawyers, but you do need to understand regulatory risk. The most prominent example is the EU AI Act, which classifies AI systems by risk tier:

• Unacceptable Risk: Systems that threaten human safety or rights (e.g., government social scoring) are banned outright.

• High Risk: Systems used in critical infrastructure, medical devices, or employment. These require pre-market assessments, logging, and human-in-the-loop oversight.

• Limited Risk (Specific Transparency): Chatbots, deepfakes. Users have to be told they’re interacting with AI.

• Minimal/No Risk: Spam filters, video games. No additional regulatory intervention required.

The Act reaches beyond the EU. Article 2 says it applies to anyone selling an AI system into the EU, anyone using one inside the EU, and any company anywhere whose AI outputs end up being used in the EU. If you have European customers, you’re in scope no matter where you’re headquartered.

Data, Bias, and Ethics

AI security still depends on the CIA triad, but integrity grows to include Data Quality and AI Ethics.

Data Quality (Garbage In, Garbage Out)

If the training dataset is poisoned, incomplete, or fundamentally skewed, the model’s outputs will be flawed, and the integrity of every downstream corporate decision goes with them. Security leaders need to vet data pipelines for accuracy, representativeness, and absence of tampering.

AI Ethics & Societal Adaptation

Ethics on the CISSP exam comes back to the ISC2 Code of Ethics (act honorably, protect society). In an AI context, that translates to:

• Fairness: Algorithmic decisions shouldn’t exhibit systemic bias against protected groups.

• Transparency: Stakeholders should be able to understand how a model reaches its conclusions.

• Human Oversight: Critical actions, especially those affecting livelihoods, physical safety, or financial assets, need human validation rather than fully automated execution.

The Disinformation Suite: Deepfakes and Automated Misinformation

Two non-technical AI threats sit squarely in Domain 1’s governance and societal-adaptation area. Deepfakes (AI-generated voice, image, or video impersonations) are now used in executive-targeting fraud and social engineering, blurring the line between identity verification and content verification. Automated misinformation campaigns use generative AI to produce false content at industrial scale and distribution speed, complicating brand defense, election integrity, and customer trust. Both call for governance responses (executive verification protocols, public-communications playbooks, third-party content-authenticity standards) rather than purely technical ones, which is why they belong in a Domain 1 risk conversation, not a firewall ruleset.

Building the Program

How do you turn the regulatory and architectural concepts into something operational? Start with administrative and organizational changes.

The Chief AI Officer (CAIO) or “AI Czar”

When organizations adopt AI at scale, a leadership gap often opens between the CISO (security) and the CDO/CIO (data and enablement). Enter the Chief AI Officer.

The CAIO aligns AI strategy with business goals, manages AI-specific compliance, and coordinates with the CISO on security architecture. If you don’t have a CAIO, a formal AI Governance Board (legal, compliance, engineering, security) fills the void.

The AI Acceptable Use Policy (AUP)

Before buying expensive security tools, set clear guidelines. An AI AUP should explicitly define:

• Approved Platforms: Distinguish approved enterprise-tier AI platforms (which guarantee data privacy) from public, consumer-grade tools (which may ingest user prompts for training).

• Classification Constraints: Restrict sensitive intellectual property, source code, and PII from being submitted to unauthorized external LLMs.

• Code Review Requirements: Any software written with AI coding tools goes through standard SAST/DAST security reviews before deployment.

Verify then Trust

For AI, every input (prompt) sent to a model needs sanitization to prevent prompt injection, and every output coming back gets treated as untrusted, hostile data. You can’t assume the model will always return benign, safe, or accurate content. The pattern echoes Zero Trust’s “never trust, always verify,” applied to LLM I/O. The OWASP LLM Top 10 (LLM01: Prompt Injection) is the canonical taxonomy.

Cost-Benefit Analysis

AI deployments have real resource overhead. Beyond software subscriptions, deep learning needs GPU compute and storage at scale. A formal cost-benefit analysis weighs efficiency gains against the costs of implementation, continuous monitoring, model retraining, and new compliance liabilities.

Adapting Your Existing Program

Your existing Domain 1 risk management processes also need to adapt to AI-related assets:

• Asset Inventory: Build a registry of AI models, training datasets, fine-tuning pipelines, and vector databases. Treat them as critical enterprise assets.

• Risk Register Integration: Document new threat profiles (prompt injection, training data poisoning, model inversion, and AI-augmented attacks like automated phishing and vulnerability discovery at scale) and assign risk owners.

• Third-Party Risk Management (TPRM): When evaluating SaaS vendors, audit AI usage. Do they use customer data to train their models? Are their LLM dependencies hosted in secure environments?

In the Next Article...

With governance and policy in place, the next article moves to Domain 2 (Asset Security): how to classify, protect, and dispose of the data pipelines, model weights, and compute assets that drive AI in the enterprise.

I’m building a CISSP prep platform centered on the idea that the exam tests your judgment and application of concepts, not rote memorization. It includes an adaptive CAT practice-exam engine, concept-coverage analytics, question-by-question scoring, exam-readiness tracking, mindset pattern analysis, weak-area drills, a custom study planner built around your schedule and requirements, my integrated book, and spaced repetition. It’s in limited beta. To request an invite (free extended Pro access in exchange for your feedback), join the waitlist at academy.balancedsec.com, and I’ll send invites on a rolling basis.

AI-native platforms have broken that math. Every prompt sent to a frontier model, every retrieval-augmented query, every personalized explanation routes through a metered inference call. The marginal cost per trial signup is no longer near zero. It’s measurable, often material, and almost always non-recoverable when the user doesn’t convert. The economics of free trials need a fresh look.

I’m working through this decision right now for a CISSP exam prep platform I’m building. The product combines a large proprietary practice-question bank, an adaptive CAT engine, an in-app full-text version of my book CISSP: A Balanced Approach, and AI features that lean heavily on premium models: a personalized in-context coach, mindset pattern analysis, and dynamic answer rationales that go beyond what I’ve written. Every one of those AI features costs real money per use. Free-trial design has become a three-way decision: marketing reach, security exposure, and unit economics.

Here is my reasoning through that decision and the security trade-offs each option carries.

Opt-In vs. Opt-Out

The first fork is whether to require a credit card before someone gets to use the product. Opt-in (no card required) is frictionless and historically draws a larger top-of-funnel. Opt-out (requiring a card upfront) reduces sign-up volume but serves as a self-qualification gate. ChartMogul’s January 2026 SaaS Conversion Report, based on 200 B2B software products, puts hard numbers on the trade-off. Per 1,000 website visitors, an opt-in trial typically produces about 45 signups and 3.6 paying customers. An opt-out trial produces about 35 signups and 10.5 paying customers. So opt-in pulls roughly 30% more signups, but opt-out produces nearly 3x the paying customers. Stated as trial-to-paid conversion, no-credit-card trials sit in the 4-6% range, and credit-card-required trials sit around 30%, more than 5x higher.

For a conventional SaaS product, that’s a marketing decision. For an AI-native product, it’s also a threat-model decision because each model targets a different adversary class.

The opt-in failure mode is automated trial farming. With no financial identity at the door, attackers can use headless browser scripts (Puppeteer, Playwright), temporary inbox generators, and residential proxy networks (Bright Data, Oxylabs) to bypass standard IP-based rate limits. Once inside, two attacks run in parallel: (1) walking your REST endpoints to dump proprietary content like a test bank or curated explanations, and (2) hammering the most expensive AI features to drain inference credits for personal use, resale, or training a copycat model. The cost falls on you as non-recoverable compute.

The opt-out failure mode is payment fraud. Putting a card form at the top of the funnel attracts a different adversary: carders running stolen-card dumps against your checkout endpoint to validate live numbers, and abusers feeding single-use virtual cards (privacy.com, Revolut) that pass a $0 authorization and then go dead before the first real charge. The cost includes processor review fees, chargeback exposure, and merchant-account standing.

For my platform, I’m landing on opt-out for three reasons:

1. The compute exposure on opt-in is asymmetric. A single determined adversary with a residential proxy pool can extract thousands of dollars in inference cost in a weekend. Recovering it is not realistic. Recovering payment-fraud losses, by contrast, is a workflow that processors already run for me.

2. Self-qualification matters more when seats are expensive to serve. A ~30% conversion rate on a smaller pool of higher-intent users is a better fit for a product where every active trial user is burning real money in tokens.

3. It lets me push off device fingerprinting. This is the part nobody talks about. If I went opt-in, I’d need a custom abuse stack from day one: device fingerprinting, behavioral signals, residential-ASN detection, link-graph clustering. With opt-out, the identity boundary moves to the financial system, which is the part of the internet where identity already costs something to fake.

How the Posture Slims: Shifting Identity to the Financial Layer

The core idea: in opt-in, you build a “proxy identity” yourself because emails are free and unlimited. In opt-out, you outsource identity to the card network, where supply is constrained, fraud is regulated, and the processors already operate a global tracking layer.

That outsourcing works regardless of which processor you pick. Stripe is what I’m using, but the same architectural pattern applies to Adyen, Braintree, Chargebee, Paddle, or any modern PSP with a managed checkout flow and a fraud product. What you get for free, in rough order of value:

1. Card fingerprinting across the processor’s network. Modern processors see the same card across many merchants. Stripe alone processed $1.9 trillion in transaction volume in 2025, and reports that 90% of the cards used on its network have been seen more than once across different merchants. Adyen and Braintree have comparable cross-merchant signals on a smaller scale. A card with a history of trial-abuse showing up at other merchants will get flagged before it ever creates an account on your platform.

2. Built-in trial-abuse models. Most processors now ship a free-trial-abuse product as a one-click feature rather than a custom build. Stripe Radar’s Free Trial Abuse Prevention, launched in 2025, claims 90% accuracy at flagging signups likely to violate trial terms. In its first two months across four high-growth AI businesses, Stripe blocked over 550,000 high-risk trials and reported $4.4M in prevented downstream compute losses. Other processors offer analogous features under different names. The point is that the processor’s centralized view of card and bank identification number (BIN) behavior is doing work that you’d otherwise have to build in-house.

3. Lightweight pre-checkout gating. A few cheap filters in front of checkout keep the customer database clean and stop low-effort scripts before they reach the payment layer:

• Disposable email blocks. Server-side validation against a maintained list of throwaway domains. Free or low-cost APIs (NinjaPear, DeBounce, AbstractAPI) handle this.

• Email alias and syntax checks. Block +alias spamming and obvious typos at the form level.

• A bot challenge at signup. Cloudflare Turnstile, hCaptcha, or Google reCAPTCHA. Low friction for humans, high friction for scripts.

With this combination, an abuser has to spend real capital on unique, valid credit cards to automate signups. The economics of attacking the platform invert. The custom device-fingerprinting stack you’d need for opt-in becomes unnecessary on day one.

The New Threat Landscape: Payment-Layer Vulnerabilities

The opt-out posture, however, is slimmer, but not threat-free. Three vectors carry over from the broader card payments ecosystem, regardless of which processor you choose. The mitigations are processor-agnostic in concept, and I’ll note how they look in Stripe specifically since that’s what I’m implementing.

1. Card Testing

A public card form is a target for card testing: criminals with stolen-card dumps fire $0.50 to $1.00 validation charges to find live numbers. Modern processors detect and block most of these, but two costs are still yours:

• Review fees on the paid fraud tier. Stripe’s Radar for Fraud Teams add-on costs 7¢ per screened transaction (reduced to $.02 if you’re on Stripe’s standard processing pricing). An overnight botnet of 15,000 attempts can saddle a Fraud Teams subscriber with anywhere from $300 to $1,050 in review fees, depending on tier, even though none of the charges went through. Adyen and Braintree’s enterprise risk products follow the same per-transaction pricing model.

• Auth-rate damage. A flood of declines hurts your acceptance-rate signal at the network.

Mitigation, in general: rate-limit your payment endpoints at the network layer (Cloudflare, your WAF, or your edge proxy), and put a bot challenge in front of checkout so high-velocity scripts can’t reach the processor’s backend at all. Stripe Checkout also ships its own managed CAPTCHA, which kicks in dynamically when Stripe’s models detect card-testing patterns.

2. Single-Use Virtual Card Drain

The more sophisticated abuser doesn’t use stolen cards. They use legitimate single-use virtual cards from services such as Privacy.com or Revolut.

• The loophole. A trial signup runs a $0 authorization, which the virtual card passes. The abuser then closes the card. When the first real charge fires at the end of the trial, it’s declined. The attacker has now extracted the full trial period of premium AI usage for free.

• The detection signal. Virtual and prepaid cards have identifiable BIN ranges. Most processors can flag them.

Mitigation, in general: if this pattern shows up in your data, write a rule against prepaid and known-virtual BINs. In Stripe, this is a custom rule in Radar for Fraud Teams. Other processors expose similar BIN targeting via their rule engines. The cost is that some legitimate users (people who genuinely prefer virtual cards for privacy) get blocked, so you can choose whether to enable this on day one, or only once the data shows it’s a real problem.

3. Friendly Fraud and Card-Network Monitoring

The leading cause of opt-out chargebacks is friendly fraud: a real user signs up, forgets to cancel, sees the charge on their statement, and disputes with their bank instead of asking you for a refund. The threshold of concern is the dispute rate.

• Industry standard threshold. Above 0.75% dispute rate, you’re under processor scrutiny. Above 1%, you risk being placed in Visa’s monitoring program. Stripe explicitly recommends staying below 0.75% to avoid being escalated.

• Card-network programs. Both card networks run monitoring programs that can ultimately terminate your processing relationship if dispute activity stays elevated. Visa’s Acquirer Monitoring Program (VAMP) replaced the older VDMP and VFMP programs, with enforcement live since October 1, 2025. Mastercard’s Scam Merchant Monitoring Program (SMMP) takes full effect on July 24, 2026, with confirmed scam activity resulting in immediate termination of Mastercard and Maestro processing.

Mitigation, in general: make the trial reminder and cancellation flow nearly impossible to misuse against you. An email 3 days before the charge clearly stating the upcoming amount, plus a one-click cancellation in the user dashboard, converts most would-be disputers into either renewals or clean cancellations. In Stripe specifically, the customer.subscription.trial_will_end webhook is the trigger point. Other processors expose equivalent events.

TL;DR

The marginal-cost economics of AI-native platforms make the free-trial decision a security- and unit-economics decision, not just a marketing one. Opt-in trials draw a larger top-of-funnel but expose you to compute exfiltration via automated farming. Opt-out trials draw a smaller, higher-intent funnel and shift your residual risk into the payment layer, where the processor’s global fraud signal does most of the work you’d otherwise build in-house.

For an AI-native product where each active trial user burns real tokens, the opt-out posture plus pre-checkout gating (disposable email blocks, a bot challenge, and a clean cancellation flow) is the architecture I’m going with. You don’t get an enterprise-grade anti-abuse stack out of it, but you get most of the way there for a fraction of the engineering cost, and you keep your focus on the product instead of fighting botnets.

As organizations rush to harness and deploy autonomous AI agents for software development, security professionals face a daunting challenge: how do we secure a system that relies on probabilistic reasoning rather than deterministic code?

We’re all looking for ways to bring some secure sanity to this new development paradigm. I started my AI-assisted development experimentation way back in the early days (last year) by spinning up Claude directly in a cloned repo on my development machine (please don’t do that). As we’ll see below, giving an agent that much unfettered access can lead to unfortunate outcomes. Put simply, an agent should never run directly on a developer’s bare-metal machine with full filesystem access, or even broad local access.

The best approach is isolation.

That’s why I wanted to write this article. For CISSP holders and cybersecurity leaders, securing AI dev tools means moving past “prompt engineering” (asking AI to be good) and instead thinking in terms of Harness Engineering.

This short guide provides an overview of what harness engineering is, why it represents an important security boundary for AI agents, and how you can lead an assessment to protect your organization.

What is “Harness Engineering”?

The term harness engineering, coined by Mitchell Hashimoto in early 2026, refers to “designing the environment, specifying intent clearly, and building the feedback loops that allow agents to autonomously build and maintain software.” You could generalize this as defining how modern autonomous systems must be structured:

• The Model is the “Brain”: An LLM (like Claude or GPT) provides the raw reasoning, language processing, and statistical inference. However, in isolation, a model can’t interact with the world.

• The Harness is the “Hands, Eyes, and Guardrails”: the deterministic software infrastructure that wraps around the model. It manages the memory modules, tool registries, database/API connectors, execution loops, and safety checkpoints.

For security professionals, harness engineering encompasses the discipline of designing the control systems that govern how an AI agent perceives its environment, selects actions, and validates its outputs.

Harness components generally fall into two classic control-theory categories:

1. Guides (Feedforward Controls): Active constraints that direct the agent before it acts. Examples include system prompts, constraint documents, and organizational boundaries (such as a CLAUDE.md or AGENTS.md file).

2. Sensors (Feedback Controls): Mechanisms that observe and validate the agent’s behavior after it acts. Examples include real-time validation loops, output parsers, and automated evaluation suites.

Why the Harness is a Better Security Boundary

Early implementations of AI assistants relied on “prompt guardrails” (e.g., “Do not delete files” or “Never disclose system keys”). However, prompts are mere suggestions to a probabilistic model. Under complex multi-step reasoning, context dilution, or adversarial inputs, these prompt-based walls reliably collapse.

And of course, you know this: You wouldn’t secure a database with just a comment like ‘please don’t drop tables.’ You’d write a permission system.

The harness is that permission system.

Without a secure harness, your organization is exposed to severe, agent-specific risks:

• Excessive Autonomy and Tool Abuse: An agent might exploit overly permissive tools to execute high-impact actions without human-in-the-loop validation.

• Indirect Prompt Injection: A malicious payload hidden in an external data source (like a customer PDF, a PR comment, or a web page) can hijack the agent’s reasoning loop. If the agent has a privileged toolset, this injection instantly escalates to remote code execution.

• Malicious Repository Configurations: In tools like Claude Code, repository configuration files (which historically were passive metadata) now control active execution paths. Disclosures such as CVE-2025-59536 and CVE-2026-21852 demonstrated that simply opening or cloning an untrusted project could enable a rogue configuration to execute arbitrary code or steal API credentials.

How to Conduct an AI Agent Harness Assessment

To help your engineering teams transition from risky “vibe coding” to a more hardened, compliant deployment, you can lead a security assessment of their AI agent harness.

This structured assessment methodology maps the bleeding-edge AI risks back to traditional CISSP domains.

Step 1: Map the Trust Boundaries (Asset Security & Architecture)

Before evaluating code, you need to map the data flows. Treat the AI agent as a highly privileged, non-human identity.

• Inventory Entry Points: Where does the agent ingest data? (e.g., User prompts, API responses, RAG databases, and/or external URLs).

• Define Trust Zones: Where does the trusted system end and untrusted data begin? Remember: any data retrieved by the agent (including tool outputs) must be treated as untrusted input.

• Identify Secrets: Ensure the agent’s harness doesn’t have direct access to raw SSH keys, cloud credentials, or long-lived API tokens. Instead, verify it uses scoped, short-lived tokens injected at runtime (typically implemented using OAuth 2.0).

Step 2: Threat Modeling

While the classical Microsoft STRIDE framework is great for static applications, autonomous agents break the idea that software has fixed, predictable roles. We previously explored several threat modeling frameworks, including MITRE ATLAS, and used MAESTRO alongside ATLAS.

Instead of fixed roles, Agents simultaneously behave as users, services, and data pipelines. For the purposes of this discussion, let’s conduct a threat modeling session using STRIDE+A, where “A” stands for AI Agent-Specific Attacks:

Step 3: Audit Tool Permissions & Sandboxing (Identity & Access Management)

Evaluate the physical boundaries of the agent’s execution environment.

• Isolate the Host: As I mentioned at the top, the agent should never run directly on a developer’s bare-metal machine with full filesystem access. It must run inside an ephemeral container (such as a DevContainer), a microVM, or a remote sandbox.

• Enforce Least Privilege: Does the agent have “wildcard” access (e.g., Bash(*))? Scrutinize and restrict allowed commands.

• Network Egress: Is network traffic wide open? Establish a strict network proxy with an allowlist limited to required endpoints (like the LLM provider and specific package registries) to prevent data exfiltration.

Step 4: Assess the Guides and Sensors (Security Assessment & Testing)

Review how the engineering team is instructing and observing the model.

• Feedforward Check: Review system instructions and constraint files (e.g., AGENTS.md or CLAUDE.md). Are they under version control? Are they concise (ideally under 150 lines) to avoid context bloat?

• Feedback Check: Does the harness use deterministic validation loops? If the agent edits code, does a PostToolUse hook automatically run tests and linters before committing?

• Human-in-the-Loop Gates: Ensure that destructive, financial, or externally visible actions (like pushing to production or deploying code) require explicit, independent human authorization.

Step 5: Implement Continuous Automated Scanning (Security Operations)

Unfortunately, we can’t treat this assessment as a one-time gate. The threat landscape of Model Context Protocol (MCP) servers and agent skills is evolving daily.

• Static Configuration Auditing: Integrate tools like AgentShield (ecc-agentshield) into your team’s local environments or CI/CD pipelines. These scanners continuously look for hardcoded secrets, overly permissive tool definitions, and risky MCP server configurations before code is committed.

• Behavioral Regression Testing: Introduce frameworks like the OWASP Agent Security Regression Harness. This allows security teams to run executable security regression scenarios against the agentic application, verifying that prompt or model updates do not introduce new security failures or allow goal hijacking.

What are you using to keep your development environment secure?

The structural signatures that gave GTIG confidence in the assessment are telling: the exploit script contained a hallucinated CVSS score in its docstrings (the in-code comments left by the developer), a textbook Python format characteristic of AI-generated code, down to extra code that prints the terminal output in color. These are small stylistic tells that a human exploit developer wouldn’t bother with.

That’s the headline finding from GTIG’s Q2 2026 AI Threat Tracker, published May 11. The TLDR version: adversaries have moved beyond basic experimentation to industrial-scale use of generative AI, and they’re doing several different things with it. Google is calling out specific groups by name, including state-sponsored clusters from China and North Korea, financially motivated cybercrime crews like TeamPCP, and Russia-linked operators targeting Ukraine. Each one uses AI at a specific phase of the attack lifecycle.

Below, I walk through what they’re doing and where it lands, mapping each use to the part of the kill chain a CISSP holder already operates against.

Here’s a quick tour.

Researching their targets

Before the attack comes the homework. Adversaries are using large language models to map out their victims. They generate detailed organizational hierarchies for departments such as finance and HR, identify which third-party vendors a target enterprise relies on, and even fingerprint the specific make and model of the computer a high-value executive uses. In one documented case, a threat actor asked an AI model to identify a target’s laptop from photographs.

Two China-linked actors stand out. The cluster GTIG tracks as UNC2814 prompts Google’s Gemini to act as a “senior security auditor” or “C/C++ binary security expert” before asking it to analyze the firmware of embedded devices like TP-Link routers. A separate China-linked group used a public agentic framework called Hexstrike, combined with a knowledge-graph memory system, to maintain persistent state on a target’s attack surface and pivot autonomously between reconnaissance tools.

The shared pattern: AI as a research force multiplier. Tasks that used to take a human analyst hours of OSINT can now happen at machine speed.

Developing new exploits

The identified zero-day matters for what it reveals about how AI changes vulnerability research. The 2FA bypass came from a hardcoded trust assumption in the developer’s authentication logic. It’s a high-level semantic flaw that fuzzers and static analyzers routinely miss. AI models, reading the developer’s intent across the codebase, increasingly find them.

Writing stealthier malware

AI also appears inside the malware itself. Sometimes it’s used to hide the malicious code. Sometimes it’s used to operate it in real time.

Two Russia-linked malware families, CANFAIL and LONGSTREAM, target Ukrainian organizations and contain LLM-generated decoy code. LONGSTREAM checks the system’s daylight saving status 32 times in a row, for no operational reason except to make the malicious file look like routine administrative work.

And then there is PROMPTSPY. The Android backdoor sends the device’s current screen layout to Google’s Gemini API and asks the model where to tap next. The model returns coordinates. The malware taps. ESET first identified the malware. GTIG extended the analysis to describe what they call the first widely-reported example of an AI service driving real-time malware behavior in the wild.

Industrializing account abuse

AI providers cap usage. Attackers don’t want to be capped. So they industrialized account abuse.

Two China-linked clusters, UNC6201 and UNC5673, run automated registration pipelines that bypass CAPTCHA and SMS verification to create premium accounts at scale. Middleware aggregators such as Claude-Relay-Service and CLIProxyAPI allow attackers to pool API keys from Gemini, Claude, and OpenAI accounts via a single OpenAI-compatible interface. Anti-detect browsers mask the fingerprints. The whole ecosystem looks professionalized. GTIG documents five tool categories with named examples for each.

Manufacturing scale

The same scaling impulse shows up in influence operations. The pro-Russia campaign Operation Overload used suspected AI voice cloning to make real journalists appear to say things they never said, splicing the synthetic audio into manipulated video to lend credibility to false narratives. Russia, Iran, China, and Saudi Arabia are all using AI to produce political content at volume, though most of the breakthrough capability claims for these campaigns have not yet appeared in observed operations.

Going after the AI supply chain

The frontier models themselves are well-defended. So attackers are going after the connecting layers: the libraries, the package managers, the skill marketplaces, and the API gateways that AI systems depend on.

A cybercrime cluster known as TeamPCP (also tracked as UNC6780) compromised the GitHub repositories of LiteLLM, BerriAI, Trivy, and Checkmarx in late March 2026. They embedded a credential stealer called SANDCLOCK that extracted AWS keys and GitHub tokens from affected build environments. The stolen credentials were sold to ransomware and data-theft-extortion groups, turning a single supply chain compromise into multiple downstream payloads.

A parallel pattern hit the OpenClaw skill marketplace. Researchers found malicious packages distributed as legitimate skills, containing hidden routines that abused OpenClaw’s elevated system access to run unauthorized code. Both incidents are supply chain attacks specifically targeting the AI dependency layer.

How does MITRE ATLAS help?

All six behaviors above need names. Once a threat has a technique ID, you can record it in a risk register, assign an owner, select a control, and audit the result. MITRE ATLAS is the canonical vocabulary for AI-specific adversary tactics, the AI extension of MITRE ATT&CK. I previously wrote a longer piece on ATLAS for readers who want the deeper context.

A question worth asking follows: how well does ATLAS cover what GTIG just documented?

The answer is partial. Some of GTIG’s findings map cleanly to pre-existing ATLAS techniques. Several map to techniques MITRE added or updated in their early May (v5.6.0) release. A handful have no direct ATLAS coverage, but the framework is responsive, and it’s still catching up.

Already in the catalog

Four of GTIG’s findings map to ATLAS techniques that predate the May update:

• PROMPTSPY’s autonomous orchestration is fully covered. AML.T0040 (AI Model Inference API Access), AML.T0103 (Deploy AI Agent), AML.T0102 (Generate Malicious Commands), and AML.T0053 (AI Agent Tool Invocation) describe the architecture pattern PROMPTSPY uses.

• LLM account abuse and middleware proxies map to AML.T0008.005 (AI Service Proxies), AML.T0021 (Establish Accounts), and AML.T0016.002 (Obtain Capabilities: Generative AI). These were added in earlier ATLAS releases.

• TeamPCP’s AI supply chain compromise maps to AML.T0010.001 (AI Supply Chain Compromise: AI Software).

• Operation Overload’s voice-cloning campaign maps to AML.T0088 (Generate Deepfakes), the technique GTIG used in their own appendix to attribute this finding. T0088 covers the synthesis of high-fidelity audio and video to impersonate authoritative figures.

These map straight into a register today without waiting for anything new.

Just added

ATLAS Data v5.6.0 (atlas.mitre.org, view the diff) added or updated four entries relevant to the behaviors above:

• Deepfake-assisted phishing (AML.T0052.001, new) is a phishing-specific subtechnique that extends the pre-existing T0088 Generate Deepfakes. GTIG didn’t document a deepfake-phishing-specific incident in this report, but ATLAS's addition of this subtechnique signals the framework’s anticipation of voice cloning moving from influence operations into phishing pretexts (CEO fraud, executive impersonation).

• Code repository reconnaissance (AML.T0095.000, new subtechnique under the new parent AML.T0095 Search Open Websites/Domains) covers the GTIG-documented use of public code repos for AI-related secrets and configuration discovery.

• LLM Jailbreak (AML.T0054, updated) now reflects persona-driven prompting patterns, including acting as a “senior security researcher” jailbreak that GTIG attributed to UNC2814.

• OpenClaw command-and-control case study (AML.CS0051, updated) formalizes the OpenClaw skill marketplace compromise pattern.

The release timing: MITRE published v5.6.0 on May 4. GTIG published their threat report on May 11. The framework was updated in close parallel with the threat intelligence cycle.

Not yet in the catalog

Three GTIG findings have no dedicated ATLAS technique:

• AI-developed zero-day exploits. The lead finding from the GTIG report, the criminal-actor 2FA bypass developed with AI assistance, doesn’t have a specific ATLAS technique. The closest is AML.T0017 (Develop Capabilities), which is generic. There’s no “adversary uses AI to discover vulnerabilities in target systems” entry.

• AI-generated polymorphic malware code. The LLM-generated decoy code in CANFAIL and LONGSTREAM, including LONGSTREAM’s 32 daylight-saving checks, has no dedicated technique. ATLAS covers prompt-side obfuscation under AML.T0068, but adversary use of AI to generate malware code with camouflage logic isn’t named.

• Agentic frameworks as offensive tools. The PRC-nexus actor using Hexstrike with the Graphiti memory system for autonomous reconnaissance has no matching ATLAS entry. The framework covers adversaries' use of AI inference APIs and includes AML.T0103 for deploying defender- or victim-owned agents, but offensive use of full agentic frameworks against victims remains a gap.

The gap is ATLAS-specific. GTIG’s own appendix maps these findings to conventional MITRE ATT&CK techniques: T1587.001 (Develop Capabilities: Malware) for CANFAIL and LONGSTREAM, T1587.004 (Develop Capabilities: Exploits) for the AI-developed zero-day, T1027.014 (Polymorphic Code) for PROMPTFLUX, and T1027.016 (Junk Code Insertion) for the decoy code patterns. Traditional ATT&CK covers the underlying behaviors. ATLAS hasn’t yet named them in AI-specific form.

The gap is informative. The biggest single GTIG finding (AI used to develop a real zero-day exploit) sits in the no-direct-mapping bucket. Frameworks update on incident-disclosure timelines, and it makes sense that the threat intelligence is ahead of the vocabulary.

How to harness ATLAS

Four things a CISSP-led security program can do this quarter with what’s in front of us:

1. Map ATLAS technique IDs into your existing risk register. The directly-mapped findings are the easy lift. Risk: AI dependency supply chain compromise. Threat: AML.T0010.001. Mitigation: AML.M0023 AI Bill of Materials and AML.M0014 Verify AI Artifacts. Owner: AppSec team. Same structural pattern your ATT&CK-anchored entries already use, with ATLAS-formal mitigation IDs rather than generic supply chain practices.

2. Add the v5.6.0 techniques where they apply. Deepfake-assisted phishing belongs in your security awareness training program now, not next year. The technique has a corresponding mitigation (AML.M0034 Deepfake Detection), and your tabletop exercises can use it as a scenario starter. Code repository reconnaissance fits into your secrets management and source control hygiene program.

3. Document the gaps as monitoring needs. This is the part most risk registers will miss. For each GTIG finding that doesn’t have an ATLAS technique (AI-developed zero-days, AI-generated polymorphic malware, offensive agentic frameworks), the register entry should explicitly say “no standard taxonomy entry; monitor framework releases for coverage.” A risk register that names where the framework has gaps is stronger than one that pretends the gaps don’t exist.

4. Track ATLAS releases. The framework moved from “no v5.6.0” to “four directly-relevant new entries” in less than a month after the underlying incidents became publicly known. Release tags live at github.com/mitre-atlas/atlas-data/releases. The canonical user-facing technique pages are at atlas.mitre.org. Subscribing to release notifications is a one-time setup with ongoing value.

Six attacker behaviors, named groups behind each, and a framework that’s partially there. Your risk register needs both the techniques the framework has named and the gaps it hasn’t.

Are you seeing any of these six behaviors already in your environment? Reply or drop it in the comments.

AI governance has moved from voluntary guidance to enforceable obligation in less than two years. The EU AI Act came into force on 1 August 2024. NIST released its AI Risk Management Framework (AI 100-1) in January 2023. ISO/IEC 42001, the first ISO standard for an AI management system, was published in December 2023.

For CISSP holders, the practical questions are how they fit together and what existing ISO 27001 work actually transfers. In this article, we dive into a comparison of NIST AI RMF and ISO/IEC 42001: how they differ, where they overlap, and which fits which use case.

The two frameworks at a glance

NIST AI RMF (AI 100-1). Published January 2023 by the U.S. National Institute of Standards and Technology (NIST). Four core functions: Govern, Map, Measure, and Manage. Seven trustworthiness characteristics. Four implementation Tiers. The Playbook companion document elaborates on 72 subcategories with suggested actions. NIST AI 600-1 (July 2024) introduces a Generative AI Profile that includes 12 GAI-specific risks. Voluntary, non-certifiable, free to download.

ISO/IEC 42001:2023. The AI version of ISO 27001. Published December 2023, it follows the same management system pattern that any 27001-certified organization already operates: leadership commitment, risk assessment, controls, internal audit, management review, and continual improvement. Clauses 4 through 10 are identical in structure to those in ISO 27001 and use the standard ISO management system template (i.e., “Annex SL-conformant”) as do other ISO management system standards. What’s new is the AI-specific control catalog in Annex A: 38 reference controls covering AI policy, roles, resources, system impact assessment, lifecycle management, data, transparency, intended use, and third-party relationships. As with 27001, you produce a Statement of Applicability (SoA) that lists every control and provides a written justification for its inclusion or exclusion. Unlike NIST AI RMF, you can earn a certificate through an accredited third-party audit. Note that reading the standard requires purchasing a license from ISO.

The two were designed to be readable together. ISO 42001 clause 4.1 NOTE 1 explicitly cross-references NIST AI RMF for AI role types and lifecycle stages.

What transfers from existing ISO 27001 work

If you have experience with ISO 27001, that muscle memory does most of the work. The ISO Survey 2024, published by ISO/IAF CASCO in September 2025, reports 96,709 ISO 27001 certificates and 179,877 sites globally. ISO 27001 ranks fourth among all ISO management system standards by certificate volume, behind only ISO 9001, ISO 14001, and ISO 45001. At a 179,877-to-96,709 ratio of sites to certificates, the average certified organization runs 1.86 sites under one certificate scope.

What that engagement gives you:

1. The audit cadence is identical. Stage 1 documentation review, Stage 2 on-site assessment, annual surveillance audits in years one and two, full recertification in year three. ISO 27001 audit capability (internal audits per clause 9.2, certification body relationships, surveillance preparation) transfers the management-system half of ISO 42001. The AI-specific half (model risk, AI System Impact Assessment, and the new control catalog) is a separate competency that typically requires AI domain expertise, which can be sourced internally or from specialists.

2. The Statement of Applicability is the document that gets audited. Both standards require it in the same form: a list of every Annex A control, justification for inclusion or exclusion, and management sign-off. ISO 42001 trades 27001’s 93 information security controls for 38 AI-specific ones. The document discipline transfers.

3. CISSP Domain 1 already covers both. ISC2’s Exam Guidance for AI (April 2026) cites NIST AI RMF and ISO 42001 as required compliance-tracking frameworks for AI governance professionals.

4. Top management commitment, internal audit, management review, and corrective action. Same wording in 27001, 42001, and other ISO management system standards. If you’ve run any of them, you already know these clauses.

5. A crosswalk already exists. NIST’s AI Resource Center hosts a community-submitted 72-row crosswalk pairing every NIST AI RMF subcategory with the relevant parts of ISO 42001. GOVERN maps to leadership and policy areas. MAP to context-setting and impact-assessment processes. MEASURE maps to monitoring and verification. MANAGE to management review and continual improvement. NIST hosts the crosswalk but doesn’t endorse it (the crosswalk’s page notes that inclusion doesn’t imply NIST endorsement of either framework’s coverage). Use it as a starting reference for your own verification work.

That covers maybe 60% of the work. Here’s where the muscle memory breaks.

What doesn’t transfer

NIST AI RMF asks for use-case-specific Profiles. An organization deploying both a recommendation engine and a clinical decision support system needs two different Profiles, not one. ISO 27001’s Statement of Applicability operates at the organizational level rather than on a per-use-case basis, so this is new ground for practitioners coming from ISO 27001.

ISO 42001 has an outward-facing AI System Impact Assessment (clause 6.1.4) with no clean 27001 analog. Internal risk assessment looks at consequences for the organization. Impact assessment looks at consequences for individuals, groups, and societies external to it. The closest 27001 analog is supplier risk, but it isn’t the same shape.

Annex A is leaner than 27001’s. 38 controls across 9 categories versus 27001’s 93. Lean by design, but it places more weight on the auditor's and implementer's judgment in the SoA. Two 42001-conformant organizations with identical risk profiles can end up with materially different control sets.

A climate change clause. ISO 42001 clause 4.1 requires the organization to determine whether climate change is a relevant issue. Inherited from a harmonized update that flowed through 27001, 9001, and other ISO management system standards in 2023 and 2024. The energy footprint of large-model training and inference makes this a real audit-interpretation question, not a paper one.

NIST has a dedicated Generative AI Profile (AI 600-1). ISO 42001 is a general-purpose standard. If your AI estate is mostly GenAI, AI 600-1’s 12 GAI-specific risks give you a more specific risk taxonomy than Annex A does.

Which to lead with

Lead with NIST AI RMF when your audience is the engineering organization, your regulatory exposure is U.S.-centric, or you want internal risk discipline before external proof. NIST is free, easy to adopt as a taxonomy, and doesn’t require a relationship with an audit body.

Lead with ISO 42001 when your audience includes procurement, customers, or regulators seeking third-party assurance. When your exposure is EU AI Act-adjacent. When you already have ISO 27001, 9001, or 14001 certified, the harmonized structure makes 42001 a meaningfully smaller delta than going greenfield. ISO 42001 is the path to a certificate. NIST AI RMF is the path to a self-attestation document.

The pattern teams might settle into is to implement NIST first to establish the taxonomy and lifecycle discipline, then layer ISO 42001 certification on top once the documentation work is complete. According to a Modulos vendor blog (April 2026), teams that go in this order find 42001 certification work substantially easier to land. Caveat worth flagging: Modulos sells an AI governance platform that supports both frameworks, so the framing is shaped by their product, but the structural claim still holds.

What doesn’t map cleanly?

NIST AI RMF cannot be audited. Self-attestation only. If a customer asks for proof, you have your documentation, not a certificate, and of course, ISO 42001 is the path to that certificate.

Both frameworks predate widespread agentic AI deployment, but their structure was built to flex. NIST AI 100-1 is January 2023. ISO 42001 is December 2023. Neither directly names the agent stack (multi-agent systems, persistent memory, tool-using agents). In practice, organizations map agentic behaviors onto existing requirements rather than waiting for explicit agent text. ISO 42001’s risk assessment (clause 6.1.2) and AI system impact assessment (clause 6.1.4) evaluate the degree of autonomy and identify agent-specific risks like prompt injection. Annex A.9 (Use of AI systems) covers responsible-use processes, including human-oversight controls for high-risk agentic workflows. A.6.2.8 (AI system recording of event logs) becomes the audit trail for agent reasoning. A.6.2.6 (AI system operation and monitoring) becomes the drift-detection discipline. Extension frameworks like CSA MAESTRO and the OWASP Agentic Top 10 add technical depth on agent-specific threats, but the management system architecture for governing them is already in 42001.

The decommissioning gap is the clearest difference. NIST AI RMF treats the safe retirement of AI systems as a separate step. ISO 42001 doesn’t have a dedicated decommissioning control. End-of-life gets folded into broader operation and monitoring work. If you run AI systems where retirement has real consequences (regulated industries, customer-facing deployments, and expensive trained models), you’ll need to build your own decommissioning process beyond what Annex A asks for.

BS ISO/IEC 42006:2025 is the AI audit qualification standard. Published by BSI in July 2025. When selecting a certification body for ISO 42001, ask whether their auditors are qualified under 42006. For CISSPs considering an AI audit as a career path, this is the named qualification track.

Monday morning

If you have an existing ISO 27001 SoA template, pull it. Sit down with the ISO 42001 Annex A controls list. For each of the 38 controls, note “we do this already / we partially do this / we don’t do this.” That 30-minute paper exercise becomes the foundation for an eventual real SoA.

If you don’t have a 27001 SoA in your toolkit, start with NIST AI RMF. Read the four functions. Run a one-page self-assessment of where your organization sits on the four Tiers. Two hours of work that helps create a defensible baseline.

A common implementation failure is starting both frameworks at once and finishing neither. Pick one to lead with, document the decision, and revisit in six months.

Your CISSP doesn’t make you an AI governance expert. It makes you the person whose existing risk discipline transfers fastest to the new problem. The frameworks are different. The job is the same.

Sources

Primary standards and frameworks

• ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system. ISO/IEC JTC 1 / SC 42, December 2023. https://www.iso.org/standard/42001

• ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information security management systems, Requirements. ISO/IEC JTC 1 / SC 27, October 2022. https://www.iso.org/standard/27001

• ISO/IEC 27006:2015 (and revisions), Requirements for bodies providing audit and certification of information security management systems. ISO/IEC JTC 1 / SC 27. https://www.iso.org/standard/27006

• ISO/IEC 42006:2025, Information technology, Artificial intelligence, Requirements for bodies providing audit and certification of artificial intelligence management systems. ISO/IEC JTC 1 / SC 42, published September 4, 2025. https://www.iso.org/standard/42006. National adoption available as BS ISO/IEC 42006:2025 via BSI: https://knowledge.bsigroup.com/products/information-technology-artificial-intelligence-requirements-for-bodies-providing-audit-and-certification-of-artificial-intelligence-management-systems

• NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology, January 26, 2023. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf

• NIST AI RMF Playbook (companion to AI 100-1, 72 subcategories with suggested actions). https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook

• NIST AI 600-1, Generative AI Profile. NIST, July 2024. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

• EU AI Act, Regulation (EU) 2024/1689. Entered into force 1 August 2024.

https://artificialintelligenceact.eu/

Survey and reference data

• ISO/IAF CASCO, The ISO Survey of Management System Standard Certifications, 2024, Explanatory Note. September 2025. https://iafcertsearch.org/services/iso-survey

• ISC2 Cybersecurity Workforce Study (2025) and Exam Guidance for AI (April 2, 2026), via ISC2 Insights. https://www.isc2.org/research

Secondary commentary (with vendor caveats)

• Modulos, NIST AI Risk Management Framework: the engineering spec for AI risk. Vendor blog, April 17, 2026. (Modulos sells an AI governance platform supporting both frameworks, and the framing reflects that.)

• NIST AI RMF to ISO/IEC FDIS 42001 AI Management system Crosswalk. Community-submitted, hosted on NIST AI Resource Center. PDF: https://airc.nist.gov/docs/NIST_AI_RMF_to_ISO_IEC_42001_Crosswalk.pdf. Listed on the AIRC crosswalks page: https://airc.nist.gov/airmf-resources/crosswalks/. NIST hosts but does not endorse the crosswalk. FDIS-stage clause references predate the December 2023 ISO/IEC 42001:2023 publication.

The framework is voluntary and non-certifiable. Nobody can audit you against it, and you can self-claim alignment, which is where ISO 42001 comes in as the certifiable counterpart. What RMF gives you is a shared vocabulary.

NIST also publishes a companion document called the AI RMF Playbook. The framework itself is about 40 pages of principles. The Playbook runs over 140 pages of suggested actions, transparency questions, and reference resources for each piece of the framework. If you only read the framework, you get the abstractions, while most of the operational guidance is in the Playbook.

This article walks through the four functions at the heart of the framework, using Playbook content to sharpen what each function actually requires.

The four functions at a glance

The NIST AI RMF organizes everything around four functions: GOVERN, MAP, MEASURE, and MANAGE. They aren’t sequential steps. They’re roles in a system that runs continuously.

GOVERN sits across the whole framework. It’s the organizational foundation: policies, accountability, culture, and oversight that make the other three functions possible. MAP, MEASURE, and MANAGE, then run in a loop. MAP establishes the context for understanding a specific AI system. MEASURE tests it against the trustworthiness characteristics NIST defines. MANAGE turns those measurements into prioritization decisions, kill-switch procedures, and disclosures to affected parties. The outputs of all three feed back into GOVERN, which uses them to update policies, roles, and culture over time. The framework is iterative, not linear.

Here is what each function covers:

• GOVERN (cross-cutting). Cultivates a risk-aware culture. Key elements: policies and processes, accountability, workforce diversity, organizational culture, engagement with AI actors, and third-party and supply-chain oversight.

• MAP (framing). Establishes context and identifies risks before they can be measured. Key elements: context, system categorization, capabilities and goals, risk and benefit mapping, and impact characterization.

• MEASURE (analysis). Analyzes and monitors AI risks. Key elements: methods and metrics, evaluation of trustworthy characteristics, risk tracking, and efficacy feedback.

• MANAGE (response). Prioritizes and responds to what MAP and MEASURE surface. Key elements: prioritization and response, benefit and impact strategies, third-party management, and risk treatment and communication.

GOVERN

GOVERN is where the framework starts and where most organizations underinvest. It’s the function that establishes who’s responsible for what, what risks the organization is willing to take, how AI work fits into existing accountability structures, and how culture supports raising concerns rather than burying them.

Two concrete examples make GOVERN tangible. First, NIST requires you to maintain an inventory of your AI systems, with a named individual or team responsible for keeping it up to date. This is the AI equivalent of a CMDB (Configuration Management Database). Right now, most teams don’t have one, but I don’t think the reason is laziness. Employees are provisioning AI agents through personal accounts and unmonitored API integrations faster than any central registry can keep up. When you connect an AI agent to Google Drive or Slack via MCP, the OAuth prompt goes to the individual employee. The result is direct app-to-app access that bypasses the corporate identity provider entirely, leaving the security team with no visibility into what was authorized or by whom. You can’t manage what you haven’t cataloged, and you can’t catalog what was provisioned without you.

Second, NIST requires a written policy for the safe decommissioning of AI systems before you deploy them. The Playbook lists what those policies must address: user and community concerns; business continuity and financial risks; upstream and downstream system dependencies; regulatory requirements, such as data retention; future legal or forensic investigations; reputational risk; and migration to a replacement system. NIST treats decommissioning as a governance decision. Engineering executes the policy.

Governance gaps here invalidate downstream measurements. If you don’t know what you’re running, you can’t understand/measure/secure it.

MAP

MAP is about context. Before you measure an AI system’s performance or risk, you have to understand what it’s supposed to do, who’s affected by it, where it operates, and what the organization considers an acceptable level of risk for that deployment.

The most operationally important piece of MAP is risk tolerance. NIST requires you to determine and document organizational risk tolerances before deployment. The Playbook makes this concrete by requiring maximum allowable risk thresholds above which the system won’t be deployed (or will need to be decommissioned), with explicit criteria established in advance. Production AI deployments that don’t have this end up making risk decisions after the fact, when problems surface, rather than before, when the criteria can be set without pressure.

MAP also begins the stakeholder picture. NIST names “affected communities” (i.e., people who will be impacted by the system but don’t use it directly) as required participants in establishing system context (MAP 1.6) and in evaluating benefits and costs (MAP 3.1, MAP 3.2). The operational consultation work happens later, in MEASURE.

If GOVERN is the substrate, MAP is the framing. You can’t measure what you haven’t framed.

MEASURE

MEASURE is the largest function in the framework and the most technically detailed. It evaluates an AI system against seven trustworthiness characteristics: valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed.

The seven sound abstract until you read what they require. Take “secure and resilient.” Traditional cybersecurity controls aren’t enough for AI. The Playbook names specific operational metrics such as “time-to-bypass” (how long it takes a determined attacker to defeat the system’s safeguards), red-team exercise frequency, and anomalous event rates. For per-vulnerability severity scoring, OWASP’s AIVSS extends CVSS v4.0 with an agentic uplift model that handles prompt injection and model jailbreaks. NIST’s contribution in MEASURE 2.7 is the operational test-and-measurement side, which AIVSS doesn’t cover.

MEASURE also distinguishes between transparency, explainability, and interpretability. They sound similar and get used interchangeably, but they mean different things. Transparency is what happened (visible outputs and audit trails). Explainability is how the model reached a decision. Interpretability is whether the explanation actually means something to the person reading it. A model can be technically explainable to a data scientist while being completely uninterpretable to the loan applicant whose application it just denied.

MEASURE is also where NIST widens the stakeholder picture from MAP. The Playbook is specific about where this shows up. Fairness metrics for MEASURE 2.11 are to be developed “in collaboration with affected communities.” MEASURE 3.3 requires feedback processes for impacted communities to report problems and unexpected behaviors. These are people affected by the system who don’t use it directly, such as loan applicants under an automated underwriting model or job candidates screened by a resume parser.

This is where most of the technical AI risk work lives.

MANAGE

MANAGE is where measurements become organizational action. Two requirements stand out.

First, NIST requires established procedures for superseding, disengaging, or deactivating AI systems that demonstrate performance or outcomes inconsistent with their intended use. This is the kill switch. The Playbook requires you to identify the incident thresholds that trigger deactivation, plan for redundant systems to ensure continuity when the AI is offline, and review the procedures regularly. This is likely another production AI deployment area that’s deficient for many companies.

Second, NIST requires a database of reported errors, near-misses, incidents, and negative impacts, with date reported, impact assessment, and responses. Plus a separate database of system changes, with rationale, test procedures, and version history. This is the AI equivalent of a vulnerability tracker and a change log. Industry references already exist for what these look like at scale: the AI Vulnerability Database catalogs failures across the AI ecosystem, and MITRE ATLAS maps the adversarial TTPs that incidents are likely to fall under.

MANAGE is where the framework meets production reality, and where the Playbook’s content gets the most operationally specific.

Is there a NIST AI RMF 2.0 or a 2026 version?

Short answer: no. As of 2026, AI RMF 1.0 (NIST AI 100-1, January 2023) is still the current core framework. NIST has said the framework is being revised, but no 2.0 has been released.

What confuses a search is that NIST extends the framework through Profiles, not new version numbers. The Generative AI Profile (NIST AI 600-1, July 2024) applies the four functions to generative AI risk, and that is the document most people mean when they ask about a “2024 version.” A Trustworthy AI in Critical Infrastructure Profile followed as a concept note in April 2026. So if you see “2023,” “2026,” or “1.0” attached to the same four functions, they all point back to the same core document, and the functions themselves have not changed.

How to use this if you’re leading an AI initiative

Read NIST AI RMF as an engineering spec, not a compliance document. Voluntary and non-certifiable looks like a weakness if you’re looking for something to audit against. It looks different if you’re looking for a complete public taxonomy of AI risk work, which is what RMF actually is. The depth is hard to recreate in private, which is why US financial regulators have built directly on it.

The Financial Services AI RMF, released by the Cyber Risk Institute in February 2026 and backed by the US Treasury and over 100 financial institutions, layers 230 control objectives onto NIST’s structure.

Practically, the framework is most useful as a structural vocabulary for cross-team conversations. It gives you a way to ask “what’s our documented risk tolerance for this deployment” or “do we have a decommissioning policy” without having to re-explain what an “AI risk” even means.

It’s not a checklist. The implementation tiers are directional rather than scored, and there is no audit procedure to certify which tier you’re at.

The Playbook is where value compounds, but you don’t have to read 140 pages cover to cover. Pull from it when you have a specific decision to make, like setting up an incident database or defining a kill-switch procedure. The framework points you at the question. The Playbook helps you build the answer.

One piece of practitioner advice worth ending on. The framework presents GOVERN first, but experienced implementers often suggest starting with MAP instead. Governance written without a current inventory governs imaginary systems. Run a discovery sprint first. Inventory the AI you’re already running, including the SaaS features that quietly added AI and the agents operating under employee credentials. Then write the GOVERN layer with specific reference to what you found. Your decision-rights matrix is a different document when “Slack now ships an AI summarizer that twelve of our teams use” is in the inventory.

Both documents are at nist.gov/itl/ai-risk-management-framework.

Frequently asked questions

What are the four functions of the NIST AI RMF?
Govern, Map, Measure, and Manage. Govern is cross-cutting, and the other three run in rough lifecycle order.

Is the NIST AI RMF mandatory?
No. It is voluntary, non-certifiable, and not sector-specific. It carries weight in US regulatory and procurement settings because of NIST’s authority, the same way the NIST Cybersecurity Framework became a de facto standard.

What is the difference between NIST AI RMF and ISO 42001?
NIST AI RMF is a voluntary framework for how to manage AI risk. ISO/IEC 42001 is a certifiable management system you can be audited against. Many teams use NIST for the risk taxonomy, then map to ISO 42001.

Does Govern come first?
It is listed first because it is cross-cutting, but many practitioners start with Map so governance reflects a real inventory of AI systems.

Is there a NIST AI RMF for generative AI?
Yes. The Generative AI Profile (NIST AI 600-1, July 2024) applies the four functions to generative AI risk.

The CISSP exam outline, which has been in effect since April 15, 2024, already includes some AI-specific references in several domain objectives. ISC2 didn’t bolt on a new “AI Security” domain. Instead, they distributed AI concepts throughout the existing structure, as they’ve always handled emerging technology. The difference this time is scale because AI touches every domain, and the Exam Guidance makes that explicit.

Here’s my take on what changed, and what you need to know.

The Dual Pattern

Across all eight CISSP domains, AI shows up in two ways:

1. AI as a system that needs to be secured. Protecting models, training data, and AI infrastructure from attack: think data poisoning, prompt injection, adversarial inputs, and model theft.

2. AI as a tool you use for defense. SIEM/SOAR automation, behavioral analytics, anomaly detection, and AI-powered vulnerability scanning.

Understanding which one is being asked will help you reason through unfamiliar scenarios on the exam.

What’s New in Each Domain

Here are some AI-related concepts from each domain that I think are the most likely to feel new or foreign to CISSP candidates.

Domain 1: Security and Risk Management

The new concept: AI supply chain risk.

You already know third-party risk management. The AI version asks the same governance questions, but about different things. Where does the training data come from? What model is your vendor using, and who trained it? What happens when the model is updated and its behavior changes? CISSPs are now expected to assess AI service providers with the same rigor applied to any critical vendor. The questions are different (data provenance, bias documentation, model transparency), but the framework is the one you already know from Domain 1.

Domain 2: Asset Security

The new concept: AI-specific asset classification.

Training datasets, pre-trained models, and model weights are now assets that need to be classified and protected. A pre-trained model is intellectual property. A training dataset may contain PII that triggers privacy mandates. Model weights are a theft target. If your organization’s data classification scheme doesn’t account for these asset types, it has a gap.

Domain 3: Security Architecture and Engineering

The new concept: Prompt injection as an architectural concern.

This is the domain where the technical specifics of AI attacks intersect with traditional security architecture. Prompt injection is the AI equivalent of SQL injection: untrusted input that manipulates the system’s behavior. But the defense isn’t just input validation. It includes architectural decisions about model isolation, output verification, and Explainable AI (XAI), which is the ability to audit why a model produced a specific output. ISC2 frames XAI as a security architecture requirement, not just a nice-to-have.

Domain 4: Communication and Network Security

The new concept: Network segmentation for AI workloads.

AI training clusters generate traffic patterns distinct from those of standard enterprise applications and pose unique lateral movement risks. The exam outline now expects CISSPs to understand micro-segmentation and Zero Trust Architecture as applied to AI environments. The goal is the same as always (prevent lateral movement from a compromised interface), but the specific architecture for isolating AI training environments from production networks is new territory.

Domain 5: Identity and Access Management

The new concept: Non-Human Identity (NHI) governance.

This one is significant. The CISSP now covers managing identities for AI agents and automated service accounts. That means understanding how to apply the Principle of Least Privilege to a system that might try to escalate its own permissions during learning or execution. It also means understanding the dual problem: you’re securing the AI’s identity (what credentials it has, who owns them, and whether it can escalate) while also using AI to make IAM more resilient (behavioral biometrics, adaptive authentication, anomaly detection in login patterns).

But credential controls alone don’t solve the problem. As Chris Hughes points out, agents don’t just exist as identities. They use identities to take action. An agent manipulated at runtime through prompt injection or a poisoned tool response will request access through valid paths, receive a properly scoped token, and act exactly as policy allows. Every identity control passes. The breach still happens. The threat model has shifted from “who holds the key” to “who is influencing the decision,” and static permission models weren’t designed to answer the latter.

For context on why this matters: a 2025 CSA survey of 383 security professionals found that only 8% were highly confident their legacy IAM tools could handle AI and NHI risks. Only 22% had formal policies for creating or removing AI identities. Making this more than a hypothetical gap.

Domain 6: Security Assessment and Testing

The new concept: Red teaming for AI systems.

Traditional penetration testing looks for software bugs and misconfigurations. AI red teaming tests different things: model robustness against evasion attacks, susceptibility to training data extraction, and “logic flaws” in the model’s output that an adversary could exploit. The Exam Guidance makes clear that CISSPs should understand these as distinct assessment methodologies, not just variations of traditional pen testing.

Domain 7: Security Operations

The new concept: Model drift as a security operations concern.

Model drift is what happens when an AI model’s performance degrades over time. Data scientists have always cared about this. What’s new is ISC2 framing it as a security operations problem. A model that’s drifting might be degrading naturally or under adversarial influence. SOC teams need to monitor AI systems as production assets, watching for drift as a potential indicator of compromise rather than just a performance issue.

Domain 8: Software Development Security

The new concept: AI-generated code risks.

As organizations adopt AI-generated code to an ever-larger degree, the CISSP is emphasizing the role of security in understanding specific risks. Hallucinated dependencies, where AI references packages that don’t exist (and an attacker creates a malicious package with that name). Insecure defaults in generated code. Leaked training data in code suggestions. And the AI/ML supply chain: the security of the ML libraries and frameworks your software depends on.

How to Prepare

If you’re studying for the CISSP right now, here’s some practical advice.

Don’t panic about depth. The CISSP is a management-level certification. You don’t need to know how to build a prompt injection defense, but you need to understand that prompt injection exists, that it’s an architectural concern, and that the defense involves input validation, model isolation, and output verification. As with other topics, you need to know what and why, not how to implement.

Distinguish the guidance from the outline. The Exam Guidance doesn’t always separate “the exam outline says this” from “here’s how to think about this in an AI context.” When it claims the outline integrates AI into shared responsibility models for cloud-based AI services, it’s most likely reading an AI lens onto an existing objective that already covers shared responsibility generally. The exam outline is the authoritative source for what’s explicitly tested. Read the Exam Guidance as an interpretive layer. It shows you how existing CISSP concepts apply to AI scenarios, rather than a guarantee that every domain now has standalone AI questions. To know what’s on the exam, check the outline. To understand how to think about it, read the guidance.

Learn the vocabulary. Several AI concepts show up across multiple domains. If you understand these terms, you can reason through scenarios even if the specific question is unfamiliar:

• Data poisoning: Corrupting training data to manipulate model behavior

• Model drift: Degradation of model performance over time (natural or adversarial)

• Prompt injection: Untrusted input that changes an AI system’s intended behavior

• Adversarial attacks: Inputs specifically crafted to cause model misclassification

• Non-Human Identity (NHI): Credentials used by AI agents and automated systems

• Explainable AI (XAI): The ability to understand and audit AI decision-making

• Shadow AI: Unauthorized use of public AI tools by employees

Map AI to frameworks you already know. The ISC2 Exam Guidance references several frameworks that connect AI security to traditional CISSP material:

• NIST AI RMF (AI 100-1): The voluntary US framework for AI risk management. Four functions: Govern, Map, Measure, and Manage. This maps directly to Domain 1’s risk management concepts. If you understand NIST RMF, the structure is familiar.

• ISO/IEC 42001: The certifiable AI management system standard. Think of it as ISO 27001 for AI. If you understand the ISO 27001 PDCA cycle, you understand the structure of 42001.

• OWASP Top 10 for LLMs: The authoritative vulnerability taxonomy for LLM applications. Prompt injection is #1. If you know the traditional OWASP Top 10, this is the AI equivalent.

Use the dual pattern as a study filter. When you encounter an AI topic, ask yourself: Is this about securing an AI system or about using AI for defense? That distinction will help you orient quickly to exam questions.

Read the Exam Guidance itself. It’s 25 pages, free, and directly from ISC2. The CISSP section is pages 8 through 10. It won’t tell you exactly what the exam will ask, but it tells you what ISC2 considers testable. That’s as close to a study guide as you’ll get from the source.

The Bigger Picture

ISC2 folded AI into every existing credential because that’s how AI works in practice. It isn’t a separate discipline. It changes how you manage risk, classify assets, design architecture, manage identities, test systems, run a SOC, and secure software.

The CISSP has always been about breadth. Knowing enough about every domain to make good security decisions. AI extends that expectation.

If you’re a current CISSP holder, this is CPE territory. Pick a framework (NIST AI RMF is a good starting point), learn the vocabulary, and start mapping AI risks to the domains you already understand. While the assets and threats may be different, the governance structure you’ve learned still applies.

ISC2 has built out a dedicated learning track for CISSP holders who want to go deeper. The ISC2 AI Security Certificate is a standalone credential covering AI attack recognition and mitigation, AI security framework comparisons, and strategies for balancing AI tools with human decision-making (essentially the layer above what the base CISSP AI integration requires). For something more targeted, the AI Security Express Courses cover specific topics like Generative AI, Secure Development, and AI Integration and Monitoring in a shorter format. If you have five or more years of experience and want to work through the strategic picture with peers, ISC2 also runs in-person and virtual Securing AI Workshops designed for mid- and senior-level practitioners. The data support doing something: according to ISC2’s 2025 Cybersecurity Workforce Study, 70% of CISSPs are already pursuing additional AI qualifications. The professionals who close this gap now will be the ones asked to lead the governance conversations in their organizations.

If you’re a candidate, the governance frameworks you’re studying are the foundation for AI security. The risk management processes, classification schemes, access control principles, and assessment methodologies all apply. What’s new is the threat surface inside each one: the poisoning vectors, the non-deterministic outputs, the identity challenges that come with autonomous agents. The Exam Guidance information gives you a map of what to learn.

The structure you’ve studied is the starting point.

CISSP relevance: All 8 domains. Domain 1 (AI governance, supply chain risk), Domain 2 (AI asset classification), Domain 3 (prompt injection, XAI), Domain 4 (AI network segmentation), Domain 5 (NHI governance), Domain 6 (AI red teaming), Domain 7 (model drift monitoring), Domain 8 (AI-generated code risks).

There are two specific guides that help answer that question more directly. The first is the OWASP Securing Agentic Applications Guide (80 pages, July 2025), an engineering manual from the same team behind the Agentic Top 10. The second is Casaba Security’s Agentic AI Security Guide (v1.2, April 2026), written by a penetration testing firm based on findings from actual engagements.

Between the two, you get both the framework and the field report. Here’s what I think matters, organized around the risks that show up in practice and the architectural decisions that address them.

A useful starting point

Before getting into specifics, one concept from the OWASP guide is worth mentioning first. The guide decomposes “an agent” into six Key Components (KC1 through KC6): the language model (KC1), orchestration and control flow (KC2), reasoning and planning (KC3), memory (KC4), tool integration (KC5), and the operational environment (KC6). Each has its own attack surface, and the risks below target specific components. This matters because you can’t secure a system you haven’t decomposed. I’m betting that teams mapping their agent to these six components will find gaps in KC4 (memory) and KC6 (operational environment), the components that existing threat models don’t cover well.

Untrusted Data Reaching the Control Plane

The risk that underlies almost everything else in agentic security is indirect prompt injection, what the research community calls XPIA. Most people think of prompt injection as a user typing something malicious into a chat box. The indirect version is harder to spot. The injection comes from the data the agent processes, not from the user: documents in RAG indices, tool outputs, emails, web pages, API responses, CRM records. Anywhere the agent reads untrusted data, an attacker can plant instructions.

Casaba breaks XPIA into four attack surfaces. Perception-layer injection hides instructions in content the agent ingests, but humans can’t see (e.g., CSS display: none, HTML comments, aria-label attributes). Research shows these alter agent outputs in 15-29% of tested cases. Instead of injecting explicit commands, the attacker fills the source content with confident, authoritative language that leans in a particular direction. The agent isn’t being told what to say. But when most of what it reads carries the same framing, its synthesis reflects that framing. There’s no payload to detect because the attack is in the aggregate rather than in any single document.

Memory and learning attacks corrupt stored context, so the compromise persists across sessions. Action-layer attacks embed explicit instruction sequences in external resources that, when ingested, override safety alignment.

The architectural response: separate the data plane from the control plane. This is the single most important design decision. The OWASP guide highlights Google’s CaMeL as the cleanest conceptual model. A privileged LLM receives only trusted inputs and generates control flow (which tools to call, in what order). A quarantined LLM processes untrusted data (web content, email bodies, retrieved documents) and has no access to tools. Prompt injection in a retrieved document hits the quarantined LLM, which can’t invoke tools. The injection has nowhere to go. CaMeL also isolates memory: the quarantined LLM’s context doesn’t leak into the privileged LLM’s memory, which prevents poisoned data from influencing future control flow decisions.

CaMeL remains a research architecture. A follow-up paper (May 2025) adds prompt screening, tiered-risk access, and output auditing, but no production deployments have been published. What is shipping in production is the underlying principle: external enforcement layers that sit between the agent and its tools. Check Points, Zenity’s runtime agent monitor, Lasso Security’s MCP Gateway, and Airia’s model-agnostic control plane all enforce the same boundary: untrusted content can’t directly trigger tool invocations. They do it through runtime policy engines and gateways rather than a second LLM, but the design principle is identical.

What to watch for: Any workflow where an agent retrieves or processes content from sources outside your direct control. Email summarizers, web research agents, document analyzers, RAG-based assistants. All are at high risk for XPIA.

Read more

Because here’s what ATLAS doesn’t cover: it can’t tell you how an attack might unfold in a system you’re building or defending right now, especially if that system involves autonomous agents with persistent memory, tool access, and the ability to spawn sub-agents. For a traditional web application, a retrospective TTP catalog is usually enough. The architecture is stable, and past patterns predict future ones with reasonable accuracy. Agentic AI doesn’t behave that way. An autonomous agent that can browse the web, call external APIs, write files, and delegate tasks to other agents creates an attack surface that’s still generating its first wave of documented incidents. The ATLAS case study record hasn’t caught up with what’s already in production.

That’s where MAESTRO comes in.

What MAESTRO Is and What Problem It’s Actually Solving

MAESTRO (Multi-Agent Environment, Security, Threat, Risk, and Outcome) was published in February 2025 by Ken Huang, co-chair of the CSA AI Safety Working Group. The framework’s central premise is that traditional threat modeling approaches weren’t designed for systems that make autonomous decisions, adapt behavior over time, and coordinate with other agents across trust boundaries.

That’s not a provocative claim. STRIDE models systems as static data flows between defined components (relying on Data Flow Diagrams to visualize a system at a specific point in time). PASTA’s attack simulation model assumes the system being analyzed has deterministic, bounded behavior, with no mechanism to represent a system that autonomously modifies its own goals or behavior at runtime.

Neither has a mechanism to address threats arising from goal misalignment, autonomous decision-making, or multi-agent collusion. A peer-reviewed 2025 study (Zambare, Thanikella, and Liu at Texas Tech University) reviewed existing frameworks and directly confirmed the gap, noting that STRIDE “does not model emergent behavior, cognitive reasoning of AI agents very well.” The OWASP Agentic Security Initiative reached the same conclusion, ultimately endorsing MAESTRO as a comprehensive extension of STRIDE for handling Agentic AI.

MAESTRO’s answer is a seven-layer reference architecture, each with its own mapped threat categories: Foundation Models (L1), Data Operations (L2), Agent Frameworks (L3), Deployment and Infrastructure (L4), Evaluation and Observability (L5), Security and Compliance as a vertical layer that cuts across all others (L6), and Agent Ecosystem (L7).

What that structure forces, and what classical frameworks don’t, is cross-layer analysis. Take a LangChain-based agent with RAG access. STRIDE treats it as a system with data flows. MAESTRO requires you to analyze it at L2 (the vector database is a poisoning surface), L3 (the framework itself is a supply chain risk), and L7 (the agent faces tool manipulation and identity attacks in the ecosystem it operates in). In other words, STRIDE asks, “Can someone tamper with the data moving through this system?” MAESTRO asks, “Can someone corrupt what the AI knows, compromise the tools it was built with, and manipulate who it trusts in the world it operates in,” and treats each of those as a separate, distinct problem requiring separate analysis.

Each layer carries its own threat categories, and a compromise in one doesn’t stay contained. Researchers at Texas Tech confirmed this empirically: poisoning a single memory file in L2 caused measurable performance degradation in L4 and L5 without altering any system logic. In essence, someone edited a JSON file, inserting fake high-severity attack entries that the agent reads. The agent didn’t break, but it degraded silently. The attack entered at L2 (data operations — the memory file). It affected L3 (the tuning module changed its behavior). That caused resource exhaustion at L4 (infrastructure) and degraded observability at L5 (the monitoring system itself became less responsive). One layer’s compromise propagated through three others without directly touching any of them. STRIDE would model the JSON file as a data integrity issue at one point in the system. It wouldn’t predict that corrupting the file would degrade the monitoring infrastructure two layers away.

The striking fact is that a single JSON file with no code access caused an autonomous security agent to silently misjudge its environment and waste resources defending against nonexistent threats, while potentially missing those that did exist.

That’s the kind of threat STRIDE doesn’t surface. MAESTRO does.

Where the Real Threats Live

Not all seven layers carry equal risk. Three of them deserve immediate attention.

L2 (Data Operations) is where the most operationally mature threat activity currently resides. ATLAS’s Resource Development tactic shows 9 of 13 rated techniques are “Realized”, meaning adversaries have already industrialized data poisoning against retrieval systems. Any organization running a production RAG pipeline should treat L2 threat modeling as urgent, and the Texas Tech cascade described above began here, with a single poisoned file.

L7 (Agent Ecosystem) is where agentic AI diverges most sharply from everything that came before. Agent impersonation, tool squatting, rug pull attacks against MCP integrations, and compromised discovery registries, none of which have classical equivalents. SesameOp (ATLAS case study AML.CS0042) confirmed adversaries are already using legitimate AI service APIs as covert C2 channels. That’s a fully “Realized” L7 attack chain. What makes L7 defense especially difficult is the governance baseline organizations are actually starting from. A 2025 CSA survey of 383 IT and security professionals found that 51% have no clear ownership of AI identities, and over 16% don’t track when new AI credentials are created. MAESTRO’s L7 threat categories assume someone is watching the identity layer. Most organizations aren’t.

L1 (Foundation Models) receives less operational attention, but two threat classes are particularly relevant for compliance-sensitive environments. Backdoor attacks embed hidden triggers in fine-tuned models that remain dormant until a specific input activates them. Membership inference attacks let an adversary determine whether specific records were used in training. That’s a direct HIPAA or GDPR exposure for any organization fine-tuning on sensitive data.

Using ATLAS and MAESTRO Together

The two frameworks solve different parts of the same problem. MAESTRO generates a systematic threat list from the architecture up. ATLAS tells you which items on that list adversaries have confirmed in the wild.

The workflow that combines them is straightforward. Take each layer of your system and ask: what could go wrong here? That’s the MAESTRO step. Then check ATLAS for each threat you’ve identified: has anyone actually done this? If a technique is tagged “Realized,” it moves to the top of your risk register. If it’s “Demonstrated” or “Feasible,” it still matters, but it’s not yet confirmed in the wild. The CSA Agentic Red Teaming Guide then provides concrete test procedures you can run against each layer to validate whether your system is actually exposed.

The Texas Tech study is the clearest argument for why you need both. The L2-to-L4/L5 cascade, the researchers confirmed, had no corresponding “Realized” ATLAS technique at the time of publication. MAESTRO predicted the attack class. ATLAS didn’t have the incident. That’s exactly where the combined methodology earns its keep.

One honest caveat: 46 of ATLAS’s 167 native techniques are unrated (as of this writing), and most are newer agentic additions. The “Realized” filter works well for L2 and L4 threats. For L7, it’s less discriminating. Treat more L7 items as “Demonstrated” rather than “Realized” until the incident record catches up.

What This Pairing Doesn’t Solve

MAESTRO doesn’t yet have a formal specification. No versioning, no conformance testing, no defined scoring methodology that I could find. The AgentRFC framework from Dartmouth and Palo Alto Networks produced companion security principles with formal conformance language. MAESTRO doesn’t operate at that level of rigor, and practitioners building repeatable assessment processes will hit that ceiling.

Both frameworks share a documented scope gap. ATLAS explicitly excludes malicious use of AI against non-AI targets, and MAESTRO follows the same boundary. AI-enhanced phishing, AI-automated vulnerability discovery, and deepfake-assisted social engineering aren’t covered. If your threat model needs to include those vectors, you’re working outside both frameworks.

There’s also no native scoring engine. OWASP’s Agentic Vulnerability Scoring System needs to be applied separately for quantitative prioritization.

And the constraint that no framework resolves: the CSA NHI survey found only 8% of organizations are highly confident their legacy IAM can handle AI and NHI risks, and 24% take more than 24 hours to revoke a compromised credential after an exposure event. A rigorous threat model is only as useful as the organization’s ability to act on it. Closing that operational gap is a separate, harder problem.

Where to Start

The combined methodology reduces to three questions applied to any AI system your organization operates.

1. What does your AI system actually touch? Map your system against MAESTRO’s seven layers. In practice, this means listing: which foundation model you use (L1), what data sources feed it and where they’re stored (L2), which framework or platform it’s built on (L3), where it runs and who manages that infrastructure (L4), how you monitor its behavior and measure its performance (L5), and what external tools, APIs, or other agents it can access (L7). Many teams will discover layers they haven’t thought about as attack surfaces, particularly L2 (the data the AI trusts) and L7 (the tools and services it connects to).

2. Which of those layers have confirmed attacks in the wild? Cross-reference your layer map against ATLAS. Start with L2: nine of thirteen techniques in ATLAS’s Resource Development tactic are “Realized,” meaning adversaries have demonstrated them in real incidents. If your AI system ingests external data — retrieval-augmented generation, fine-tuning on user data, or any pipeline that feeds information to the model — that’s your most evidence-backed risk. Any layer where ATLAS shows “Realized” techniques goes to the top of your risk register.

3. Can you actually detect and respond if something goes wrong? This is where most organizations hit the real gap. MAESTRO’s L5 (Evaluation and Observability) asks whether your monitoring can detect a compromised AI agent, not just whether the system is up, but whether it’s making trustworthy decisions. And the governance question is unavoidable: the CSA NHI survey found 51% of organizations have no clear ownership of AI identities. If no one owns the AI identity layer, your threat model describes a problem that nobody is accountable for fixing.

For CISSP holders, questions 1 and 2 fall under Domain 1 (Security and Risk Management). Question 3 spans Domain 8 (Software Development Security) for the monitoring and testing controls, and Domain 1 again for the governance structure. The CSA Agentic Red Teaming Guide provides executable test procedures for each MAESTRO layer once you’ve completed the mapping.

Assign ownership first. Then model the threats.

The attack wasn’t sophisticated in any traditional sense. No CVE was exploited. No credentials were stolen. No network was breached. It was simply provided inputs through the interface the system was designed to accept, and the model’s own learning mechanism turned those inputs into a weapon against itself. If you tried to map that attack to MITRE ATT&CK at the time, you’d come up empty. The attack surface wasn’t an endpoint or a network. It was the model’s relationship with its training data.

That gap, the space between what ATT&CK covers and what AI systems actually expose, is exactly what MITRE ATLAS was built to fill.

ATLAS stands for Adversarial Threat Landscape for Artificial-Intelligence Systems. It’s a structured knowledge base of adversary tactics, techniques, and real-world case studies specifically targeting AI and machine learning systems. Think of it as ATT&CK’s purpose-built extension into territory that traditional threat frameworks never modeled: data pipelines, model architectures, inference APIs, and training processes. As of today, ATLAS documents 16 tactics and 167 techniques across 57 case studies, with 35 mapped mitigations, and the framework is actively growing.

Where This Started

ATLAS began in late 2020 as a collaboration between MITRE and Microsoft, with twelve industry and academic partners, under the blunter name Adversarial ML Threat Matrix. The original repository still lives at github.com/mitre/advmlthreatmatrix.

The project was justified by a pattern of high-profile ML failures. Google’s image recognition system was fooled by adversarial stickers. Amazon’s Alexa was triggered by ultrasonic commands embedded in bird chirps. Tesla’s Autopilot was steered into oncoming traffic by three small road stickers, at roughly $0 cost and without exploiting any software vulnerability. And then there was Tay. Four incidents, four companies, four different attack mechanisms, united only by the fact that the target in each case was the AI system’s behavior, not its infrastructure. A survey of 28 organizations conducted around the same time found that 25 of them didn’t know how to secure their ML systems. Industry wasn’t behind on patches. It was behind on the vocabulary needed to think about the problem systematically.

MITRE’s AI Security 101 resource at atlas.mitre.org/resources/ai-security-101 frames why AI attacks require a different analytical lens through three dimensions:

• AI Access Time refers to whether an attack occurs during training, when the model is still being shaped by data, or during inference, when it’s responding to live queries.

• AI Access Points covers whether the adversary reaches the model digitally via an API or physically by modifying real-world inputs, such as a sticker on a road sign or a sound pattern near a microphone.

• System Knowledge covers whether the adversary has white-box access to the model architecture and weights or operates in a black-box manner, probing only the inputs and outputs via an API. Most real-world attacks are black-box, and adversaries have learned to do significant damage without ever seeing model weights.

These three dimensions explain why AI attacks don’t map cleanly onto ATT&CK. An adversary targeting an ML system doesn’t necessarily need a foothold on a server. API access and a few thousand queries may be enough.

How ATLAS Builds on ATT&CK

ATLAS was consciously modeled on ATT&CK: the same tactic-technique matrix structure, the same case-study grounding, and the same community contribution model. Security teams already know how to use ATT&CK, and ATLAS doesn’t ask them to learn a new mental model, just extend an existing one.

ATT&CK Enterprise has 14 tactics. ATLAS has 16. Most overlap directly and are adapted to describe how familiar attack phases look when the target is an AI system. Two new tactics have no ATT&CK equivalent.

AI Model Access covers how adversaries reach the target model itself, through an inference API, a stolen artifact, or an offline copy built through iterative querying. You can’t run AI-specific attacks without first getting to the model in some form, and traditional attack chains have no equivalent requirement. Every technique under this tactic is ATLAS-native.

AI Attack Staging is the most technically distinctive column in the matrix. It describes the preparation phase unique to AI attacks: crafting adversarial data, building proxy models for offline testing, and verifying that an attack works before deploying it against production. An adversary poisoning a production model doesn’t just submit corrupted data and hope. They build a local approximation, test inputs against it, refine until the attack reliably produces the desired output, then execute. Like AI Model Access, every one of AI Attack Staging’s entries is ATLAS-native. No equivalent exists in ATT&CK because this class of preparation didn’t exist as a documented threat category before AI systems became production infrastructure.

Beyond the 167 ATLAS-native techniques, the matrix incorporates 98 ATT&CK-adapted techniques that MITRE doesn’t count in its headline figure. Those inherited techniques carry a clear signal: when traditional TTPs appear in AI system attacks, adversaries are usually targeting the underlying infrastructure, API keys, data servers, and GPU compute, rather than the model itself. ATLAS doesn’t pretend that the threat disappears just because the target system has a neural network.

Sixteen Tactics and a Prioritization Tool

The 16 ATLAS tactics run left to right in rough attack-progression order, which can be read in four groups, which I’ll call preparation, establishment, exploitation, and objectives.

Preparation covers Reconnaissance, Resource Development, Initial Access, and AI Model Access. Reconnaissance in an AI attack might mean querying a public API to map model behavior or scraping job postings to identify what ML frameworks a target uses. Resource Development covers building attack inputs, including poisoned datasets, crafted prompt libraries, and hallucinated entities published to contaminate retrieval systems. Initial Access includes an AI supply chain compromise, prompt injection via public-facing applications, and phishing targeting engineers with access to the training infrastructure.

Establishment covers Execution, Persistence, and Privilege Escalation. Persistence in an AI system looks different from traditional IT. An adversary might poison a RAG (Retrieval-Augmented Generation) knowledge base so that malicious content survives model updates. Or they embed a backdoor trigger in a fine-tuned model that stays dormant until a specific input activates it. For Privilege Escalation, the two ATLAS-native techniques are AI Agent Tool Invocation and LLM Jailbreak. Both reflect the same underlying risk: an agentic AI system that can take actions on behalf of users becomes a potential bridge between a sandboxed AI environment and the resources beneath it.

Exploitation covers Defense Evasion, Credential Access, Discovery, Lateral Movement, and Collection. Defense Evasion is the most populated tactic in the matrix: 15 ATLAS-native techniques plus 26 ATT&CK-adapted entries in that column, covering everything from AI supply chain reputation inflation to manipulating a user’s LLM chat history to cover attack traces.

Objectives cover AI Attack Staging, Command and Control, Exfiltration, and Impact. Exfiltration under ATLAS includes techniques specific to AI systems: extracting an LLM’s system prompt, inducing data leakage through crafted queries, or using model response rendering to exfiltrate information. Impact includes Cost Harvesting and resource exhaustion attacks that inflate inference bills on a victim’s API account, alongside data destruction and service denial.

MITRE also publishes an ATLAS Knowledge Graph that's worth bookmarking alongside the matrix. Where the matrix shows tactics and techniques in column-row format, the graph shows the relationships between them: how a technique connects to its mitigations, which case studies demonstrate it in practice, and how tactics link to one another across an attack chain. You can filter by entity type to focus on tactics and techniques or mitigations; search by ID when working with specific techniques; and enter focus mode on any node to expand its immediate network. For threat modeling, it's a faster way to answer "what mitigates this specific technique" than to navigate the matrix column by column. The graph was added in Website v4.12.0, alongside the Data v5.5.0 update in March 2026, and reflects the same 167 techniques, 35 mitigations, and 57 case studies cited throughout this article.

The Maturity Slider: A Practical Prioritization Tool

The live matrix includes a filter that deserves more attention than it typically gets. The maturity slider lets you filter techniques by evidence level across three tiers. Feasible means the technique works in a research setting. Demonstrated means it’s been proven in a red-team exercise or against a realistic AI system. Realized means a threat actor has used it in a confirmed real-world incident.

Of 167 ATLAS-native techniques, 121 carry a maturity rating. The remaining 46, mostly newer agentic AI additions, haven’t been assessed yet. Of the 121 rated techniques, 50 appear in the Realized tier.

Fifty techniques confirmed in actual threat-actor operations against AI systems. This isn’t theoretical anymore.

The distribution is instructive. Resource Development has 9 of 13 rated techniques Realized, indicating that adversaries are actively building poisoned datasets, hallucinated entities, and compromised models as part of their operational tradecraft. AI Attack Staging has 4 Realized out of 6, a high ratio for a tactic that describes specialized preparation work. Discovery and Credential Access each show only 1 Realized technique despite having 9 and 6 rated, respectively, suggesting that the reconnaissance and credential-theft phases of AI attacks remain more theoretical than operational in documented incidents. That gap is worth noting when prioritizing defensive investments.

The Realized filter is a built-in prioritization shortcut. With 167 techniques in the full matrix, knowing which 50 are confirmed adversary behavior gives you a defensible, evidence-based starting point for threat modeling.

What the Case Studies Tell Us

ATLAS launched with 13 case studies drawn from real incidents. Four that hold up well as illustrations: VirusTotal Poisoning, where adversaries submitted adversarial samples to corrupt a shared malware detection service; Bypassing Cylance's AI Malware Detector, where researchers studied the product's public API behavior to craft evasion inputs; Tay poisoning; and GPT-2 model replication through iterative API querying. The full case study library now documents 57 incidents and exercises. Two recent additions stand out. The iProov deepfake case documents adversaries using face-swap tools and virtual camera injection to defeat liveness detection in banking KYC (Know Your Customer) systems. SesameOp documents adversaries turning a legitimate AI service API into a covert command-and-control channel, hiding malicious traffic inside normal AI workflow activity.

Each case study is labeled either “Incident” for confirmed real-world attacks or “Exercise” for red-team and research demonstrations. That distinction is visible on each case study page and is worth checking before treating any entry as evidence of active adversarial use. Not all 57 carry equal operational weight, but the labeled distinction makes it straightforward to tell them apart.

What This Means for CISSP Holders

ATLAS isn’t just for ML engineers. Two domains make it directly relevant to security leaders.

Domain 1, Security and Risk Management. Most risk registers in use today don’t include entries for AI Attack Staging, Functional Extraction, or Inversion Attacks. ATLAS gives practitioners the vocabulary to translate “our AI system might be vulnerable” into specific, structured threat scenarios that map to controls and drive prioritized remediation.

Domain 8, Software Development Security. On the ATLAS mitigations page, each of the 35 mitigations is tagged to the phase of AI development it applies to, from initial data collection through model deployment and ongoing monitoring. If you've spent time mapping security controls to software development phases, this is the same idea applied to AI systems. It tells the team building or buying an AI system, where in the process, each defense needs to go, not just what the defense is.

On the regulatory side, the EU AI Act's obligations for general-purpose AI models became active in August 2025, with the broader high-risk AI system framework following in August 2026. For the largest frontier GPAI models (those deemed to carry systemic risk), Article 55 of the Act already requires providers to conduct and document adversarial testing. For organizations deploying high-risk AI systems, the compliance deadline arrives in August 2026.

For ecosystem fit: ATLAS works alongside other frameworks rather than replacing them. Pair it with the NIST AI RMF's Measure function for risk quantification, the OWASP LLM Top 10 for application-level vulnerability coverage, and ISO/IEC 42001 for governance structure. ATLAS covers the adversarial tactics and techniques layer, which is what attackers actually do, a piece that the others largely leave undefined.

Two limitations worth naming. First, ATLAS is still catching up to agentic AI. The late 2025 and early 2026 updates added significant new coverage of AI agent techniques, but Realized technique counts in that area remain low. The framework is reacting to, not predicting, how attackers use autonomous AI systems. Second, ATLAS explicitly does not yet cover what MITRE calls "Malicious Use of AI," meaning AI as a weapon rather than as a target. AI-enhanced phishing, AI-powered reconnaissance, AI-automated attack development against conventional infrastructure: none of that fits the current TTP structure, and MITRE says so directly. The framework tells you how to defend your AI systems. It doesn’t yet systematically address how AI is changing attacks against your non-AI systems.

ATLAS is the shared language AI security has needed. The framework at atlas.mitre.org is free, open, and actively maintained. The only barrier to using it is not knowing it exists.

By The Cyber Leader | balancedsec.com

In August 2025, ISACA did something long overdue. They launched a certification built specifically for security managers who need to deal with AI. Not data scientists. Not ML engineers. Security managers.

The timing wasn’t subtle. Organizations were already deploying AI systems across their operations, and most had no one formally responsible for securing those deployments. ISC2’s 2025 AI Adoption Survey found that over one-third of surveyed cybersecurity professionals cited AI as the biggest skills shortfall on their teams, and 42% said they’re actively exploring or testing AI-focused security tools. ISACA’s response was the Advanced in AI Security Management (AAISM): a credential designed to sit atop existing security management expertise and extend it into AI governance, risk, and technical controls.

I believe it’s the first certification that treats AI security as a management and leadership discipline rather than as a demonstration of technical knowledge. For CISSP or CISM holders, it’s the most directly relevant option on the market right now. But “first” doesn’t automatically mean “complete,” and the certification has limitations worth understanding before you charge the card.

Who It’s For (And Who It Isn’t)

The most important design decision ISACA made was the prerequisite. You can’t sit for the AAISM exam without an active CISM or CISSP certification. Active. Not expired or in progress.

That single requirement tells you everything about the intended audience. AAISM isn’t trying to create AI security professionals from scratch. It’s trying to take experienced security managers who already think in terms of governance, risk tolerance, and program management, and give them the AI-specific knowledge they’re missing. In other words, the credential is additive, not foundational.

The target candidate is a security leader, GRC professional, or anyone accountable for enterprise AI risk, vendor oversight, or regulatory compliance around AI systems. If your organization isn’t working with AI, or if you’re in a purely hands-on technical role with no governance responsibilities, this may not be the right investment.

The Exam: What You’re Walking Into

The AAISM exam consists of 90 multiple-choice questions and lasts 2.5 hours, roughly 1 minute and 40 seconds per question. The passing score is 450 on ISACA’s 200–800 scaled scoring system. It’s computer-based and administered through PSI testing centers or via remote proctoring (available in most countries worldwide, with a few specific regional exceptions). Available in English and Spanish.

Cost: $459 for ISACA members, $599 for non-members, plus a one-time $50 application fee after passing. You get a 12-month eligibility window, up to three attempts at full price each, and can schedule up to 90 days in advance.

Maintenance is notably lighter than what you’re used to. AAISM requires just 10 CPE hours per year (30 over three years), with an annual fee of $20 for members or $35 for non-members, due January 1st. Compare that to the CISSP’s 120 CPE credits over three years. You do need to keep your qualifying CISM or CISSP active throughout. One practical note for CISSP holders: your CISSP fee is due on your certification anniversary, but the AAISM fee is due January 1st. Different calendars. Worth noting now.

The Three Domains

Domain 1: AI Governance and Program Management (31%)

This is where CISSP holders will feel the most solid footing. This domain covers the creation, implementation, and maintenance of ethical and secure AI systems. Per the AAISM exam content outline, it covers stakeholder engagement, industry frameworks and regulatory requirements; AI-related policies and procedures; AI asset and data lifecycle management; security program development; and business continuity/incident response as they apply to AI systems.

If you’ve spent time in CISSP Domain 1 (Security and Risk Management), the concepts are structurally familiar. What’s new is the application layer. AI asset classification doesn’t work the same way as traditional IT asset management. A trained model isn’t a server. The regulatory frameworks (e.g., EU AI Act, NIST AI RMF, ISO/IEC 42001) are ones you probably haven’t had to operationalize before.

Domain 2: AI Risk Management (31%)

This domain covers AI risk assessment, thresholds, and treatment; threat and vulnerability management; and AI vendor and supply chain management. It tests your ability to assess both the risks and opportunities that come with enterprise AI adoption.

The vendor and supply chain piece deserves extra attention. Multiple exam prep providers flag third-party AI risk as one of the most heavily tested areas, and the one candidates consistently underestimate. My research suggests that the AAISM exam treats AI as a supply chain problem. The questions test whether you can evaluate the risk posture of cloud AI providers, SaaS vendors running AI-powered automation, and managed model services where you don’t control the training data or model architecture.

Domain 3: AI Technologies and Controls (38%)

The largest domain by weight, and where most CISSP holders will need the most study time. It covers AI security architecture and design; the AI lifecycle (model selection, training, validation); data management controls; privacy/ethical/trust/safety controls; and security controls and monitoring.

The AI lifecycle subtopics are where I think the CISSP foundation stretches thinnest. Model selection, training pipelines, and validation processes are not in the CISSP CBK. You don’t need to become an ML engineer, but you do need to understand how models are built, what can go wrong at each phase, and what controls are appropriate.

The privacy, ethics, and trust component is a differentiator. This is where AAISM goes beyond traditional security into the realm of responsible AI, covering bias detection, fairness in automated decision-making, and transparency requirements. The EU AI Act’s risk classification system explicitly requires these controls for high-risk systems, and organizations in regulated industries need people who understand how to implement them.

Prep Materials and Study Strategy

ISACA offers several official prep resources: the AAISM Official Review Manual (digital and print), an online review course ($449 for members / $549 for non-members), and a 200+-question QAE database with a 12-month subscription. As with other exams, there may be a members-only study group on ISACA Engage, but I haven’t found a public link yet.

The review manual ($105 for non-members, $89 for members) is available either as a hardcopy book delivered to your physical address or as a platform-locked ebook accessible only through the platform's browser-based interface. Note that you can save all or a part of your eBook in your browser's cache for offline reading, but you’ll need to activate the feature before you need it.

Third-party options are still limited. Destination Certification offers a 3-day online bootcamp. Training Camp offers a 3-day in-person bootcamp with a claimed 94% pass rate and a voucher. While the cost of the bootcamp is not explicitly listed as a single public price on their main landing page, similar advanced ISACA boot camps generally run $2,500 to $3,000.

Because the cert launched less than a year ago, don’t expect the depth of community study guides, YouTube walkthroughs, or Reddit threads that exist for CISSP or CISM. Supplementing with the OWASP Top 10 for LLMs, MITRE ATLAS, and the NIST AI RMF will give you practical grounding in the frameworks referenced in the exam.

Returning to third-party risk, consider using the NIST framework to assess how to verify that a third-party vendor (such as a cloud AI provider) is meeting its own safety claims, a frequent theme in the AAISM's managerial reasoning questions.

One study tip that comes up repeatedly: the questions are scenario-based and rarely black-and-white. You’re choosing the least risky option, not the perfect one. If you’ve been through the CISSP, you know the feeling. From what I’ve read, the “ISACA mindset” leans heavily toward governance-first thinking.

The Bottom Line

The AAISM is one of the strongest governance-path AI security credentials currently available for experienced security managers. The prerequisite keeps the quality bar high, the domain coverage is relevant, and the maintenance burden is light. Every hour you spend studying counts toward your CISSP renewal as Group A credit.

But it won’t teach you hands-on model security testing (look at Practical DevSecOps’ CAISP for that). It doesn’t go deep on agentic AI security, arguably the fastest-moving threat vector right now. The third-party study ecosystem is immature. And because the certification is less than a year old, its market recognition is still building.

For CISSP holders: from what I have gathered, your Domain 1 knowledge maps strongly to AAISM Domains 1 and 2. Domain 3 (38% of the exam) is where you’ll need to put in real study time. Budget accordingly. If AI governance is in your job description today, or will be in the next 18 months, the AAISM is worth serious consideration. The window to be early is still open.