Versatile AI Risk Assessment

AI threat catalogue Application and Integration Security Production

Application Vulnerabilities

The software around the AI model, meaning its web interface, APIs and databases, has the same weaknesses as any other application. Attackers do not need to outwit the model if a classic security flaw opens the way into the system.

As of: October 2026 · Catalogue version 2026.10.24.2 · 5 mitigations · 7 verified sources

Description

An AI system is far more than the model: login, user management, programming interfaces (APIs), databases and server infrastructure form the application layer. This is where the long-known weaknesses of web security arise: injected scripts (XSS), manipulated database queries (SQL injection), actions forged in the name of logged-in users (CSRF) or bypassed authentication. Attackers often find such flaws from the outside with automated scans. AI projects are particularly exposed when attention is focused on the model and quickly built prototypes or newer AI frameworks go into production without hardening.

Possible impact

Through a flaw in the application layer, attackers gain access to the system and all data it processes, including user inputs, knowledge bases and credentials. The consequences range from manipulation or outage of the service to GDPR notification duties after data leaks, and for high-risk systems questions of cybersecurity conformity under the EU AI Act.

Example

A company runs its AI framework with an administration interface that is reachable from the internet without login. Attackers find the open interface, execute their own code on the servers and siphon off computing power, models and data.

Recommended mitigations (5)

Compare effects and implementation levels. Expand each entry for the additional classification and rationale.

  • Secure coding practices (OWASP Top 10)

    Organizational & process-based
    Effect
    Preventive
    Implementation level
    Application, API & agents, Organization
    Classification and rationale

    Complementary control typeTechnical

    Primarily organizational and process-based: Defined selection, operating, or lifecycle procedures make the control binding and repeatable; complemented by technical implementation.

  • Regular vulnerability scanning

    Technical
    Effect
    Detective
    Implementation level
    Application, API & agents, Infrastructure, Use & operations
    Classification and rationale

    Primarily technical: Software or analytical tools systematically produce and evaluate measurements, deviations, or attack indicators.

  • Penetration testing

    Organizational & process-based
    Effect
    Detective
    Implementation level
    Application, API & agents, Infrastructure, Use & operations
    Classification and rationale

    Complementary control typeTechnical

    Primarily organizational and process-based: A planned, repeatable assessment with ownership and documented follow-up creates the protective effect; complemented by technical implementation.

  • Dependency management and patching

    Technical
    Effect
    Preventive
    Implementation level
    Application, API & agents, Infrastructure, Supply chain, Use & operations
    Classification and rationale

    Complementary control typeOrganizational & process-based

    Primarily technical: Safe formats, restrictive defaults, or protective layers reduce unsafe execution paths and exploitable attack surface; complemented by binding workflows.

  • WAF and runtime protection

    Technical
    Effect
    Preventive, Impact-limiting
    Implementation level
    Application, API & agents, Infrastructure
    Classification and rationale

    Primarily technical: Safe formats, restrictive defaults, or protective layers reduce unsafe execution paths and exploitable attack surface.

Framework mappings

Verified locations in OWASP, NIST AI RMF, MITRE ATLAS, the EU AI Act and further frameworks. The mappings are taxonomic, not evidence of compliance.

NIST AI RMF Section 2.9MITRE ATLAS AML.T0049EU AI Act Article 55(1)(d) · Article 9(1), 9(2)(a), 9(2)(d)BIML BIML-LLM inference:10 · BIML-LLM inference:9 · BIML78 system:9

Verified references (7)

Every reference states the framework, the exact location and the publishing organisation.

EU AI Act obligations related to this threat

The obligations from the obligations compass whose articles the catalogue maps to this threat. Each leads to its entry with core, action step and evidence; whether it applies to you depends on role and risk class.

  • Establish and operate a risk management system Art. 9 · applies from Annex III: 2 December 2027 · Annex I: 2 August 2028

    Statutory roles: Provider, Product manufacturer. Classes: High-risk under Annex III, High-risk as a product or safety component.

    This reference is a review prompt. A threat match alone does not establish applicability.

  • Evaluate and mitigate systemic risks Art. 55 · applies from 2 August 2025

    Statutory roles: Provider of a general-purpose AI model. Classes: Model with systemic risk.

    This reference is a review prompt. A threat match alone does not establish applicability.

All 62 obligations by role, risk class and deadline in the obligations compass

More entries from the topic group Application and Integration Security.

Insecure Output Handling The application passes an AI model's answers to downstream systems without checks, for example to databases, web pages or command lines. Insecure Tool Design Many AI applications act on their own through connected tools, for example sending emails or querying databases. RAG-Specific Attacks (Document Poisoning) Attackers plant prepared documents in the knowledge base an AI system draws on via RAG (retrieval-augmented generation, looking up …

Matching use cases

This list shows where to review this threat, rather than how high the risk is.

Belongs on the checklist for every AI system. What to review for every AI system

Frequently asked questions

What is Application Vulnerabilities?
The software around the AI model, meaning its web interface, APIs and databases, has the same weaknesses as any other application. Attackers do not need to outwit the model if a classic security flaw opens the way into the system.
Which mitigations help against Application Vulnerabilities?
The catalogue lists 5 mitigations, each with control type, effect and implementation level. First among them are Secure coding practices (OWASP Top 10), Regular vulnerability scanning and Penetration testing.
Which EU AI Act obligations does Application Vulnerabilities touch?
The catalogue maps this threat to Art. 9 and Art. 55 of the EU AI Act. In the obligations compass this leads to: Establish and operate a risk management system and Evaluate and mitigate systemic risks. Whether an obligation applies depends on role, risk class and deadline.

Assess this threat in your own system

The live demo contains all 52 threats of this catalogue, including the EU AI Act and GDPR assessment. The free single modules cover AI risk, the EU AI Act and GDPR. No sign-up; the assessment runs locally in your browser.

Start the live demo See the free modules

Cite this entry

For reports, policies or internal documents; the link leads directly to this entry.

“Application Vulnerabilities”. Versatile AI Risk Assessment, AI threat catalogue, as of October 2026.
https://www.versatile-ai-risk-assessment.com/en/wissensbasis/threats/application-vulnerabilities/

← Back to the full catalogue