How to Build an AI Security Assessment Scope: What to Include and What to Skip

A common mistake in AI security assessments is trying to assess everything. Model behaviour, training data handling, prompt injection, jailbreaks, data privacy, governance documentation, API security, third-party integrations, output monitoring, incident response: all of these are legitimate areas of concern for an organisation deploying AI systems. Trying to address all of them in a single assessment produces shallow coverage across many areas rather than meaningful findings in the ones that matter most for your specific risk profile.

Good scoping is not about cutting corners. It is about concentrating assessment effort where it will produce the most useful information given the nature of the system being assessed and the organisation's actual risk exposure. The right scope for a RAG system deployed in a law firm is different from the right scope for a customer-facing chatbot with no access to sensitive data, which is different again from the right scope for an agentic AI system with access to internal systems. Scoping a single template across all of these is a reliable way to miss what matters.

Understand the System Before Scoping the Assessment

Effective scoping starts with a system characterisation: what the AI system does, what data it processes, what tools or actions it can take, who can interact with it, and what the business impact of a failure would be. This characterisation does not need to be exhaustive, but it needs to cover the dimensions that drive risk: data sensitivity, action capability, access profile, and exposure surface. A system that processes only publicly available information and can only generate text has a very different risk profile from one that handles personal information and can take actions in connected systems.

The characterisation should also identify what is in scope for the assessment: just the AI model and its prompting, or the full application stack including the APIs, authentication, data storage, and third-party integrations? For most AI security assessments, the AI-specific risks (model behaviour, prompt-based attacks, training data issues) are the primary focus, and the surrounding application security can be addressed in a separate engagement. Conflating the two produces scope that is too large to assess thoroughly and responsibility boundaries that are unclear.

A Risk-Profile-Driven Scoping Framework

At Cyberlinx, we use a risk-profile approach to scoping. The starting point is the system's position on two axes: data sensitivity (what data does the system handle or have access to) and action capability (what can the system do beyond generating text). High data sensitivity with high action capability warrants the broadest assessment scope. Low on both axes warrants a narrower focus.

For a high-sensitivity, high-capability system, the assessment scope would typically include adversarial prompting (direct and indirect injection), guardrail testing, agentic security including tool-use restriction and action logging, data handling and privacy risks, and governance controls. For a low-sensitivity, text-generation-only system, the scope might focus primarily on adversarial prompting and guardrail testing, with governance and data handling addressed through a lighter review. The key is that the scope is driven by the system's actual risk profile, not by a fixed template or a desire to generate a comprehensive-looking report.

What to Prioritise, Defer, or Skip

Prioritise areas where a failure would have direct business impact: the model behaviours that are closest to the system's core function, the data that is most sensitive, and the actions that are most irreversible. These are the areas where an attacker is most likely to focus, and where a finding will produce a clear, actionable remediation recommendation.

Defer areas where the risk is real but lower given the current system configuration. If the system does not currently have agentic capabilities, detailed agentic security assessment can be deferred until those capabilities are added. If the model used is a third-party hosted model rather than a fine-tuned proprietary model, detailed training data analysis is less relevant than prompt-level attack testing. Skip areas where the risk is genuinely low given the system context, and where assessment effort would be better spent elsewhere. A detailed governance assessment of a small internal prototype that handles no sensitive data is not a good use of limited assessment time. Scoping is about making those trade-offs explicitly, based on evidence, not assumptions.

• System characterisation comes before scoping: understand what the system does before deciding what to assess
• Data sensitivity and action capability are the two primary risk dimensions that drive scope
• Keep AI-specific assessment scope separate from general application security to maintain focus
• Prioritise assessment areas that are closest to the system's core function and highest-impact failure modes
• Defer agentic and training data assessment when those system characteristics are not present
• A focused, well-scoped assessment produces more actionable findings than a broad, shallow one

Cyberlinx works with Australian organisations to scope and conduct AI security assessments that are matched to actual risk profiles. If you are planning an AI security assessment and want help building a scope that reflects your system and your risk context, contact us at info@cyberlinx.com.au.