AI Application Security: Securing the AI Stack at Runtime

What is AI application security?

AI application security is application security for systems built on large language models and machine learning. It covers the same concerns as traditional AppSec, vulnerable dependencies, insecure code, exposed secrets, and exploitable runtime behavior, plus a set of risks specific to AI: prompt injection, agent and tool abuse, model and data-pipeline manipulation, and an expanding AI supply chain.

The key shift is to stop treating AI as special. An AI application is application code. The model is one untrusted component inside a larger system of orchestration, tools, retrieval, and execution. Securing it means securing that system, and prioritizing by what actually runs rather than by the volume of theoretical findings a scanner can produce.

Why traditional scanning misses AI risk

Traditional scanning flags issues by presence in code or dependencies, without proving whether they are exploitable in production. In an AI stack that gap is wider than usual, because the stack is new, moves fast, and chains risk across layers. A scanner can report a long list of CVEs in AI libraries while saying nothing about which of them load, execute, or can be reached by an attacker.

What matters is runtime exploitability: whether a vulnerable path is reachable, whether it executes, and whether it can be chained with others. Reachability analysis and runtime intelligence are what turn a noisy inventory of AI-stack CVEs into the short list that genuinely puts the application at risk.

The AI application stack, layer by layer

The AI application stack breaks into five layers, each with distinct security considerations.

1. Agent frameworks

LangChain, LangGraph, and CrewAI connect models to tools, APIs, and workflows. They introduce prompt injection, tool exploitation, and API overreach.

2. Full-stack frameworks

Next.js, React, Vue, and Angular power most AI applications and inherit familiar issues like cross-site scripting and dependency compromise.

3. Data pipelines

TensorFlow.js, Transformers.js, and Hugging Face datasets and tokenizers handle preprocessing and inference, introducing poisoned models, dataset manipulation, and runtime vulnerabilities.

4. Vector databases

Pinecone, Weaviate, and Milvus store embeddings and power retrieval. Risks include data exfiltration through query abuse, metadata injection, and poisoning.

5. Runtimes and deployment

Node.js, Deno, and Bun, plus serverless and edge runtimes like AWS Lambda, Vercel Edge, and Cloudflare Workers, add metadata credential theft, prototype pollution, and build pipeline compromise.

Security issues here are rarely isolated. They chain across layers: a poisoned dataset ingested through Hugging Face can be embedded into a vector database, retrieved by an agent framework, and exfiltrated through an API endpoint on an edge runtime. Each layer amplifies the next, which is why a stack-wide, runtime-aware view matters more than any single scanner.

The main AI threat categories

• Prompt injection. Crafted input makes a model follow an attacker's instructions instead of the developer's. It is OWASP LLM01 and is best understood as initial access, not the damage itself. See what prompt injection is and how to defend against it.
• Agentic and tool abuse. Most high-impact agent failures are authorization and orchestration failures, not model failures, when tools are over-privileged and actions execute without oversight. See agentic AI security, plus multi-agent architectures and agent-framework security.
• AI supply chain. AI applications pull in models, datasets, and packages whose provenance and runtime behavior are often unverified. An AI bill of materials extends the SBOM to these components.
• LLM inference attacks. Exposed inference servers and leaked keys let attackers steal or abuse model inference. See how attackers are gaining access to LLM inference.
• OWASP Top 10 for LLM. The OWASP Top 10 for LLM Applications is the reference taxonomy for these risks, from prompt injection to insecure output handling and excessive agency.

How to secure AI applications

Securing an AI application means treating the model as untrusted and defending the system around it, with prioritization driven by what actually runs. In practice that combines least-privilege tool access, validated tool arguments, sandboxed execution, gating of irreversible actions, and runtime monitoring of the behavior the system actually performs.

Kodem approaches this through securing the AI application stack: runtime intelligence identifies which AI-stack vulnerabilities are reachable and exploitable, and Kai, Kodem's runtime-aware AI, helps teams prioritize and remediate the findings that genuinely matter instead of triaging every advisory. The goal is not more findings. It is an accurate, runtime-validated view of the AI risk that actually puts the application in danger.

What this research series covers

This series dissects the AI application stack layer by layer, documenting real-world security issues with MITRE ATT&CK mappings and references:

• Agent Frameworks: LangChain, LangGraph, CrewAI
• Model / LLM Integration SDKs: Vercel AI SDK, OpenAI SDK, Anthropic SDK
• Full-Stack Frameworks: Next.js, React, Vue, Angular
• Data Pipelines: TensorFlow.js, Transformers.js, Hugging Face
• Vector Databases: Pinecone, Weaviate, Milvus
• Runtimes: Node.js, Deno, Bun
• Serverless/Edge: AWS Lambda, Vercel Edge, Cloudflare Workers

Frequently Asked Questions