What an AI security assessment actually covers, and what it will not tell you
You have been told you need an AI security assessment. Three quotes have arrived and they describe three different pieces of work, ranging from a week of reading to an automated scan that finishes in an afternoon. Before comparing them it is worth knowing what the thing is supposed to contain — and, more usefully, what it is not able to tell you whatever you pay.
Published 22 September 2026. Written by the SecHB practice, Greater Vancouver, British Columbia.
The short version
An assessment has four parts, and a quote that is missing any of them is quoting something else. There is a scope, which says what was looked at. There is a method, which says what it was looked at against. There is a deliverable, which says what was found and what to do. And there is a boundary, which says honestly what the work did not cover.
Scope follows the system rather than a package: how many features put a model in the path, what those models can reach, how many tenants share a retrieval index, whether anything acts without a person approving it, and how much of the answer already exists in writing.
What is in scope
The unit of assessment is the system, not the model. A hosted model behind a thin wrapper and a self-hosted model with tool access to a production database are the same technology and entirely different exposures. Six layers are in scope, and a review that stops at the first two is a review of the wrapper.
| Layer | What is examined |
|---|---|
| Applications | The feature surface: who can reach it, authenticated or not, what the system prompt and guardrails actually do as distinct from what they are believed to do. |
| Models | Which models are in the path, hosted or self-run, what version is pinned, what changes when the provider updates underneath you, and what the contract says about your inputs. |
| Data flows | What enters a prompt, where it came from, what is retained, where it is stored, and which of it is personal information or otherwise regulated. |
| Identities | Whose credentials each component acts under — the signed-in user’s, a shared service account, or an agent identity nobody has reviewed. |
| Third-party services | Model providers, vector stores, evaluation tools, orchestration frameworks and the plugins wired into them, with the provenance evidence for each. |
| Governance around it | Who approves a new use, who is told when a model changes, what is written down, and which of it matches what the systems do. |
The method: a named checklist, with evidence per finding
The review runs against something named, so that coverage can be checked afterwards by someone who was not there. The usual pairing is the OWASP Top 10 for LLM Applications for what goes wrong in a system with a language model in it, and the NIST AI Risk Management Framework (AI RMF 1.0) for the governance questions around it. For the testing methodology itself, the OWASP AI Testing Guide is the open project consolidating structured approaches to testing AI systems.
Naming the checklist is what makes the negative result meaningful. If a review says nothing about vector and embedding weaknesses, the buyer needs to know whether that means “looked and found nothing” or “did not look”. Those are different reports and they cost different amounts.
Per finding, the artifact that proves it: the configuration line, the query result, the log entry, the screenshot, the prompt and response. A finding without an artifact is an opinion, and an opinion will not survive the engineer who has to act on it.
What the deliverable should contain
- A scope statement you can argue with. Systems, environments, dates, accounts used, and what was excluded and why.
- Findings, each with a reachable path. Not “prompt injection is a risk”, but the specific input source, the specific component it reaches, and the specific consequence.
- Evidence per finding. See above. This is the section that separates a report from a template.
- A remediation position, ranked. Ordered by what moves the most exposure per unit of effort, not by severity label alone, and naming the team that would do each one.
- Controls that are already real. What is working, and the evidence that it is working rather than configured.
- Coverage against the named checklist. Every category, with the result or the reason it was out of scope.
- The boundary. A written statement of what this work does not establish.
What an assessment will not tell you
No. An assessment reads the system as built and reports what an attacker could reach through it; a penetration test proves a specific attack works against a running instance, and is carried out only with signed authorization, to a scope agreed in writing. An assessment can tell you a path exists and is unguarded; only testing tells you it was walked.
It is also not a model safety evaluation. Whether the model behaves acceptably on the inputs you expect is a different question from what an attacker can reach, and neither answers the other.
And it is a point-in-time reading. The model provider will change the model, someone will wire in a new tool, and a retrieval corpus will grow to include a document store nobody mapped. An assessment tells you where you stand today and what to watch; monitoring is the thing that tells you when it stops being true.
Four questions that separate a real assessment from an automated scan
Automated tooling has a place in this work and none of these are aimed at it. They are aimed at a scan being sold as a review.
- “Which of our systems will you look at, and how will you know you have them all?” A real answer describes a discovery step. A scan answers with an endpoint.
- “What will the report say about the categories where you find nothing?” A real answer distinguishes clean from unexamined.
- “Can you show us a redacted finding from previous work?” You are looking for a reachable path and an artifact, not a severity badge and a paragraph of generic guidance.
- “Who reads the retrieval design, and what do they ask about it?” Tenant isolation in a vector store is not something a scanner reaches. If the answer is vague, the most expensive class of finding is out of scope and nobody said so.
What you need ready before it starts
The work goes faster and costs less when four things exist on day one: a list of the AI features in production and who owns each, whatever architecture documentation exists however stale, read access for the reviewers to the code and configuration, and a named engineer who can answer questions within a day. Missing the fourth is what actually stretches timelines.
Usually not. Most of the work runs on architecture, configuration, prompts, retrieval design, identity and code, in a read-only or pre-production environment where one exists, with production access limited to the questions that genuinely cannot be answered anywhere else.
It answers what most questionnaires are really asking — whether anyone competent has examined the AI feature and written down what they found — but it is a review rather than evidence that a named attack was attempted and failed. Where the buyer wants the second thing, testing is the engagement that produces it.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
Testing and adversary simulation are carried out only with signed authorization, to a scope agreed in writing.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
Is an AI security assessment the same as a penetration test?
No. An assessment reads the system as built and reports what an attacker could reach through it; a penetration test proves a specific attack works against a running instance, and is carried out only with signed authorization, to a scope agreed in writing.
Does it need production access?
Usually not. Most of the work runs on architecture, configuration, prompts, retrieval design, identity and code, in a read-only or pre-production environment where one exists, with production access limited to the questions that genuinely cannot be answered anywhere else.
Will it satisfy a customer questionnaire?
It answers what most questionnaires are really asking — whether anyone competent has examined the AI feature and written down what they found — but it is a review rather than evidence that a named attack was attempted and failed. Where the buyer wants the second thing, testing is the engagement that produces it.
What drives the scope?
Scope follows the system rather than a package: how many features put a model in the path, what those models can reach, how many tenants share a retrieval index, whether anything acts without a person approving it, and how much of the answer already exists in writing.
Where to go from here
The engagement itself is described on AI security assessment. If what you actually need is proof that a specific attack works, LLM application penetration testing is that instead. If a questionnaire started this, answering the AI security questionnaire deals with the answers directly. The rest of the AI security practice sits behind those, and the other pieces are indexed under Writing.
Describe the AI features in production, what they retrieve and what they can call, and the reply will say what an assessment of them would cover.