GenAI Is Accelerating Software Development — But Is Security Keeping Up? - Part 2

Generative AI is changing how software is designed, written, tested, and deployed. It can dramatically improve developer productivity, but the same acceleration can also multiply security weaknesses at a scale traditional review processes were never designed to handle.

OWASP GenAI/LLM Top 10 2026

This changing threat landscape is reflected strongly in the OWASP Top 10 for LLM Applications 2026, published by the OWASP GenAI Security Project.

The 2026 guide was developed with contributions from hundreds of AI-security experts and incorporates analysis of thousands of real-world AI-security incidents.

The 2026 Top 10 is:

Rank	OWASP GenAI/LLM Risk
LLM01	Prompt Injection
LLM02	Sensitive Information Disclosure
LLM03	Excessive Agency
LLM04	Supply Chain
LLM05	Data and Model Poisoning
LLM06	Unbounded Consumption
LLM07	Misinformation
LLM08	Hidden Context Exposure
LLM09	Vector and Embedding Weaknesses
LLM10	Improper Output Handling

Reference:
https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/

LLM01 — Prompt Injection

Prompt injection remains the most recognizable GenAI application risk.

But its modern form is significantly broader than:

Ignore all previous instructions...

The architectural problem is fundamental.

An LLM processes:

System Instructions
+
User Input
+
Retrieved Data
+
Conversation History
+
Tool Output
+
Memory

inside a shared context.

The model does not enforce the same hard distinction between instructions and data that traditional software architectures can establish.

The question is no longer solely:

“How do we prevent prompt injection?”

It becomes:

“What happens when prompt injection works?”

Indirect Prompt Injection Changes the Attack Surface

One of the most important risks for modern organizations is indirect prompt injection.

Imagine an enterprise assistant that can:

Read email
Read documents
Search SharePoint
Access Git repositories
Query databases
Interact with MCP servers
Call internal APIs

An attacker may not have to attack the AI interface directly.

They could place malicious instructions inside something the AI later reads:

External Website
        ↓
PDF / Document
        ↓
Support Ticket
        ↓
Email
        ↓
GitHub Issue
        ↓
RAG Data
        ↓
Enterprise AI Agent

The AI becomes the attack intermediary.

LLM03 — Excessive Agency

The risk becomes dramatically more serious when an LLM can perform actions.

Consider:

LLM
 ↓
MCP
 ↓
Shell
 ↓
Cloud API
 ↓
Database
 ↓
Email
 ↓
File System

The model is no longer only generating text.

It has agency.

A compromised model with only conversational capability might generate an incorrect response.

A compromised model with access to:

AWS
GitHub
Jira
Slack
Database
Shell

may create operational consequences.

This dramatically changes threat modeling.

AI Supply Chains Are Becoming Software Supply Chains

Modern applications already depend heavily on third-party packages.

GenAI introduces additional dependencies:

Foundation Model
Model Provider
Fine-Tuned Model
Embedding Model
Vector Database
Dataset
RAG Documents
MCP Server
Prompt Library
AI Plugin
Agent Framework
Third-Party API

Each component becomes part of the trust chain.

This is effectively an emerging AI Bill of Materials problem.

Data and Model Poisoning

AI applications are unusually dependent on data.

RAG systems, vector databases and fine-tuning pipelines intentionally allow information to influence future model responses.

That also creates an opportunity for attackers.

If an attacker can introduce malicious information into:

RAG corpus
Vector store
Training data
Fine-tuning dataset
Long-term agent memory

the attack may persist beyond the original interaction.

Image Placeholder – RAG Poisoning Attack

Attacker
    ↓
Poisoned Document
    ↓
RAG Ingestion
    ↓
Vector Database
    ↓
AI Assistant
    ↓
Multiple Future Users

Improper Output Handling Meets AI-Generated Code

One OWASP 2026 observation is particularly relevant to AI-assisted development.

The revised LLM10: Improper Output Handling explicitly includes insecure code generated by assistants at scale.

This connects the two sides of the problem:

AI inside software

        +

AI creating software

A human developer might recognize a dangerous pattern.

But when hundreds or thousands of AI-generated changes enter repositories continuously, the question becomes:

Who is reviewing the reviewer?

The Rise of Vibe-Coded Applications

Another important change is the growth of what is often described as vibe coding.

The developer—or sometimes non-developer—describes what they want:

“Create a customer portal with authentication,
file upload, payment processing and an admin dashboard.”

The AI generates most of the implementation.

The application works.

It gets deployed.

But the person deploying it may have limited understanding of:

Session management
Authorization
Input validation
Cryptography
API security
Dependency risk
Cloud permissions
Secure file handling
SSRF
Race conditions
Business-logic vulnerabilities

The danger appears when:

Software-development democratization is not accompanied by security democratization.

Traditional SAST Alone Will Not Solve This

Static-analysis tools remain extremely useful.

But GenAI applications introduce security conditions that do not necessarily appear as a vulnerable line of code.

The security stack therefore needs to evolve from:

Scan the source code

toward:

Understand the system
        ↓
Threat-model AI interactions
        ↓
Review source code
        ↓
Review architecture
        ↓
Test prompts
        ↓
Attack RAG
        ↓
Attack agent permissions
        ↓
Test MCP integrations
        ↓
Evaluate output handling
        ↓
Attempt real attack chains

The New GenAI Application Attack Surface

A useful way to think about modern AI security is:

                USER
                  ↓
             APPLICATION
                  ↓
        ┌─────────┴─────────┐
        ↓                   ↓
     Traditional           LLM
     Application            ↓
     Security             Prompt
        ↓                   ↓
    API / Database       Context
                            ↓
                      RAG / Vector DB
                            ↓
                          Tools
                            ↓
                           MCP
                            ↓
                         Agents
                            ↓
                     External Systems

Each arrow represents a trust relationship.

And every trust relationship should be tested.

Security Needs a Human Back in the Loop

Ironically, the answer to increasingly automated development may be stronger human-led security validation.

AI can help security engineers.

It can:

Analyze code
Identify patterns
Explain vulnerabilities
Generate test cases
Correlate findings
Assist threat modeling
Prioritize alerts

But high-impact application-security testing still requires understanding context, trust boundaries, attack chains, and business logic.

A Better Model: AI + Automation + Human Offensive Security

The answer is not:

AI vs Humans

It is:

                 AI
                  ↓
        Large-Scale Analysis
                  ↓
              Automation
                  ↓
        Continuous Detection
                  ↓
        Human Security Review
                  ↓
       Adversarial Validation
                  ↓
        Business-Risk Context

AI handles scale.

Humans handle context.

Automation handles repetition.

Offensive testing validates reality.

Together, they create a much stronger security model.

What Organizations Should Do Now

Organizations developing GenAI-enabled applications should consider security throughout the entire development lifecycle.

1. Inventory AI Components

Identify models, APIs, RAG systems, vector databases, MCP servers, agents, datasets, plugins, and external AI providers.

2. Threat Model AI Architecture

Map inputs, models, data, tools, and actions. Identify every trust boundary.

3. Review AI-Generated Code

Treat AI-generated code exactly like third-party code.

Never assume:

AI-generated = security-reviewed

4. Test Against OWASP GenAI/LLM Top 10

Security assessments should explicitly evaluate the current OWASP GenAI/LLM risks.

5. Test Agent Permissions

Ask:

What can the agent read?
What can the agent modify?
What can the agent execute?
Where can it send information?

6. Assume Prompt Injection Will Eventually Work

Defensive design should focus not only on blocking malicious instructions but also on constraining the blast radius if the instruction boundary is bypassed.

7. Perform Manual Adversarial Testing

Attempt realistic attack chains across application, LLM, RAG, identity, MCP, cloud, and business logic.

How LeetProtect Can Help

GenAI security cannot be solved simply by purchasing another scanner.

Organizations need to understand how their AI-enabled applications behave when exposed to realistic adversarial conditions.

LeetProtect can support organizations across several layers of this problem.

GenAI Application Security Assessment

Evaluate applications against risks including:

OWASP GenAI/LLM Top 10
Prompt injection
Indirect prompt injection
Sensitive-information disclosure
Excessive agency
RAG security
Vector-store weaknesses
AI supply-chain risk
Model and data poisoning
Improper output handling

AI-Assisted Secure Code Review

LeetProtect’s approach combines automated code analysis with security expertise to identify:

Insecure coding patterns
Authentication weaknesses
Authorization flaws
Injection vulnerabilities
Data-flow problems
Dangerous AI integrations
Misconfigurations
Business-logic weaknesses

Agentic and MCP Security Assessment

For applications using autonomous agents or MCP integrations, review:

Agent permissions
Tool exposure
Authentication
Authorization
Trust relationships
Data access
Command execution
External communication
Cross-agent interactions

RAG Security Testing

Evaluate whether retrieval systems can be abused through:

Poisoned documents
Cross-user retrieval
Unauthorized knowledge access
Vector manipulation
Indirect prompt injection
Sensitive-data exposure

Human-Led Red Teaming

Finally, evaluate the complete system as an attacker would.

Not:

Is vulnerability X present?

but:

What can an attacker actually achieve?

From Secure Code to Secure AI Systems

The GenAI revolution will not slow down.

Nor should it.

AI is enabling developers and businesses to create software faster than at any point in the history of computing.

The challenge for security teams is ensuring that security capability scales with development capability.

The organizations that succeed will not be those that avoid AI.

They will be those that recognize a simple principle:

Every capability AI gives your developers may eventually become a capability available to an attacker.

The objective therefore should not be to make an AI system that can never be manipulated.

It should be to build an architecture where manipulation does not automatically become compromise.

Take Action

If your organization is:

Developing applications using AI coding assistants
Building GenAI-enabled products
Implementing RAG
Deploying AI agents
Integrating MCP
Allowing AI access to internal systems
Using AI to generate significant amounts of production code

then traditional application-security testing alone may no longer represent your complete attack surface.

LeetProtect can help assess the application, the AI layer, the code, the architecture, and the attack paths connecting them.

The objective is simple:

Build with AI at speed. Test it with the mindset of an attacker before someone else does.

References

OWASP GenAI Security Project, OWASP Top 10 for LLM Applications 2026
https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/

Author: Moe Khalilov
LeetProtect

Gen AI Application Security — Part 2