This is part 1 of a multi-part series exploring the intersection of artificial intelligence and cybersecurity. As AI systems become increasingly powerful and deeply integrated into our digital infrastructure. We’ll examine the techniques, exploits, and defensive strategies.

Before we dive into the technical details in upcoming posts, we need to establish the foundation. This article sets the stage by exploring how AI, specifically Large Language Models, has become critical infrastructure in software development and security tools.

Large Language Models (LLMs) have become infrastructure; nowadays, they are embedded in IDEs (e.g. VSCode, PyCharm, etc.) , reviewing pull requests and scanning for vulnerabilities.

The core risk is straightforward: models that understand code can be manipulated into influencing or executing it.

This article examines how LLM code reasoning works, why prompt injection represents a natural evolution of classic injection attacks, and how these vulnerabilities escalate to Remote Code Execution in production systems.

Table of contents

1. How LLMs Process Code

LLMs do not parse code like compilers. There is no AST (Abstract Syntax Tree) construction, no type checking, no formal semantic analysis.

Instead, they process code as token sequences, statistical patterns learned from billions of lines of training data.

2. The Underlying Mechanics

Tokenization segments code into subword units. A function name like getUserById becomes ["get", "User", "By", "Id"]. The model does not inherently understand what a function does, it predicts based on learned patterns.

Pattern recognition enables the model to learn idiomatic structures. After processing millions of SQL queries, an LLM learns that SELECT * FROM users WHERE id = ? is a common pattern. It can generate syntactically valid queries or identify injection vulnerabilities.

Semantic reasoning is where capabilities become significant. Given sufficient context, LLMs can:

• Infer variable purposes from naming conventions
• Trace control flow through conditional logic
• Predict operation outputs without execution

Consider this example:

An LLM correctly predicts that get_role(1) returns "admin" without running the code. It reasons through the dictionary structure, the lookup operation, and the default value.

The critical distinction: LLMs do not execute code, they predict behavior probabilistically. This means they can generate syntactically valid and semantically dangerous code without any runtime validation.

3. Prompt Injection Fundamentals

For security practitioners familiar with SQLi, command injection, or SSTI, prompt injection follows the same fundamental pattern.

The root cause is the same: mixing data with instructions.

3.1 Definition

Prompt injection occurs when attacker-controlled input manipulates an LLMs behavior by overriding or corrupting its instructions. The model cannot distinguish between:

• System prompts defined by developers
• Malicious content embedded in user input

3.2 Types of Injections

Vulnerability	Injection Point	Boundary Violated
SQL Injection	Query string	Data to SQL engine
Command Injection	Shell arguments	Data to Shell
SSTI	Template variables	Data to Template engine
Prompt Injection	User input / context	Data to LLM reasoning

The key difference: LLMs have no formal grammar. There is no mechanism for escaping special characters because there are no special characters. The entire input stream constitutes instructions.

3.3 Why LLMs Are Vulnerable

No instruction boundary. System prompts and user content exist within the same context window. The model processes everything as natural language without structural separation.

Hidden prompts provide no security. Many applications rely on obscuring the system prompt from users. Models routinely leak context when prompted correctly. Security through obscurity remains ineffective.

Implicit trust creates risk. When downstream systems execute model output without validation, injection becomes a gateway to system compromise.

4. From Injection to Remote Code Execution

This is where theoretical concerns become concrete security incidents.

Prompt injection alone is concerning. Combined with execution privileges, it becomes an RCE vector.

4.1 The Attack Chain

Each component operates correctly in isolation. The vulnerability resides in the architecture connecting them.

4.2 Realistic Attack Scenarios

4.2.1 Scenario 1: CI/CD Code Review Bot

An automated bot reviews pull requests for security issues, ingesting the entire diff including comments.

An attacker submits a PR containing:

The LLM, optimized for helpfulness, may incorporate the suggested fix into its review. If the CI system auto-applies security recommendations, the attacker achieves code execution.

4.2.2 Scenario 2: AI-Assisted Refactoring Tool

Development teams use LLMs to modernize legacy codebases. The tool ingests source files, dependency manifests, and documentation.

An attacker publishes a malicious npm package with a compromised README:

When the refactoring tool processes the codebase, it ingests this README and may incorporate the malicious instruction into its output.

4.2.3 Scenario 3: Real-World Examples with Code

Moltbook is a viral 2026 social network designed exclusively for AI agents. While humans could watch, only autonomous agents (mostly powered by the Moltbot/OpenClaw framework) could post, comment, and upvote.

An attacker makes a “Malicious Agent” persona on MoltBook. Instead of hitting the server, it targets the logic of other agents. As these agents read and share this harmful content, the attack spreads quickly.

We will dive deeper into this subject in an upcoming part of the series.

4.3 Why This Represents a New Vulnerability Class

This is not simply injection with additional steps. LLMs fundamentally break traditional security assumptions.

Data becomes instructions. Classical security architectures maintain strict separation between code and data. LLMs process all input as natural language without syntactic boundaries between trusted and untrusted content.

Non-deterministic behavior. Identical inputs may produce different outputs across requests. This significantly complicates testing, auditing, and building reliable guardrails.

Implicit authority elevation. When a security bot recommends a fix, engineers trust that recommendation more than arbitrary user input, even when both originate from untrusted sources.

4.4 Defense Strategies

No single solution exists. However, practical defenses can significantly reduce risk.

The fundamental principle: treat all LLM output as untrusted input.

The Defense Architecture

Isolate Input and Output

Treat generated code like user input, validate everything equally. Escape all output before displaying or processing it.

Sandbox Code Execution

Run generated code in containers, VMs, or WebAssembly. Use seccomp or AppArmor for shell access. Block network connections from execution contexts.

Require Human Approval

Get explicit sign-off before destructive operations (deletes, permissions changes, sensitive data access). Show your reasoning for audit trails.

Minimize Permissions

Grant only what’s needed. Default to read-only. Avoid shell access unless absolutely necessary.

Enforce Structured Output

Require JSON or strict schema formats. Validate responses against your expected structure. Reject anything that doesn’t match.

4.5 Why Filtering Is Insufficient

Blocklisting harmful prompts seems good but isn’t an effective long-term solution.

• Attackers use base64, Unicode, or typographical tricks to hide payloads.
• Semantic attacks are hard to detect because they don’t have clear patterns.
• Jailbreaks and new injection methods develop quicker than filter updates
• The search space for malicious inputs is effectively infinite

Prompt filtering should be considered a defense-in-depth layer, not a primary control.

---

5. Conclusion

Large Language Models are not inherently insecure. They are powerful tools with significant capabilities.

The vulnerability occurs when systems:

• Trust model output implicitly without validation
• Grant models authority over execution without appropriate boundaries
• Blur the distinction between AI assistance and AI automation

For security practitioners: Treat AI output with the same scrutiny as untrusted user input. This is not optional.

For system architects: Design for LLM compromise. Assume the model will eventually be manipulated. Build architectures where model compromise does not cascade into system compromise.

“The model is not the vulnerability. The architecture surrounding it is.”

In the next parts of this series, we’ll move beyond theory into the practice. We’ll show you the techniques attackers use, and more importantly, the architectural decisions that either enable or prevent them.

Stay tuned. The details matter.