AI Systems Security

A team ships an internal assistant: a large language model (LLM) fine-tuned on three years of support tickets, hosted on a managed cloud service, allowed to look up orders through an internal API. Ask whether it is secure and three different reviews come back, because three different questions hide inside that one word. What are we protecting, and with which control? Where does the thing run, and what surrounds it? Who is attacking it, and at what point can they act? This domain is 40% of the CY0-001 exam, the largest of the four domains and well ahead of AI-Assisted Security at 24%, and its items are built on that ambiguity: four options that are all real security controls, three of them answering a different question than the stem asked. Name the question first, and the control family follows.

Each of the three pages owns exactly one of those questions and breaks it down its own way, so read them in order. AI Security Controls answers what you are protecting: it names four assets, the training data, the model artifact, the inference endpoint, and the prompt and response record, then gives each one a control family, running from provenance and de-identification through signing, guardrails on what may be asked and what may be answered, quotas, and logging. Secure AI Deployment Environments answers where the system runs, across four boundaries: placement, meaning whose hardware and which jurisdiction; isolation, meaning which other workloads share the trust zone; path, meaning what may reach the system and what the system may reach; and pipeline, the build and promotion route that machine-learning operations (MLOps) tooling runs, whose output becomes whatever production serves. Adversarial AI Risk Mitigation answers who is coming for it, sorting each named attack by the stage at which the attacker acts: training time for poisoning, the inference input for evasion and for prompt injection (instructions that reach the model in the same channel as the developer's own), the inference output for the privacy attacks that read a model through its answers, and the downstream action an answer sets off. Reach for the page whose question the scenario is straining.

Those three breakdowns are not rival taxonomies competing to describe one thing; each is the zoom-in on one axis of the same system, and a realistic scenario carries a value on all three. Take a model pulled from a public hub. The asset is the model artifact, which is why the controls page supplies the recorded digest, the publisher signature, and a weights format that cannot execute code when the file is loaded. The environment is the pipeline, which is why the deployment page routes that file through the single staging path it keeps for material arriving from outside, separate from training and production. The adversary acted at training time, which is where NIST's adversarial machine learning taxonomy sorts an attack that changes what a model learns, and that placement is what lets the adversarial page warn that a backdoor planted before the file reached you can survive your own fine-tuning. A control is worth what the environment behind it and the attack stage it covers make it worth, so an option that names one axis while ignoring the other two is usually the distractor.

SecAI+ is a framework exam, so answer options tend to be phrased in a published standard's vocabulary rather than in generic security language, and recognising the owning body narrows the field before you weigh any technical detail. No body is exclusive to one question: OWASP turns up on the adversary side too. Asset questions carry OWASP Top 10 for LLM Applications 2025 identifiers at the application layer and sit inside the four functions of the NIST AI Risk Management Framework, GOVERN, MAP, MEASURE and MANAGE, where GOVERN runs through the other three rather than opening a sequence. Environment questions lean on NIST SP 800-218A, which makes separating the development, model-training, build, test and distribution environments a high-priority task, on NIST SP 800-190 for the image, registry, orchestrator, container and host layers underneath, and on the Guidelines for Secure AI System Development published by the UK National Cyber Security Centre (NCSC) with the US Cybersecurity and Infrastructure Security Agency (CISA) and international partners, whose four development-lifecycle stages run from secure design to secure operation and maintenance. Adversary questions lean on the NIST taxonomy cited above, while MITRE ATLAS catalogues the techniques an attacker uses rather than the control you should implement, which is why an ATLAS identifier rarely answers a controls question.

One default settles most ties across all three pages. NIST's taxonomy is blunt that many tasks still have no theoretically secure algorithm, that published defences have repeatedly fallen to attacks designed against them, and that spotting an adversarial input is about as hard as building a model that resists one, so an answer resting on recognition of the malicious input is the weaker of two otherwise plausible options. OWASP draws the same line for systems that let a model act: logging and rate limiting limit the damage of excessive agency without preventing it, while cutting the model's functions, permissions and autonomy, or putting a human approval step in front of a high-impact action, is preventive. Assume the model will be fooled at some point, and pick the option that shrinks what being fooled can reach: fewer tool permissions, a smaller blast radius, and a documented way back to a previous version or to a path that does not use the model at all.