LLMs are embedded in production apps everywhere. According to Aikido's State of AI in Security and Development 2026 report, 24% of production code is now AI-generated. However, 69% of organizations have discovered vulnerabilities in AI-generated code and 20% reported a serious incident as a result.
A lot of the security conversation around LLMs focuses on putting guardrails on the models. But far less attention goes to the application layer, even though that's where many of the real incidents originate, and where guardrails can't help. In September 2025, a malicious npm package postmark-mcp
impersonated a legitimate MCP server and BCC'ed every email sent through it to an attacker-controlled address. The vulnerability lived in a package installed on developer machines, and no guardrail sitting in front of an LLM would have caught it.
This post walks through what LLM application security actually covers, how to choose a tool that addresses it, and which platforms handle the parts that matter.
{{cta}}
TL;DR
Aikido Security is the strongest option for teams that want enterprise-grade LLM application security across the whole AI development lifecycle. It scans AI-generated code in the IDE, blocks malicious and hallucinated packages at install time, protects the developer environment against threats like malicious MCP servers, and tracks which AI models your application is calling in production.
What is LLM application security?
In this piece, we will focus on LLM security from the application side, which means securing the code, dependencies, and infrastructure around an LLM. It's distinct from model security, which covers the LLM's own behavior and is handled by guardrails and red-teaming tools like Lakera Guard, Prisma AIRS, NeMo Guardrails, and Garak. Neither is sufficient alone.
Aikido's PromptPwnd research showed how this plays out. Untrusted input got injected into prompts for Gemini CLI and other agents running inside GitHub Actions workflows, and those agents used their privileged tokens to leak secrets. At least five Fortune 500 companies were affected. The exploitable surface wasn't the model. It was the CI workflow wrapped around it.
LLM application security protects your application against these core threat categories from the OWASP Top 10 for LLM Applications 2025:
- Sensitive information disclosure (LLM02)
- Supply Chain (LLM03)
- Improper output handling (LLM05)
- Excessive agency (LLM06)
- System Prompt Leakage (LLM07) new in 2025
These categories map to real incidents. Under LLM02, a critical misconfiguration in AI generated code discovered in January 2025 affected 170+ Lovable built apps, exposing emails, API keys, payment details and personal data. Under LLM03, Researchers at USENIX 2025 tested 16 models across 2.23 million code samples and found that 19.7% contained at least one hallucinated package name. When identical prompts were re-run, 43% of hallucinated packages reappeared in every one of 10 queries. Attackers now register fake names in advance, turning model quirks into supply chain attacks.
Covering these categories takes several distinct capabilities. SAST and secret scanning on application code catch hardcoded credentials and unsanitized inputs flowing into prompts. SCA flags known-vulnerable AI framework versions, while supply chain malware detection catches malicious and hallucinated packages. Developer environment protection catches malicious MCP servers distributed as packages (postmark-mcp) and compromised extensions before they're installed. And LLM usage tracking watches which models your application is actually calling, surfacing unauthorized AI integrations.
Why you need LLM security tools
AI development has introduced new vulnerabilities that security teams need to address.
- AI-generated code ships unreviewed: With a quarter of production code now AI-generated, review hasn't kept pace with output.
- Slopsquatted packages: Attackers register the package names AI assistants hallucinate, turning a model quirk into a supply chain attack.
- Shadow AI: Teams are calling models nobody inventoried, sending data to providers nobody approved.
- Compliance pressure is starting to ask for LLM security: The EU AI Act is the clearest example, and the OWASP LLM Top 10 is becoming the de facto reference framework in security reviews.
How to choose an LLM security tool
Coverage of the whole AI SDLC
A platform that covers AI-generated code, the supply chain feeding it, and the developer environment producing it. Point tools cover a slice, and stitching vendors together means multiple dashboards and duplicate findings.
Does it check AI generated code in the IDE?
Code written by an assistant should be scanned at the point of creation, not discovered in CI after it's already in a pull request.
Signal-to-noise ratio
AI has inflated the volume of code and findings alike. A tool that can't triage its own output turns into another backlog.
LLM usage tracking
Visibility into which models the application calls, so shadow AI surfaces before an auditor or an attacker finds it first.
Top LLM security tools for AI applications
Aikido Security
Aikido Security covers the AI application lifecycle end to end. That starts in the IDE, where AI-generated code originates, and runs through to the production environment where it executes. RBAC, SSO, and audit trails sit behind every layer, so enterprise governance requirements are met.
At the code layer, Aikido's MCP plugin connects Aikido's security engine directly to AI coding tools, automatically running SAST and secrets detection on generated code inside the IDE. Vulnerabilities get caught at the point of creation instead of surfacing in a pull request or, worse, in production. Safe Chain sits alongside it, blocking malicious and hallucinated npm packages at install time and cutting off the slopsquatting attack path before a package ever lands in your dependency tree (a direct match for OWASP LLM03).
At the environment layer, Device Protection watches for malicious MCP servers and unsafe AI tool integrations, which is the layer built to catch threats like postmark-mcp
before they reach the codebase. DSPM flags sensitive customer data sitting unredacted in the stores AI applications write to, including vector databases and prompt logs. And in production, Zen provides in-app LLM usage tracking that shows exactly which AI models your application is calling in real time, tracks where data is going down to the region level, and enforces AI usage compliance so unauthorized integrations surface immediately.
Behind all of this, AutoTriage does the deduplication, reachability filtering, and cross-scanner correlation that keeps AI-inflated finding volumes manageable at enterprise scale.
{{walkthrough}}
Snyk
Snyk is the broadest enterprise platform on this list, spanning SAST, SCA, container, and IaC scanning, with its DeepCode AI engine powering detection and AI-generated code analysis in the IDE. It has the deepest enterprise adoption of any developer security tool.
The tradeoffs are noise and cost. Snyk's finding volume is a common complaint, and its pricing model works better for large organizations than for small teams.
Best for: teams that want an established platform with broad language coverage, but teams should budget for tuning time to keep the finding volume manageable, and expect enterprise pricing that won't fit smaller organizations.
Semgrep
Semgrep's strength is customizable rules. Teams can write their own detection logic for LLM-specific code patterns, and Semgrep has shipped rules covering unsafe AI agent configurations. It's the natural pick for security teams that want fine-grained control over what gets flagged.
The tradeoff is assembly. Semgrep is CI-first, coverage depends on the rules you invest in, and it's a code scanning tool rather than a platform. Supply chain, developer environment, and AI usage visibility all need to come from somewhere else.
Best for: security engineering teams that want to write and tune their own detection rules, but coverage lives and dies by the rules you invest in, and there's nothing here for supply chain, developer environment, or production LLM usage visibility.
Endor Labs
Endor Labs is the supply chain specialist. Its reachability analysis cuts dependency noise by identifying which vulnerable functions are actually called, and it has built out AI-specific coverage including risk scoring for models pulled from public repositories and AI-BOM generation.
The tradeoff is scope. Endor is a point solution for dependencies and doesn't cover code scanning, the developer environment, or runtime.
Best for: teams whose primary AI risk is the open source supply chain, but if your risks include AI-generated code in the IDE, malicious MCP servers on developer machines, or unauthorized model calls in production, you'll need something else alongside it.
Wiz
Wiz approaches AI security from the cloud rather than the developer workflow. Its AI-SPM discovers AI services, models, and training infrastructure across cloud environments and flags misconfigurations and exposure. Since the Google acquisition closed in March 2026, Wiz continues to operate under its own brand within Google Cloud.
Wiz answers a different question than the other tools here. It tells a security team what AI exists across the organization's cloud footprint. It doesn't scan code in the IDE, block packages at install, or watch the developer environment.
Best for: security teams whose AI security question is cloud-wide visibility, but if your goal is stopping AI-related vulnerabilities before they reach production, Wiz sits too far downstream and doesn't touch the IDE, the supply chain, or the developer environment.