Framework

OWASP AISVS
AI Application Security Verification Standard at L1, L2, and L3

The OWASP Artificial Intelligence Security Verification Standard (AISVS) is the open standard that defines what a verified secure AI application looks like, control by control. Pick a verification level (AISVS-L1 essential, AISVS-L2 defence in depth, AISVS-L3 high assurance), test against the named controls across training data, model lineage, input handling, output handling, authentication, retrieval-augmented generation, agent action boundaries, memory, monitoring, privacy, supply chain, testing, resilience, and governance, and produce a verification report that maps findings to AISVS rather than to a generic LLM risk list. SecPortal runs AISVS engagements as structured records with control-level traceability across the AI application, the backend it sits inside, the inference surface, and the model supply chain.

Get Started Free

No credit card required. Free plan available forever.

OWASP AISVS: a verification standard for AI applications, not just a risk list

The OWASP Artificial Intelligence Security Verification Standard (AISVS) is the open standard that defines what a verified secure AI application looks like, control by control. Where the OWASP Top 10 for LLM Applications ranks the most common LLM-specific risks (and the companion LLM Top 10 explainer walks each risk in plain language), AISVS describes which controls have to be in place and which tests have to pass for an AI application to be considered verified at a given level. AISVS is published by the Open Worldwide Application Security Project, sits in the same family of verification standards as OWASP ASVS for web and API applications and OWASP MASVS for mobile applications, and is structured so the verification claim is comparable across providers and over time.

For internal AppSec teams running an AI-application verification programme, product security teams owning a generative AI feature surface, AI and ML engineering teams shipping LLM and agent applications, AI safety and red-team functions, GRC and compliance teams mapping to the ISO/IEC 42001 AI management system, the NIST AI Risk Management Framework, or the EU AI Act, and CISOs carrying the audit-committee read against the AI programme, AISVS is the verification standard the technical evidence reads against. The standard is dense; the value is the control-level traceability that turns AI security from a one-off red team into a continuous operating record.

This page covers the AISVS verification levels, the AISVS control chapters, the verification reporting expectations, where AISVS sits next to OWASP ASVS, the OWASP LLM Top 10, NIST AI RMF, ISO/IEC 42001, the EU AI Act, and OWASP MASVS, the buyer and operator read for AppSec teams and AI engineering, and how SecPortal operates an AISVS verification engagement as one structured record.

AISVS verification levels: pick the level on purpose

AISVS defines three verification levels. The level is a contractual decision: a Level 1 engagement reported as Level 2 is a scope breach, and a Level 2 engagement reported as Level 1 is a value gap. Decide the level during pre-engagement, name it in the rules of engagement, and reflect it on every page of the verification report. The level decision is typically anchored in the EU AI Act risk classification (if applicable), the data sensitivity, the agentic depth, and the decision impact.

AISVS-L1 (essential security)

Defends against the AI-application risks any consumer-facing or internal-facing AI surface should be protected against without additional threat-model justification. Level 1 expects sound use of platform AI APIs, no clear-text storage of regulated content in prompts and outputs, basic input and output handling against prompt injection and unsafe output, model-call authentication, and rate-limit and abuse controls. It is verifiable through a mix of automated static analysis against the application code, dynamic testing against the inference endpoint, and a focused manual pass against the named AISVS-L1 controls. A Level 1 verification report names the controls in scope and the deviations and is honest about what was not exercised.

AISVS-L2 (defence in depth)

Adds defence in depth for AI applications handling regulated, financial, healthcare, or otherwise sensitive data, or AI applications operating with elevated permissions (tool use, agentic actions, code execution, payment authority). Level 2 expects evidence-based testing of training-data lineage and integrity, model lineage and integrity, retrieval-augmented generation isolation, agent-tool permission boundaries, conversation-memory privacy, output filtering for sensitive content, and abuse-pattern detection, mapped control by control rather than as a generic finding list. Level 2 is the default for enterprise AI deployments where the AI surface holds or generates regulated data.

AISVS-L3 (high assurance, agentic and high-impact)

Adds high-assurance controls for AI applications operating with significant autonomy (multi-step agentic workflows, code execution, financial transactions, healthcare decision support, safety-critical advice) or for AI applications that materially shape an organisational decision the operator cannot economically review every output of. Level 3 expects independent verification of the training-data provenance chain, model integrity attestation, agent action allow-listing with named scope per tool, replayable conversation logs, human-in-the-loop checkpoints for material decisions, and abuse-and-safety red-team evidence. Level 3 pairs naturally with EU AI Act high-risk classification, NIST AI RMF GOVERN tier, and ISO/IEC 42001 high-impact AI system designation.

For a longer treatment of the operating model that runs the AI security programme around an AISVS engagement, see the MLSecOps implementation guide and the AI security posture management explainer, which together cover the wider AI security operating layer the AISVS verification fits inside.

The AISVS control chapters: what gets verified

AISVS is organised into control chapters covering training data through to governance, with explicit applicability for Level 1, Level 2, and Level 3 against each control. The verification report references those chapter identifiers directly, which is what makes AISVS engagements comparable across providers and over time. The chapter list below reflects the AISVS structure at the time of writing; the live standard is published on the OWASP project page and refreshed by the contributing community.

C1: Training data governance

Verify that training data has documented provenance (source, collection method, consent basis, licence), documented quality controls (deduplication, contamination checks, label-quality validation), documented sensitivity controls (PII filtering, regulated-data exclusion, copyright handling), and a documented retention and disposal record. Training-data controls underwrite GDPR Article 5 and 6 lawful processing, the EU AI Act Article 10 data and data governance obligations, and any sectoral data-handling regime (HIPAA for healthcare AI, PCI DSS for financial AI, GLBA for US financial AI).

C2: Model governance and lineage

Verify that each model in scope carries a documented lineage (training data version, training procedure, evaluation result, intended use), a documented integrity record (model card, model hash or signed manifest, deployment provenance), a documented safety evaluation record (red-team coverage, refusal-rate evaluation, jailbreak resistance evaluation), and a documented update cadence (when the model is refreshed, what triggers a refresh, what the regression evaluation covers).

C3: Input handling and prompt processing

Verify that inputs are validated and sanitised before reaching the model, that prompt injection vectors are tested across direct, indirect via retrieved content, indirect via tool outputs, and indirect via uploaded files, that the user-input boundary is segregated from the system-instruction boundary, and that input-derived content does not silently escalate trust. C3 maps directly to OWASP LLM Top 10 LLM01 prompt injection and to the indirect-prompt-injection-via-RAG class that pure C1 input filtering does not catch.

C4: Output handling and downstream effects

Verify that model outputs are filtered for sensitive content before display, that outputs are not directly executed without validation when the output drives a tool call or code path, that outputs are not silently trusted as authoritative for downstream decisions, and that streaming outputs respect the same filtering and validation rules as buffered outputs. C4 maps directly to OWASP LLM02 insecure output handling and to LLM06 sensitive information disclosure for output-path leakage.

C5: Authentication, authorisation, and rate-limiting on inference

Verify that every inference request carries a verifiable identity, that the inference endpoint enforces the same authorisation model as the backend it sits inside, that rate-limiting and abuse-detection apply to inference requests, and that per-user inference budgets are documented and enforced. C5 maps to OWASP LLM10 unbounded consumption and to the authentication and access-control discipline OWASP ASVS V2 and V3 already specify for the backend surface.

C6: Retrieval-augmented generation (RAG) and external data

Verify that retrieved context is isolated from system instructions, that the retrieval source list is named and access-controlled, that retrieval cannot exfiltrate cross-tenant data, that retrieved content is treated as untrusted input for downstream processing, and that the RAG pipeline is exercised against indirect prompt injection embedded in retrieved documents. C6 is the chapter most modern enterprise AI deployments depend on and the chapter most commonly under-tested.

C7: Agent action boundaries and tool use

Verify that each tool the agent can call is named, scoped, and allow-listed, that the parameters the agent can pass to each tool are validated against an allow-list rather than a deny-list, that destructive actions require a human-in-the-loop confirmation step, that the agent cannot escalate its scope through tool composition, and that the agent action log is replayable. C7 maps to OWASP LLM06 excessive agency and is the chapter that distinguishes a chat assistant from an agentic application.

C8: Memory, conversation history, and privacy

Verify that conversation memory does not leak across users, that long-term memory features are opt-in and revocable, that memory storage respects the same retention controls as the rest of the application data, that PII captured in conversation is detected and handled per the privacy programme, and that memory is included in the data-subject-access and data-subject-deletion workflows. C8 ties AISVS verification to GDPR data-subject rights, CCPA, the EU AI Act transparency obligations, and the privacy-evidence pack the GRC programme depends on.

C9: Logging, monitoring, and incident detection

Verify that inference requests, model responses, tool calls, and agent actions are logged with sufficient detail to reconstruct an incident, that the log retention satisfies the regulator and audit reads, that abuse and safety signals are surfaced as findings the security team can act on, that the log surface does not itself leak sensitive content, and that the monitoring pipeline can distinguish a model degradation from an active abuse pattern. C9 maps to OWASP LLM05 inadequate AI alignment monitoring and to the wider logging-and-monitoring discipline OWASP ASVS V7 already specifies.

C10: Privacy and consent

Verify that the AI application discloses its use of AI to the user, that the data-use disclosure is granular and accurate, that consent for sensitive uses is captured at the boundary appropriate to the regime (GDPR Article 6 lawful-basis, CCPA notice, EU AI Act Article 50 transparency, US sectoral obligations), and that the third-party model and inference provider relationships are surfaced in the privacy notice and DPIA. C10 connects AISVS verification to the privacy programme and to the data-protection-impact-assessment record.

C11: Supply chain and dependencies

Verify that the model supply chain is documented (the foundation model and its provenance, fine-tuning datasets and their provenance, model weights integrity, model-serving infrastructure), that the third-party AI SDK and library inventory is tracked and patched, that AI bill of materials artefacts are produced and refreshed, and that the supplier-side security posture of the foundation-model provider is documented. C11 maps to OWASP LLM03 supply chain and connects to NIST SSDF and CISA secure-by-design.

C12: Testing and verification programme

Verify that the AI application carries a documented test pack covering safety evaluations (red-team coverage, jailbreak resistance, refusal correctness, hallucination rate, bias and fairness), security evaluations (prompt injection coverage, indirect-injection coverage, agent-action boundary coverage, output handling), and integration evaluations (the backend the AI sits inside still satisfies OWASP ASVS for the wider surface). C12 ties AISVS verification to a repeatable test record rather than a one-time assessment.

C13: Resilience and safe failure

Verify that the AI application degrades safely when the model is unavailable, when the model is producing unsafe outputs, when the model is producing biased outputs, or when an abuse pattern is detected, that the fallback path is documented and exercised, that the safety filter cannot be silently bypassed, and that the safe-failure posture is tested across normal, abusive, and degraded operating conditions. C13 is the chapter that distinguishes a model-in-production from a model-in-experiment.

C14: Human oversight and governance

Verify that the AI application has a documented human-oversight model proportionate to the decision impact (advisory output, decision-supporting output, automated decision, autonomous action), that named human reviewers exist for high-impact decisions, that the override and feedback channel is documented and operated, and that the governance committee or accountable owner reviews the operating record on a documented cadence. C14 ties AISVS verification to the wider AI governance discipline ISO/IEC 42001 and the EU AI Act expect.

The control set is broad on purpose. A verification claim that exercises only input handling (C3) and output handling (C4) is a partial verification, not a full AISVS engagement at the declared level. When scoping an AISVS test, write down the chapters in scope and the chapters explicitly out of scope, so the report cannot be read as a stronger claim than was tested. For the LLM-Top-10-specific finding shape that flows into the C3 and C4 chapters, see the prompt injection vulnerability page, the indirect prompt injection via RAG vulnerability page, the improper output handling in LLM vulnerability page, the excessive agency in LLM applications vulnerability page, the system prompt leakage vulnerability page, and the data and model poisoning vulnerability page. Each maps to one or more AISVS controls and feeds the verification report as evidence.

AISVS reporting expectations: the deliverable, not an export

An AISVS verification report is a structured deliverable, not a wrap-up. The report is the artefact the buyer pays for, the assessor reviews, and the auditor cites, so its structure and evidence density determine whether the verification was actually useful. The expectation list below covers the minimum the verification claim needs to carry to read defensibly.

  • Verification level claim (AISVS-L1, AISVS-L2, AISVS-L3) declared up front, with the reason the level was chosen rather than a higher or lower one. The level decision is anchored in the EU AI Act risk classification (if applicable), the data sensitivity, the agentic depth, and the decision impact.
  • In-scope AISVS control groups listed by chapter identifier (for example C3-1, C7-2), with explicit deviations documented for any control excluded with a reason. The control inventory reads at the chapter level so a reviewer can see at a glance which depths were exercised and which were not.
  • Asset list named (the AI application identifier, the model and version in scope, the inference endpoint, the foundation-model provider, the retrieval index in scope, the tool set the agent can call, the backend services in scope, and the data sources the model can read or write).
  • Findings logged against the AISVS control they evidence, with a CWE identifier where applicable, the OWASP LLM Top 10 mapping, and a CVSS 3.1 vector for severity. Findings without an AISVS mapping are downgraded to general AppSec findings outside the verification claim.
  • Evidence inline with each finding: prompt sequence, retrieved-context excerpt, tool-call log, decompiled snippet (for client-side AI applications), request and response, screenshot, or short clip, retained on the same record so a reviewer can validate the result without asking for the working file.
  • Safety evaluation pack alongside the security findings: refusal-rate evaluation result, jailbreak-resistance evaluation result, hallucination-rate evaluation result, bias and fairness evaluation result, with the evaluation prompt set or red-team script identifier so the test is reproducible.
  • Remediation guidance written for the AI engineering audience that will fix the finding, citing the AISVS control, the OWASP LLM Top 10 mapping, and the platform AI API or framework feature rather than restating the vulnerability description.
  • Retest scope agreed at kickoff (the retest count, the retest window, the verification method per finding, and the regression evaluation against the safety evaluation pack) so the verification report can include verified-fixed status without renegotiation.
  • Closure record covering the original finding, the proposed fix, the retest evidence on a clean build, the safety regression result, and the final outcome, so the verification claim is a record rather than a pdf attached to an email.

For deeper context on how to structure a security verification report end to end, see how to write a pentest report and the matching penetration testing report template. The AI report generation feature composes the executive summary, technical body, safety evaluation summary, and remediation roadmap from the underlying engagement and findings, citing the AISVS controls that were exercised rather than starting from a blank template.

How AISVS sits next to ASVS, the LLM Top 10, NIST AI RMF, ISO 42001, and the EU AI Act

AISVS is rarely used in isolation. It is the requirement set that other documents cite, run against, or wrap. The contrast below is a working view, not a buyer comparison: the practitioner question is which standards to pair AISVS with, not which to pick instead of it.

AISVS vs ASVS

OWASP ASVS is the verification standard for the wider web and API surface; AISVS is the verification standard for the AI application that sits inside it. The two share the same level structure (L1 essential, L2 defence in depth, L3 high assurance) and the same engagement shape, but AISVS adds chapters specific to AI applications (training data governance, model governance, RAG, agent action boundaries, conversation memory, AI-specific monitoring, AI supply chain, safety evaluation, human oversight). Engagements covering an AI application typically declare an ASVS level for the wider backend tier and an AISVS level for the AI tier separately, on the same engagement record, with findings mapped to the right standard.

AISVS vs OWASP LLM Top 10

The OWASP Top 10 for LLM Applications is a ranked list of the most common LLM-specific risks (LLM01 prompt injection, LLM02 insecure output handling, LLM03 supply chain, LLM04 data and model poisoning, LLM05 inadequate monitoring, LLM06 excessive agency, LLM07 system prompt leakage, LLM08 vector and embedding weaknesses, LLM09 misinformation, LLM10 unbounded consumption). AISVS is a verification standard that says, control by control, what a verified secure AI application looks like. The two compose: an LLM Top 10 finding maps to one or more AISVS controls, and an AISVS verification covers the broader requirement set including controls that the LLM Top 10 does not explicitly enumerate (training-data governance, model lineage, conversation memory privacy, human oversight). A pentest scoped to the LLM Top 10 covers the headline risks; an AISVS engagement covers the requirement set and produces a verification report rather than a finding list.

AISVS vs NIST AI RMF

NIST AI RMF (the AI Risk Management Framework with GOVERN, MEAP, MEASURE, MANAGE functions) is the framework-level outcome model for AI risk management. AISVS reads beneath as the verification standard for the technical security and safety controls the AI RMF MEASURE function expects. Programmes operating against the AI RMF use AISVS as the implementation companion that supplies the operating depth the framework-level outcomes are evidenced through.

AISVS vs ISO/IEC 42001

ISO/IEC 42001 is the AI management system standard that names the policies, the processes, and the management discipline an AI-producing organisation operates against. AISVS is the technical verification standard for the AI applications the management system covers. The two compose: ISO/IEC 42001 says how the AI programme is governed; AISVS says how the AI application is verified. Programmes certifying against ISO/IEC 42001 typically operate AISVS as the verification standard the technical evidence the Annex A controls reference reads against.

AISVS vs EU AI Act

The EU AI Act is the EU regulation that classifies AI systems by risk (unacceptable, high-risk, limited risk, minimal risk) and imposes obligations proportionate to the classification. AISVS reads beneath as the verification standard for the technical obligations the high-risk classification entails: Article 9 (risk-management system), Article 10 (data and data governance), Article 13 (transparency), Article 14 (human oversight), Article 15 (accuracy, robustness, cybersecurity). High-risk AI deployers and providers operating against the EU AI Act use AISVS as the technical verification companion that supplies the evidence the conformity assessment reads against.

AISVS vs OWASP MASVS

OWASP MASVS is the verification standard for mobile applications. AISVS is the verification standard for AI applications. The two are independent verification scopes that may co-exist on one product: a consumer-facing mobile AI assistant is typically scoped under MASVS for the mobile binary and the backend it calls, and under AISVS for the AI tier of the same product. Engagements that cover both standards declare each level claim separately on the same engagement record.

Buyers procuring an AI engagement under a regulated framework should pair AISVS with OWASP ASVS for the wider backend tier of the same application, with ISO/IEC 42001 for the AI management system the verification operates inside, with NIST AI RMF for the framework-level outcome model, with NIST SSDF for the secure-development practices the AI application is built under, and with CISA Secure by Design for the default-secure commitment the AI application makes to its users.

Adjacent OWASP and CISA references

AISVS reads alongside several OWASP and CISA references. Each one covers a different slice of the AI security operating model; AISVS is the verification companion that converts the risk and outcome statements into control-level requirements.

AISVS and the OWASP Top 10 for LLM Applications

The OWASP Top 10 for LLM Applications is a ranked list of the most common LLM-specific risks. AISVS is the broader verification standard the LLM Top 10 findings map into at the control level. Most AISVS engagements include LLM Top 10 coverage in the scope statement so the headline risks are tested alongside the broader requirement set.

AISVS and the OWASP Machine Learning Security Top 10

The OWASP Machine Learning Security Top 10 is the ranked list of the most common machine-learning-specific risks (model adversarial attacks, data poisoning, supply-chain compromise, model theft, transfer-learning attacks, model inversion, output manipulation, prompt injection where applicable, model denial of service, insecure online learning). AISVS reads alongside as the verification standard that converts the ML Top 10 risks into control-level requirements.

AISVS and CISA Secure by Design

CISA Secure by Design is the voluntary pledge framework for software producers committing to default-secure software products. CISA has extended the secure-by-design principles into AI-specific guidance for AI software producers. AISVS reads beneath as the verification standard the secure-by-design AI claims are evidenced through.

AISVS and NIST SSDF

NIST SSDF (Secure Software Development Framework, SP 800-218) is the secure-development practices framework. AISVS reads as the verification companion for the AI application that the SSDF practices produce. The SSDF Verify practice category (PW.8 verify third-party components, PS.3 verify intentional behaviour) is the place AISVS verification evidence flows into when the AI application is part of a CISA Secure Software Development Attestation submission.

AISVS for AppSec teams, AI engineering, product security, and AI governance

AISVS is read differently depending on which side of the engagement you sit on. AppSec teams use AISVS as the internal bar that the AI engineering team builds against, and as the structure that triages findings from prompt-injection evaluations, output-handling reviews, agent-action audits, and code-and-dependency scanning into one comparable picture. Product security teams use AISVS as the verification standard their AI feature ships under, with the verification report driving the feature go-live decision and the residual-risk position. AI engineering teams use AISVS as the requirements specification their model and prompt infrastructure satisfies, especially C1 training data governance, C2 model lineage, C6 RAG, and C7 agent action boundaries. AI governance committees use AISVS as the technical evidence layer their high-impact AI decisions read against under ISO/IEC 42001 and the EU AI Act.

The persona-specific entry points are SecPortal for AppSec teams, SecPortal for product security teams, SecPortal for application security programme leads, SecPortal for security engineering teams, and SecPortal for GRC and compliance teams. Each anchors a different view of the same AISVS engagement record.

For firms that specialise in AI and ML security assessments rather than running AI as one of several practices, the SecPortal for AI and ML security consultancies page covers the operating model that fits a specialist AI security practice, including finding evidence fields tuned to AISVS controls and the retest workflow that pairs verification to the original finding across each new model release.

Where AISVS sits next to other framework pages

AISVS is the AI-application verification standard; the adjacent framework pages cover the regimes the AISVS engagement reads alongside. The pages below are the ones AISVS programmes most often read together.

  • The OWASP ASVS framework page covers the verification standard for the wider web and API surface the AI application sits inside. ASVS and AISVS read together on most AI engagements.
  • The OWASP MASVS framework page covers the mobile verification standard. Consumer-facing AI assistants are typically scoped under MASVS for the mobile binary and AISVS for the AI tier.
  • The ISO/IEC 42001 framework page covers the AI management system standard. AISVS verification supplies the technical evidence the ISO 42001 Annex A controls reference.
  • The NIST AI RMF framework page covers the AI Risk Management Framework. AISVS reads beneath the MEASURE function as the control-level verification standard.
  • The NIST SSDF framework page covers the secure-development practices. AISVS reads as the verification companion for AI-specific code paths the SSDF Verify practice category expects to exercise.
  • The CISA Secure by Design framework page covers the default-secure software commitment. AISVS reads beneath as the verification standard the secure-by-design AI commitments are evidenced through.
  • The EU Cyber Resilience Act framework page covers the EU product cybersecurity regulation for products with digital elements. AISVS reads as the technical verification companion for AI features inside CRA-in-scope products.
  • The OWASP Web Security Testing Guide framework page covers the testing technique reference for web applications. AISVS reads alongside as the AI-specific verification standard, with the WSTG supplying the test technique for the non-AI tiers and AISVS supplying the AI-tier requirements.

Where SecPortal fits in an AISVS verification engagement

SecPortal is the operating layer for an AISVS verification engagement. The platform handles scope, level claim, control coverage, backend authenticated DAST evidence, AI application codebase SAST and SCA evidence, prompt-injection and indirect-injection evaluation results, agent-action audit findings, output-handling findings, finding triage, retests, and the final deliverable, so the engagement runs as a single workflow rather than a long email thread with attachments and screenshot zips. For consultancies running AI security engagements on behalf of multiple clients, the AI and ML security consultancies workspace bundles that with branded client portals.

  • Engagement management captures the AISVS verification level, the in-scope control chapters, the AI application identifier, the model and version under test, the inference endpoint, the retrieval index, the tool set, the rules of engagement, the testing window, and the agreed retest scope as a structured record so the engagement scaffold is the workflow rather than a contract attachment.
  • Findings management stores each finding with a CVSS 3.1 vector, severity, evidence, owner, OWASP LLM Top 10 category, CWE identifier, and a free-text mapping field for the AISVS control being verified, so the verification report writes itself from the underlying records.
  • Code scanning runs SAST and SCA against the AI application codebase via the Git provider connection (GitHub, GitLab, Bitbucket), so AISVS-C11 supply chain evidence (AI SDK dependency hygiene, model-library inventory) is captured against the same engagement as the runtime testing.
  • Authenticated scanning runs DAST modules against the backend the AI application sits inside, with credentials stored encrypted at rest under AES-256-GCM, so AISVS-C5 authentication and AISVS-C6 RAG and external data evidence covers the inference surface and the backend API surface together.
  • Bulk finding import accepts the prompt-injection evaluation results, the jailbreak-resistance evaluation results, the bias and fairness evaluation results, and the red-team output files as CSV intake with column mapping, so the safety evaluation pack reads against the same finding ledger as the security findings.
  • AI-assisted report generation composes the executive summary, the technical body, the safety evaluation summary, and the remediation roadmap from the live engagement and findings, citing the AISVS controls that were exercised rather than starting from a blank template.
  • Compliance tracking lets one AISVS engagement satisfy framework mappings to OWASP ASVS for the wider backend surface, ISO/IEC 42001 AI management system controls, NIST AI RMF GOVERN MEASURE MAP MANAGE functions, EU AI Act Article 9 (risk-management system), Article 10 (data and data governance), Article 12 (record-keeping), Article 13 (transparency), Article 14 (human oversight), Article 15 (accuracy, robustness, cybersecurity), and the sectoral regime that applies (HIPAA for healthcare AI, PCI DSS for financial AI, FFIEC for US banking AI).
  • Retesting workflows pair each finding to a verification step on a clean build, with the safety evaluation regression record attached, so the closure record carries the full evidence chain.
  • Activity log with CSV export captures every state change to the engagement, the findings, the override decisions, and the retests, so the auditor or regulator can reconstruct the verification operating record without a multi-team excavation.
  • Document management for the AI application model card, the data sheet, the system card, the safety policy, the prompt template inventory, the tool inventory, the AI bill of materials, the DPIA (where required), and the safety evaluation pack, with version history per artefact and named custodian per file.
  • Team management with role-based access (owner, admin, member, viewer, billing) that keeps AI engineering, AppSec, ML engineering, AI safety, data protection, GRC and compliance, security operations leaders, and the AI governance committee on the same workspace with appropriate scoping per surface.
  • Multi-factor authentication enforcement at workspace level for the AISVS operating records, so the identity assurance applies at access time as well as evidence time.
  • Finding overrides for the residual gaps that cannot be closed within one engagement (named approver, scope, cited reason, hard expiry, compensating control, refresh trigger) so the deferral is evidenced rather than silent.

What SecPortal does not do

AISVS is a verification standard for AI applications and depends on the organisation operating AI engineering, AI safety, AppSec, product security, GRC and compliance, and AI governance as coordinated functions. SecPortal is the operating record for the AISVS verification engagement, not the AI development platform, not the model-evaluation framework, not the AI red team service provider, and not the third-party AI audit firm. The honest scope below reads against the AISVS boundary so the platform commitment is unambiguous.

  • SecPortal is not an AI red team service. The platform does not author the prompt-injection corpus, the jailbreak attack scripts, the agent-action attack chains, or the multi-turn safety eval prompts. The red-team workstream is run by the AI security team or by an external AI red-team provider; SecPortal carries the engagement record, the findings, the retests, and the verification report the red team produces.
  • SecPortal is not a model-evaluation framework. The platform does not run lm-eval-harness, HELM, BIG-bench, MLPerf, Inspect AI, AI Verify, AISI Inspect, or any other model-evaluation harness. The evaluation runs where the eval infrastructure runs; SecPortal accepts the eval result file via bulk finding import as structured findings on the workspace.
  • SecPortal is not an MLOps platform. The platform does not connect to MLflow, Weights & Biases, Comet, ClearML, Neptune, DVC, Kubeflow, SageMaker, Vertex AI, Azure Machine Learning, or any other MLOps platform. The ML lifecycle is operated where the training and serving infrastructure is; SecPortal carries the AISVS verification record alongside the MLOps record rather than replacing it.
  • SecPortal does not host AI models. The platform does not run inference, does not connect to OpenAI, Anthropic, AWS Bedrock, Google Vertex, Azure OpenAI Service, Hugging Face Inference Endpoints, Cohere, Mistral, or any other inference provider, and does not serve as an LLM gateway, proxy, or guardrail. The inference runs where it runs; SecPortal carries the verification evidence the inference surface generates.
  • SecPortal does not replace the AI governance committee, the accountable AI owner, the AI safety lead, or the data protection officer. The platform carries the operating record so the verification programme is durable rather than tribal; the named owner runs the programme, the safety lead authors the safety policy, the AI governance committee approves the decision impact tier, and the DPO signs off the DPIA.
  • SecPortal does not issue or verify AISVS certifications, ISO/IEC 42001 certifications, EU AI Act conformity assessments, or any other third-party certification. Certification is performed by an accredited certification body. SecPortal carries the operating record the auditors and the conformity assessors read against, with the artefact pack the audit fieldwork reads continuously rather than reconstructed at examination time.
  • SecPortal does not ship packaged connectors into Jira, ServiceNow, Slack, Microsoft Teams, SIEM, SOAR, GRC platforms, or AI-governance platforms. The AISVS findings live on the SecPortal workspace and the wider operational ticketing remains in the systems where the rest of the work is tracked.

The operational workstreams the AISVS programme reads against already exist as named use cases on SecPortal. The security onboarding for new applications workflow covers the per-application onboarding that the AISVS verification engagement attaches to. The code review use case covers the SAST and SCA evidence the C11 supply chain control reads against. The cross-framework control mapping workflow reads the same AISVS evidence pack across OWASP ASVS, ISO/IEC 42001, NIST AI RMF, EU AI Act, and CISA Secure by Design so the cross-regime read is reconcilable rather than reconciled per audit.

For deeper reading on the disciplines this standard reads against, the OWASP Top 10 for LLM Applications explainer covers the ranked LLM risk list that AISVS controls map into. The AI bill of materials guide covers the supply-chain artefact AISVS C11 expects. The secure code review for AI-generated code guide covers the developer-facing review discipline that flows into AISVS evidence on the code path. The MLSecOps implementation guide covers the operating model around the verification engagement.

Key control areas

SecPortal helps you track and manage compliance across these domains.

C1: Training data governance

Verify provenance, quality, sensitivity controls, and retention for the data the model was trained or fine-tuned on. Underwrites GDPR Article 5 and 6 lawful processing, EU AI Act Article 10 data and data governance, and the sectoral data-handling regime (HIPAA, PCI DSS, GLBA).

C2: Model governance and lineage

Verify documented model lineage (training data version, evaluation result, intended use), integrity record (model card, model hash or signed manifest), safety evaluation record (red-team coverage, refusal-rate, jailbreak resistance), and update cadence.

C3: Input handling and prompt processing

Verify input validation, prompt injection coverage (direct, indirect via retrieval, indirect via tool output, indirect via files), user-input vs system-instruction segregation. Maps to OWASP LLM01.

C4: Output handling and downstream effects

Verify output filtering for sensitive content, prevention of unvalidated tool calls or code execution, output-trust scoping, streaming-output handling. Maps to OWASP LLM02 and LLM06.

C5: Authentication, authorisation, and rate-limiting on inference

Verify identity on every inference request, authorisation parity with the backend, rate-limiting and abuse detection, per-user inference budgets. Maps to OWASP LLM10 unbounded consumption and OWASP ASVS V2 and V3.

C6: Retrieval-augmented generation (RAG) and external data

Verify context isolation from system instructions, named and access-controlled retrieval sources, cross-tenant exfiltration prevention, untrusted-input treatment of retrieved content, indirect-prompt-injection coverage on retrieved documents.

C7: Agent action boundaries and tool use

Verify named, scoped, allow-listed tools, allow-list parameter validation, human-in-the-loop for destructive actions, scope-escalation prevention through tool composition, replayable agent action logs. Maps to OWASP LLM06 excessive agency.

C8: Memory, conversation history, and privacy

Verify memory does not leak cross-user, long-term memory is opt-in and revocable, memory respects retention controls, conversation PII is handled per the privacy programme, memory is included in DSAR and DSAD workflows.

C9: Logging, monitoring, and incident detection

Verify inference, response, tool call, and agent action logging with reconstruction-grade detail, regulator-and-audit retention, abuse and safety surfacing as findings, log-surface confidentiality, abuse-vs-degradation distinction.

C10: Privacy and consent

Verify AI-use disclosure, granular data-use disclosure, regime-appropriate consent capture (GDPR Article 6, CCPA, EU AI Act Article 50, sectoral), third-party model and inference provider surfacing in the privacy notice and DPIA.

C11: Supply chain and dependencies

Verify documented model supply chain (foundation model provenance, fine-tuning data provenance, weights integrity, serving infrastructure), AI SDK and library inventory hygiene, AI bill of materials artefact, supplier-side security posture documentation. Maps to OWASP LLM03.

C12: Testing and verification programme

Verify safety evaluations (red-team, jailbreak, refusal, hallucination, bias), security evaluations (prompt injection, indirect-injection, agent-action, output handling), and integration evaluations (the wider backend still satisfies OWASP ASVS).

C13: Resilience and safe failure

Verify safe degradation when the model is unavailable or producing unsafe or biased outputs, documented and exercised fallback path, safety-filter bypass prevention, safe-failure posture tested across normal, abusive, and degraded conditions.

C14: Human oversight and governance

Verify human-oversight model proportionate to decision impact, named human reviewers for high-impact decisions, documented override and feedback channel, AI governance committee review cadence. Ties AISVS verification to ISO/IEC 42001 and the EU AI Act.

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Find vulnerabilities before they ship

Test web apps behind the login

Bulk finding import bring your scanner data with you

AI-powered reports in seconds, not days

Compliance tracking without a full GRC platform

Verify fixes and track reopens on the same finding record

Every action recorded across the workspace

Document management for every security engagement

Collaborate across your entire team

Multi-factor authentication on every workspace

Finding overrides that survive every scan cycle

Run an AISVS verification engagement on one workspace

Pick the level, test the named controls across training data, model lineage, input handling, output handling, RAG, agent boundaries, memory, monitoring, privacy, supply chain, safety evaluation, resilience, and governance, and ship a verification report mapped to AISVS rather than a generic LLM risk list. Start free.

Get Started Free

No credit card required. Free plan available forever.