EXIN AISP Cheat Sheet: Threat and Control Distinctions
Recall AI attack mechanisms, authorization boundaries, data protections, testing evidence and the standards named in the EXIN AISP outline.
Use this reference after studying the official reading . In each scenario, trace asset → attacker access → action → observed effect → control boundary.
Classify the demonstrated mechanism
| Mechanism | Deciding evidence |
|---|---|
| Direct prompt injection | Instructions submitted directly to the model conflict with its intended application role. |
| Indirect prompt injection | Instructions arrive through lower-trust material such as retrieved documents or tool output. |
| Augmentation-data manipulation | Retrieved facts are changed; the content need not contain an instruction or change model weights. |
| Data poisoning | Attacker-controlled examples influence learning. Online learning can make that change during operation. |
| Direct model poisoning | The model artifact or parameters are modified directly. |
| Evasion | Crafted prediction inputs cause errors while the model’s parameters remain fixed. |
| Model extraction | Inputs and outputs or other available evidence support reproducing the model’s behavior. |
| Membership inference | The target is whether a record was included in training. |
| Model inversion | The attacker infers hidden information by analyzing model behavior. |
| Memorization-based disclosure | Model output reproduces confidential training information; distinguish this from inferring an attribute. |
| Development-time data leakage | Training/test data or their copies escape the development environment. |
| Runtime input-data leakage | Prompts or other inference inputs are exposed through handling, storage or transmission. |
An attack can cross several boundaries. A malicious retrieved instruction may cause an unsafe shell command, but the shell-execution defect is different from the prompt-injection entry point. Answer the question at the boundary it asks about.
What common controls do—and do not—prove
| Control or evidence | Useful conclusion | Remaining question |
|---|---|---|
| Matching checksum | Bytes match a reference. | Can the attacker replace the reference too? |
| Valid signature | Integrity and attribution relative to the verified signing key. | Is that key trusted for this publisher, and is the content safe? |
| Encryption at rest | Protects stored ciphertext under the configured access model. | Can an authorized process export readable data? |
| Authenticated account | Establishes identity. | Is this operation on this object within the approved task? |
| Prompt instruction or delimiter | Gives the model guidance and structure. | What application control blocks an unwanted action? |
| Human oversight | Can provide a decision or correction. | Does review occur before impact, with adequate evidence, authority and capacity? |
| Supplier assurance report | Supports claims within its stated scope. | Who operates the customer integration and connected tools? |
Bind tools to the authenticated user and the delegated task. A user who may refund any account has not necessarily asked the agent to refund every account. Apply authorization at execution; do not infer permission from generated text.
Govern and assess risk
GUARD: Govern, Understand, Adapt, Reduce and Demonstrate are interacting activities, not a mandatory incident-response sequence. An inventory and owner support governance; threat analysis establishes applicable exposures; tests demonstrate bounded evidence.
Use the probability and consequence definitions given in the scenario. When annual expected loss is explicitly defined as probability × loss, compare current verified residual estimates, not untreated risk or forecast benefits from an unimplemented control. Risk-owner acceptance records a decision; it does not prove the control works.
Protect data without losing the required task
Replacing names with linkable aliases is pseudonymization, not automatic anonymity. Monitoring prompts can create a sensitive data store even when no attack is detected. Reduce collection, access and retention while preserving necessary security evaluation.
A smaller retrieval cap can reduce the number of exposed records without reducing attack success frequency or harm to each person. Evaluate those measures separately. Keeping a protected attribute out of model inputs also does not remove the possible need for controlled subgroup evaluation.
Interpret test results carefully
Record authorization, environment, test data, model version, configuration and allowed effects. A simulator with a live fallback can breach scope even when a smoke test hits a recorded response. A clean-task success is not an adversarial test.
When several controls change, report what the trace demonstrates. If an injected tool request still occurs but execution is denied, the test shows authorization containment, not proof that the model ignored the injection. Check regressions and other relevant attack paths before generalizing.
Standards and compliance roles
| Reference | Main purpose in AISP preparation |
|---|---|
| ISO/IEC 23894 | AI risk-management guidance. |
| ISO/IEC 27005 | Information-security risk-management guidance. |
| ISO/IEC 42001 | Organizational AI management-system requirements. |
| ISO/IEC 5338 | AI system lifecycle processes. |
| GDPR | Personal-data principles and factual controller/processor responsibilities. |
| EU AI Act | Roles and obligations depend on intended use and the applicable system category. |
Consent is one possible lawful basis, not the answer to every data-use question. Publicly readable text, attribution or lawful model training does not by itself establish a right to republish protected expression in an output. Use the scenario’s jurisdiction and facts; consult the official sources for current requirements.