{"site":"Habitwala Technical Blog","url":"https://blog.habitwala.in","description":"Technical insights on securing AI coding agents, Next.js performance, and DevSecOps.","llmsTxt":"https://blog.habitwala.in/llms.txt","llmsFullTxt":"https://blog.habitwala.in/llms-full.txt","rss":"https://blog.habitwala.in/rss.xml","totalArticles":3,"articles":[{"title":"\"Next.js 16 image optimization high CPU usage fix\"","url":"https://blog.habitwala.in/blog/nextjs-16-image-optimization-high-cpu-usage-fix","rawMarkdownUrl":"https://blog.habitwala.in/blog/nextjs-16-image-optimization-high-cpu-usage-fix?format=md","category":"Engineering","publishedAt":"2026-07-31T11:30:00.000Z","updatedAt":"2026-07-27T15:33:31Z","author":"Aman Janwani","excerpt":"Experiencing CPU starvation and server crashes on high-traffic Next.js 16 sites? Learn how to fix the image optimization bottleneck using device constraints and edge CDNs.","content":"Introduction Next.js 16 is a powerhouse of performance, bringing stable React Server Components (RSCs), the automated React Compiler, and incredible streaming capabilities. However, many engineering teams migrating to the App Router encounter a crippling bottleneck the moment their application experiences a high-traffic spike: Massive CPU starvation leading to OOM (Out of Memory) errors and server crashes. In many of these cases, the culprit is not a memory leak in the React code, nor is it a complex database query. The culprit is the built-in Next.js <Image /> component performing on-demand, server-side image processing. Because image processing is intensely CPU-bound, relying on your main Node.js server to generate dozens of image variations on the fly will rapidly exhaust your vCPUs. When the CPU is at 100% processing JPEGs, your server cannot respond to API requests or render Server Components, causing the entire application to hang. In this highly technical guide, we will break down exactly why this bottleneck occurs in Next.js 16, how to identify it using server metrics, and the definitive architectural strategies to fix it permanently. The CPU Starvation Problem: Unconstrained Optimization  When you use the <Image src=\"/hero.jpg\" width={800} height={600} /> component, Next.js intercepts the request. Under the hood, it resizes the image to fit the requested dimensions, converts it to a modern format (like WebP or AVIF), caches it, and serves it. While Next.js 16 correctly uses the high-performance sharp C++ library by default (Squoosh was entirely removed in Next.js 15), the core architectural problem remains: Doing heavy C++ image manipulation on the same event loop responsible for handling API and React Rendering traffic is incredibly dangerous. During a traffic spike, if hundreds of users hit a page with un-cached images, the Node process spins up hundreds of sharp instances. This exhausts the server's CPU credits instantly. How to Identify the Bottleneck Before implementing a fix, you must confirm that image optimization is actually the root cause of your CPU spikes. 1.  Vercel/Cloud Metrics: Look at your server metrics. If your CPU usage is spiking to 100% but your memory usage remains relatively stable (no slow, creeping memory leak), it is highly likely a CPU-bound task like image processing. 2.  PM2 / Docker Top: If you are self-hosting, use htop or docker stats. You will see the Node.js process consuming massive CPU cycles specifically when users navigate to media-heavy routes. 3.  The Cold Start Hang: If your site is lightning fast most of the time, but hangs for 5-10 seconds immediately after a deployment or a cache clear, this is the classic \"image re-optimization\" cold start. Implementation 1: Constraining Next.js Image Generation Generating hundreds of different image sizes on-demand is wildly wasteful. By default, Next.js allows an almost infinite combination of deviceSizes and imageSizes in response to the sizes prop. You can drastically reduce the CPU workload by explicitly restricting the allowed image sizes in your next.config.js.  Fixing Cache Persistence (Crucial for Self-Hosters) If you self-host via Docker and you do not mount a persistent volume for the .next/cache directory, your server will delete all optimized images every time the container restarts. This forces your CPU to re-optimize every single image on the site upon the next visit. Ensure your docker-compose.yml mounts a volume to preserve /app/.next/cache across deployments. Implementation 2: The Custom Loader Strategy (The Enterprise Fix)  If you are operating at enterprise scale with high traffic, having your main application server process images at all is an architectural anti-pattern. Your Next.js server should be rendering HTML and JSON, not running C++ image binaries. The ultimate fix is to completely offload image optimization to a dedicated edge CDN (like Cloudinary, Imgix, or Cloudflare Image Resizing). Step 1: Create a Custom Loader Create a file named imageLoader.js in your utility folder. This function intercepts the Next.js <Image /> request and formats the URL for your external CDN.  Step 2: Configure next.config.js Tell Next.js to stop processing images locally and rely on your custom loader.  With this configuration, your Next.js CPU usage for image processing drops to exactly 0%. The heavy lifting is completely offloaded to distributed edge servers designed specifically for media manipulation. Conclusion Next.js provides an incredibly powerful <Image /> component, but its default configuration is optimized for \"ease of use\" in low-traffic environments, not for enterprise scalability. If you are suffering from high CPU usage and server hangs: 1.  Constrain your formats. Disable AVIF generation if CPU cycles are tight, and severely limit your deviceSizes array in next.config.js. 2.  Persist your cache. Never let a Docker deployment wipe your .next/cache folder. 3.  Offload at Scale. For massive traffic, decouple image processing from your main application server entirely using a custom loader and an Edge CDN. Call to Action: Want more deep-dive architectural fixes for Next.js 16 and modern infrastructure? Subscribe to the Habitwala Engineering Newsletter to get zero-fluff, highly technical engineering research delivered straight to your inbox.","jsonLdSchema":{"@context":"https://schema.org","@graph":[{"@type":"BlogPosting","@id":"https://blog.habitwala.in/blog/nextjs-16-image-optimization-high-cpu-usage-fix#article","isPartOf":{"@type":"WebPage","@id":"https://blog.habitwala.in/blog/nextjs-16-image-optimization-high-cpu-usage-fix","url":"https://blog.habitwala.in/blog/nextjs-16-image-optimization-high-cpu-usage-fix","name":"\"Next.js 16 image optimization high CPU usage fix\"","description":"Experiencing CPU starvation and server crashes on high-traffic Next.js 16 sites? Learn how to fix the image optimization bottleneck using device constraints and edge CDNs."},"headline":"\"Next.js 16 image optimization high CPU usage fix\"","description":"Experiencing CPU starvation and server crashes on high-traffic Next.js 16 sites? Learn how to fix the image optimization bottleneck using device constraints and edge CDNs.","url":"https://blog.habitwala.in/blog/nextjs-16-image-optimization-high-cpu-usage-fix","mainEntityOfPage":"https://blog.habitwala.in/blog/nextjs-16-image-optimization-high-cpu-usage-fix","datePublished":"2026-07-31T11:30:00.000Z","dateModified":"2026-07-31T11:30:00.000Z","inLanguage":"en-US","author":{"@type":"Person","@id":"https://blog.habitwala.in/author/aman-janwani#person","name":"Aman Janwani","jobTitle":"Founder & Lead Security Engineer","url":"https://blog.habitwala.in/author/aman-janwani","sameAs":["https://github.com/amanjanwani","https://x.com/amanjanwani1486","https://www.linkedin.com/in/aman-janwani/"],"knowsAbout":["AI Security","Next.js Performance","DevSecOps","Web Architecture"],"worksFor":{"@id":"https://blog.habitwala.in/#organization"}},"publisher":{"@id":"https://blog.habitwala.in/#organization"}},{"@type":"Organization","@id":"https://blog.habitwala.in/#organization","name":"Habitwala","url":"https://habitwala.in","logo":{"@type":"ImageObject","url":"https://blog.habitwala.in/habitwala-blog-black.png"},"sameAs":["https://github.com/habitwala","https://twitter.com/habitwala"]}]}},{"title":"\"Preventing prompt injection in CLI AI tools using dual-LLM architecture\"","url":"https://blog.habitwala.in/blog/preventing-prompt-injection-cli-ai-tools-dual-llm","rawMarkdownUrl":"https://blog.habitwala.in/blog/preventing-prompt-injection-cli-ai-tools-dual-llm?format=md","category":"Engineering","publishedAt":"2026-07-29T11:30:00.000Z","updatedAt":"2026-07-27T15:33:32Z","author":"Aman Janwani","excerpt":"Learn how to secure your CLI-based AI agents against prompt injection attacks by implementing a Privileged vs Quarantined dual-LLM architectural pattern.","content":"Introduction Command Line Interface (CLI) tools have seen a massive renaissance thanks to the integration of Large Language Models (LLMs). Developers are now using AI-powered CLIs to automate git workflows, refactor massive codebases, and scaffold entire architectures from a single prompt. However, the power of these tools introduces a severe security vulnerability: [Prompt Injection](https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-2023-v1_1.pdf). Unlike a web-based chatbot where a successful prompt injection might simply cause the AI to say something inappropriate, a successful injection in a CLI tool can lead to catastrophic consequences. If your CLI tool has the ability to execute shell commands, read local files, or interact with APIs, a prompt injection is effectively a Remote Code Execution (RCE) vulnerability. Because LLMs inherently cannot distinguish between \"system instructions\" and \"user data,\" simply telling the model \"Do not execute malicious commands\" is practically useless against a determined attacker. In this authoritative engineering guide, we will break down the anatomy of a CLI prompt injection attack, and detail how to protect your tools using a robust, enterprise-grade defense: The Dual-LLM (Privileged vs Quarantined) Architecture. The Anatomy of a CLI Injection Attack To understand the defense, we must visualize the attack. Imagine you have built an AI CLI tool that helps developers summarize the recent git changes in a repository and automatically draft a commit message. The developer runs your tool: ai-commit-drafter Behind the scenes, your tool runs git diff, captures the output, and constructs the following prompt for the LLM:  The Attack Vector Now, suppose the developer recently cloned a repository from an untrusted source, or a malicious actor opened a Pull Request with a hidden payload. The attacker added a seemingly innocuous text file to the repo, but the file contains a prompt injection payload. When your tool runs git diff, it captures the attacker's payload:  Because the LLM parses the entire string as a single context, it reaches the payload and believes it has received new instructions. It outputs the malicious command. If your CLI tool is poorly designed and blindly executes or heavily relies on the LLM's output for secondary automation, the developer's machine is compromised. Architectural Defense: The Security Boundary The fundamental problem is that we are mixing trusted instructions (our system prompt) with untrusted data (the git diff). Security engineering dictates that we must establish a hard boundary between the two. In traditional web development, this is why we use parameterized SQL queries instead of concatenating strings—it separates the SQL command from the user input. Unfortunately, LLMs do not currently have a reliable, mathematically proven equivalent to SQL parameterization. The most effective architectural solution is the Dual-LLM Pattern. The Privileged Orchestrator vs. The Quarantined Parser  Instead of passing everything to one massive LLM, we split the workflow into two distinct agents with entirely different scopes of authority. #### 1. The Quarantined Parser (The Shield) This is a fast, cheaper LLM (like Claude 3.5 Haiku or GPT-4o-mini). Its entire existence is heavily restricted. *   Permissions: Zero. It cannot execute tools, it cannot call APIs, and it cannot trigger local functions. *   Input: It receives the raw, untrusted user data (the git diff, the file contents, the user's terminal input). *   Task: Its only job is to sanitize, summarize, and extract structured data (JSON) from the untrusted input. It operates in a \"quarantine\" where even if it gets successfully injected and hijacked, it has no capabilities to cause harm. #### 2. The Privileged Orchestrator (The Brain) This is your main, highly capable LLM (like Claude 3.5 Sonnet or GPT-4o). *   Permissions: High. It has access to your structured tools (Function Calling, shell execution, file writing). *   Input: It never sees the raw user data. It only receives the sanitized, structured JSON output produced by the Quarantined Parser, alongside strict system instructions. *   Task: It makes decisions and executes tools based on the clean data. Implementation: Building the Dual-LLM Workflow  Let's look at how to implement this architecture using a Node.js CLI tool example. Step 1: The Quarantined Parser Execution We construct a highly specific prompt for our fast Parser LLM. We force it to use JSON mode to ensure the output is programmatic.  Step 2: Evaluating the Parser Output Before we even involve our Privileged Orchestrator, we evaluate the parsed data. If the Parser flagged an anomaly, we halt the CLI tool immediately.  Step 3: The Privileged Orchestrator Execution Now, we pass the *sanitized* cleanData.summaryOfChanges to our powerful Orchestrator LLM. The Orchestrator is safe from injection because the attacker's raw commands (IGNORE ALL PREVIOUS INSTRUCTIONS) were stripped away by the Parser.  Bypassing the Parser: Edge Cases While the Dual-LLM architecture stops 99% of direct injection attacks, advanced attackers will attempt to bypass the parser. Obfuscation and Encoding Attackers may use Base64 encoding, hex strings, or even obscure Unicode formatting to hide their instructions from the Quarantined Parser, hoping the Privileged Orchestrator will decode and execute it later. Defense: Instruct your Quarantined Parser to aggressively flag *any* encoded strings, obfuscated code, or unusual formatting that it cannot natively interpret. If the parser cannot understand it, it should not pass it along to the Orchestrator. The \"Context Window Stuffing\" Attack Attackers may flood the input with massive amounts of garbage data, hoping to push the system instructions out of the LLM's attention mechanism (the \"lost in the middle\" phenomenon), allowing a payload at the very end to take control. Defense: Enforce strict token limits on the input *before* it even hits the Quarantined Parser. If a file is suspiciously large, chunk it, or reject it entirely. Continuous Auditing & Human-in-the-Loop No AI architecture is 100% impenetrable. The final layer of defense for any CLI AI tool must be strict governance over execution. 1.  Human Confirmation: Even with a Dual-LLM setup, if a tool attempts an irreversible action (like rm, drop table, or an outbound curl request), the CLI must pause and require a manual [Y/n] confirmation from the developer. 2.  Audit Logs: Implement tools like Gryph or maintain local timestamped logs of every tool invocation. If an injection does succeed, you must have the forensic capability to see exactly what commands were executed and what data was exfiltrated. Conclusion Building AI CLI tools is incredibly rewarding, but the local terminal is a high-stakes environment. Treating user input (whether from a prompt, a file, or a network request) as benign text is a critical architectural failure. By implementing a Privileged vs. Quarantined Dual-LLM architecture, you effectively create an \"air gap\" between untrusted data and terminal execution capabilities. This drastically reduces your attack surface and protects your users from supply chain prompt injections. Call to Action: Don't leave your local environment exposed to rogue LLM outputs. Audit your CLI workflows with [Agentinel](https://github.com/aman-janwani/agentinel) to implement automated guardrails, monitor permissions, and ensure your autonomous agents never execute malicious commands without your explicit consent.","jsonLdSchema":{"@context":"https://schema.org","@graph":[{"@type":"BlogPosting","@id":"https://blog.habitwala.in/blog/preventing-prompt-injection-cli-ai-tools-dual-llm#article","isPartOf":{"@type":"WebPage","@id":"https://blog.habitwala.in/blog/preventing-prompt-injection-cli-ai-tools-dual-llm","url":"https://blog.habitwala.in/blog/preventing-prompt-injection-cli-ai-tools-dual-llm","name":"\"Preventing prompt injection in CLI AI tools using dual-LLM architecture\"","description":"Learn how to secure your CLI-based AI agents against prompt injection attacks by implementing a Privileged vs Quarantined dual-LLM architectural pattern."},"headline":"\"Preventing prompt injection in CLI AI tools using dual-LLM architecture\"","description":"Learn how to secure your CLI-based AI agents against prompt injection attacks by implementing a Privileged vs Quarantined dual-LLM architectural pattern.","url":"https://blog.habitwala.in/blog/preventing-prompt-injection-cli-ai-tools-dual-llm","mainEntityOfPage":"https://blog.habitwala.in/blog/preventing-prompt-injection-cli-ai-tools-dual-llm","datePublished":"2026-07-29T11:30:00.000Z","dateModified":"2026-07-29T11:30:00.000Z","inLanguage":"en-US","author":{"@type":"Person","@id":"https://blog.habitwala.in/author/aman-janwani#person","name":"Aman Janwani","jobTitle":"Founder & Lead Security Engineer","url":"https://blog.habitwala.in/author/aman-janwani","sameAs":["https://github.com/amanjanwani","https://x.com/amanjanwani1486","https://www.linkedin.com/in/aman-janwani/"],"knowsAbout":["AI Security","Next.js Performance","DevSecOps","Web Architecture"],"worksFor":{"@id":"https://blog.habitwala.in/#organization"}},"publisher":{"@id":"https://blog.habitwala.in/#organization"}},{"@type":"Organization","@id":"https://blog.habitwala.in/#organization","name":"Habitwala","url":"https://habitwala.in","logo":{"@type":"ImageObject","url":"https://blog.habitwala.in/habitwala-blog-black.png"},"sameAs":["https://github.com/habitwala","https://twitter.com/habitwala"]}]}},{"title":"\"Setup Firecracker MicroVM for secure LLM CLI execution\"","url":"https://blog.habitwala.in/blog/setup-firecracker-microvm-llm-execution","rawMarkdownUrl":"https://blog.habitwala.in/blog/setup-firecracker-microvm-llm-execution?format=md","category":"Engineering","publishedAt":"2026-07-27T11:30:00.000Z","updatedAt":"2026-07-27T15:33:33Z","author":"Aman Janwani","excerpt":"Docker isn't enough. Learn how to implement hardware-level isolation using Firecracker MicroVMs to securely execute untrusted LLM-generated code locally.","content":"Introduction As AI coding agents transition from passive chat interfaces to autonomous CLI tools (capable of running terminal commands, installing packages, and reading files), the security landscape has fundamentally shifted. The industry is rapidly learning a hard lesson: you cannot trust LLM-generated code. Whether due to a hallucination (like attempting to install a non-existent npm package that has been \"slopsquatted\" by attackers) or a targeted prompt injection attack, giving an AI agent unrestricted execution rights on your host machine is a recipe for disaster. The immediate reflex for many developers is to wrap the execution in a Docker container. However, container escapes—where malicious code exploits kernel vulnerabilities to break out of the container and access the host—are a well-documented reality. When you are executing completely untrusted, non-deterministic AI outputs, shared-kernel isolation is insufficient. Enter [Firecracker](https://firecracker-microvm.github.io/). Developed by AWS to power AWS Lambda and Fargate, Firecracker is an open-source virtualization technology that creates \"microVMs\". It combines the security and hardware-level isolation of traditional virtual machines with the speed and resource efficiency of containers. In this authoritative guide, we will walk through exactly why Docker fails for AI agent execution, how Firecracker works under the hood, and provide a comprehensive, step-by-step tutorial on setting up a Firecracker microVM to safely sandbox your local AI CLI tools. The Container Escape Threat: Why Docker is Insufficient To understand why Firecracker is necessary, we must first understand the architectural flaw in using Docker for untrusted code execution. Shared Kernels and Syscalls Docker and other container runtimes (like containerd) use Linux namespaces and cgroups to isolate processes. However, all containers on a host share the same underlying OS kernel. When an LLM agent executes a malicious Python script inside a Docker container, that script makes system calls (syscalls) directly to the host's kernel. If there is a vulnerability in how the kernel handles a specific syscall, the malicious code can exploit it to gain root access to the host machine. Furthermore, containers often suffer from misconfigurations (e.g., running as root, mounting sensitive host directories, or overly permissive capabilities) that make escapes trivial for automated exploitation scripts. The Hardware-Level Solution Traditional Virtual Machines (VMs) solve this by using a hypervisor (like KVM on Linux) to virtualize the hardware. The guest OS runs its own kernel. If malicious code compromises the guest kernel, it is still trapped within the VM, unable to reach the host kernel. The downside? Traditional VMs (using QEMU) are slow to boot and consume massive amounts of memory, making them completely unviable for fast, responsive AI agent workflows. Firecracker solves this by being a minimalist Virtual Machine Monitor (VMM). It strips out legacy device support (no USB, no VGA, no PCI) and provides only the bare minimum required to run a modern Linux kernel. The result is a microVM that boots in ~125 milliseconds and consumes less than 5MB of memory overhead. Architecture of a Firecracker MicroVM Before we begin the setup, let's visualize the architecture of a Firecracker-based LLM execution environment.   1.  The Host: Runs the Firecracker VMM binary. It communicates with the KVM (Kernel-based Virtual Machine) module to utilize hardware virtualization. 2.  The API: Firecracker exposes a local Unix domain socket with a RESTful API. You configure and launch the microVM by sending JSON payloads to this socket. 3.  The Guest: The microVM requires an uncompressed Linux kernel binary (vmlinux) and an ext4 root filesystem containing the OS environment (e.g., Ubuntu or Alpine) and the runtimes needed for the agent (e.g., Node.js, Python). 4.  Communication: Instead of traditional networking, the host and guest communicate using VSOCK (Virtual Socket), a fast, low-overhead inter-process communication mechanism designed specifically for hypervisors. Prerequisites & Host Setup To run Firecracker, your host machine must meet strict requirements. Hardware Virtualization You need a Linux host with hardware virtualization enabled (Intel VT-x or AMD-V). If you are testing this on a cloud provider (like AWS, GCP, or Azure), you must use a \"bare-metal\" instance or an instance type that supports nested virtualization. Verify virtualization support:  KVM Permissions Firecracker requires access to the /dev/kvm device. Ensure your user has read and write permissions.  Downloading & Configuring Firecracker Let's pull the latest Firecracker release directly from their official GitHub repository.  Preparing the Guest Assets Firecracker does not boot ISOs or Docker images directly. It requires raw binary files. We need two things: 1.  A Kernel Image: An uncompressed Linux kernel (vmlinux). 2.  A Root Filesystem (rootfs): An ext4 formatted file containing our guest OS. For this tutorial, we will use pre-built assets provided by the Firecracker team for testing. In a production environment, you would build these yourself using tools like debootstrap or Packer, injecting the specific Python/Node runtimes your LLM requires.  Booting the MicroVM via the REST API  Firecracker operates by listening on a Unix domain socket. We will start the Firecracker process and instruct it to listen on /tmp/firecracker.socket. Open Terminal 1:  Firecracker is now running and waiting for API commands. Open Terminal 2. We will use curl to send JSON payloads to configure the VM. Step 1: Set the Boot Source (Kernel) We tell Firecracker where the kernel image is located and provide standard Linux boot arguments. Note that console=ttyS0 routes the output to our terminal, and reboot=k handles kernel panics gracefully.  Step 2: Set the Root Filesystem (Drive) Next, we mount our ext4 image as the root drive. We set is_root_device to true.  Step 3: Configure Machine Resources (CPU & Memory) By default, Firecracker allocates 1 vCPU and 128MB of RAM. Since our LLM agent might need to run npm install or compile small Python scripts, let's increase this to 2 vCPUs and 1024MB of RAM.  Step 4: Start the Instance Finally, we send the InstanceStart command.  If you look at Terminal 1, you will see the Linux kernel boot sequence fly by in milliseconds, dropping you straight into a root shell inside the microVM. You are now in a hardware-isolated environment. If an LLM agent executes rm -rf / or attempts to download a malicious slopsquatted package, it will only destroy this ephemeral microVM. Your host machine remains completely untouched. Integrating LLM Agents via VSOCK In a real-world scenario, you do not manually type commands into the terminal. Your host application (the orchestrator) needs to send the LLM-generated code to the microVM and read the standard output back. Networking via traditional TAP devices introduces complexity (managing IP addresses, iptables, and bridge interfaces). The modern standard for agent execution is VSOCK. VSOCK allows communication between the host and guest without any network stack overhead. It uses a Context ID (CID) and a port number. Configuring VSOCK Before issuing the InstanceStart command, you would add a VSOCK device:  The Host-Guest Workflow 1.  Guest Daemon: Inside the custom rootfs, you run a small background daemon (written in Rust or Go) that listens on VSOCK port 5000. 2.  Host Execution: When the LLM generates a Python script, the host connects to the Unix socket /tmp/v.sock and sends the script payload. 3.  Execution & Return: The guest daemon writes the script to disk, executes it via python3, captures stdout and stderr, and streams it back over the VSOCK connection to the host. 4.  Destruction: Once the task is complete, the host process kills the Firecracker VMM, destroying the environment instantly. Managing VM Lifecycles at Scale Booting a VM in 125ms is fast, but if your CLI tool needs to execute hundreds of discrete agent commands per minute, even 125ms adds latency. To achieve true instant execution, production systems utilize two advanced techniques: 1. VM Pools (Pre-warming) Your host application maintains a \"pool\" of 5-10 pre-booted microVMs idling in the background. When an agent needs to execute code, it instantly claims a VM from the pool. Once the execution finishes, the VM is destroyed, and a background thread boots a fresh one to replenish the pool. 2. Snapshotting Firecracker supports taking snapshots of a running microVM. You can boot a VM, start your Python environment, load necessary libraries into memory, and then \"pause\" the VM, saving its memory footprint and CPU state to disk. When you need to execute code, you \"resume\" from this snapshot. The VM bypasses the entire Linux boot sequence and is ready to execute Python code in less than 10 milliseconds. Conclusion & The Agentinel Advantage Docker is an incredible tool for packaging software, but it was never designed for executing malicious, untrusted code. As we enter the era of autonomous AI agents, security must shift from software-level namespace isolation to hardware-level virtualization. Firecracker microVMs provide the perfect balance: the uncompromisable security of KVM with the speed and overhead of a container. While building a Firecracker orchestrator from scratch is a massive engineering undertaking, ignoring the risk of container escapes is a liability no indie hacker or startup can afford. Call to Action: If you are building AI agents and need to ensure your local CLI environment isn't compromised by hallucinated packages or prompt injection, you need automated, intelligent guardrails. Use [Agentinel](https://github.com/aman-janwani/agentinel) as your lightweight CLI guardrail to monitor agent permissions, audit file access, and intercept dangerous execution patterns before they hit your OS kernel.","jsonLdSchema":{"@context":"https://schema.org","@graph":[{"@type":"BlogPosting","@id":"https://blog.habitwala.in/blog/setup-firecracker-microvm-llm-execution#article","isPartOf":{"@type":"WebPage","@id":"https://blog.habitwala.in/blog/setup-firecracker-microvm-llm-execution","url":"https://blog.habitwala.in/blog/setup-firecracker-microvm-llm-execution","name":"\"Setup Firecracker MicroVM for secure LLM CLI execution\"","description":"Docker isn't enough. Learn how to implement hardware-level isolation using Firecracker MicroVMs to securely execute untrusted LLM-generated code locally."},"headline":"\"Setup Firecracker MicroVM for secure LLM CLI execution\"","description":"Docker isn't enough. Learn how to implement hardware-level isolation using Firecracker MicroVMs to securely execute untrusted LLM-generated code locally.","url":"https://blog.habitwala.in/blog/setup-firecracker-microvm-llm-execution","mainEntityOfPage":"https://blog.habitwala.in/blog/setup-firecracker-microvm-llm-execution","datePublished":"2026-07-27T11:30:00.000Z","dateModified":"2026-07-27T11:30:00.000Z","inLanguage":"en-US","author":{"@type":"Person","@id":"https://blog.habitwala.in/author/aman-janwani#person","name":"Aman Janwani","jobTitle":"Founder & Lead Security Engineer","url":"https://blog.habitwala.in/author/aman-janwani","sameAs":["https://github.com/amanjanwani","https://x.com/amanjanwani1486","https://www.linkedin.com/in/aman-janwani/"],"knowsAbout":["AI Security","Next.js Performance","DevSecOps","Web Architecture"],"worksFor":{"@id":"https://blog.habitwala.in/#organization"}},"publisher":{"@id":"https://blog.habitwala.in/#organization"}},{"@type":"Organization","@id":"https://blog.habitwala.in/#organization","name":"Habitwala","url":"https://habitwala.in","logo":{"@type":"ImageObject","url":"https://blog.habitwala.in/habitwala-blog-black.png"},"sameAs":["https://github.com/habitwala","https://twitter.com/habitwala"]}]}}]}