VELA
Securely execute AI-generated & untrusted code
Start new thread
Praveen

VELA - Securely execute AI-generated & untrusted code

by
Lineage Lens
•
Autonomous AI agents are writing and executing code, but running it on your host server is a massive security risk. Vela (powered by the Aegis runtime) solves this. It’s a policy-driven execution guard that uses Firecracker micro-VMs and HMAC capability tokens to safely run untrusted code. Get structured results, fine-grained filesystem/network restrictions, and a full JSONL audit trail. Open-source, MIT licensed, and built for LangChain/LlamaIndex.

Add a comment

Replies

Best
Praveen
Maker
📌
Hey Product Hunt! 👋 What inspired us & the problem we're solving: With the explosion of autonomous AI agents (like those built with LangChain or AutoGen), LLMs are increasingly writing and executing Python scripts, shell commands, and data pipelines on the fly. But running untrusted, model-generated code directly on your host server or standard Docker containers is a massive security risk. Ad-hoc isolation (like monkey-patching stdlib calls) is brittle and easily bypassed. We realized the ecosystem was missing a fast, auditable, and truly secure execution guard designed specifically for the AI era. Our approach & how it evolved: Initially, we looked at heavy container orchestration, but it was too slow for real-time agent tool calls. We pivoted to a local-first, Rust-based daemon (Aegis) backed by Firecracker micro-VMs. This gave us hardware-level isolation with near-instant boot times. We then evolved the policy engine to use HMAC capability tokens. Instead of a blanket 'allow/deny', developers can now issue scoped, time-bound tokens per request (e.g., 'allow read/write to /tmp, block all network access, max 64MB RAM'). Finally, we built Python wrappers and LangChain adapters so agents can route dangerous tool calls into the sandbox transparently, without rewriting their core logic. We’ve open-sourced Vela under the MIT license because we believe secure AI execution should be a standard, accessible primitive for every developer. I’d love to hear your thoughts, feedback, and how you are currently handling code execution in your AI workflows! Let’s discuss below. 👇
Andreas Rubin-Schwarz

Congrats on the launch! Host-level agent code execution is a risk people underestimate, so great to see a policy-driven guard here. Will give it a spin on our end.

Praveen
Maker

@andreas_rubin_schwarz Thank you, Andreas!

That was exactly our motivation. As agents become more autonomous, the risk shifts from "can the model write code?" to "where is that code being executed?" We wanted a security layer that developers could place between AI-generated actions and their infrastructure without sacrificing speed or developer experience.

Really appreciate the support, and we'd love to hear your feedback once you've had a chance to try it.

Sanjay Kumar

The Firecracker micro-VM approach makes sense here, the ~150ms cold start seems totally workable for tool call use cases. I run a lot of AI-generated code via Claude Code and this is exactly the kind of safety layer I'd want underneath it. Does it handle MCP tool call contexts or is it mainly focused on raw script execution right now? Congrats on shipping!

Praveen
Maker

@i_sanjay_gautam 
Great question — Vela currently focuses on raw script execution, but MCP tool-call support is something we’re actively thinking about. The sandbox and policy layer are built to be flexible enough for both. Appreciate the kind words!

Florent Berrez

The interesting problem here isn't running untrusted code, it's what the sandbox actually contains. A lot of solutions stop at process isolation but still share a network namespace, which means a malicious payload can exfiltrate data or reach internal services even if it can't touch the host filesystem. Curious whether VELA does full network isolation per execution, and how you handle cases where the code legitimately needs outbound access, like an AI-generated script that has to hit an external API to do anything useful.

Praveen
Maker

@fberrez1 Thanks Florent — that's exactly the distinction we wanted to address.

You're right that process isolation alone isn't enough. In VELA, isolation is enforced at the micro-VM boundary, and network access is treated as a first-class policy decision rather than an implicit default. A sandbox can be launched with networking completely disabled, which is the safest mode for many AI-generated workloads.

For cases where outbound access is legitimately required (calling APIs, downloading data, etc.), developers can grant narrowly scoped capabilities through policy and capability tokens instead of giving unrestricted access. The goal is to move from a binary "sandboxed/not sandboxed" model to a least-privilege execution model where filesystem, network, runtime limits, and auditability are all controlled per execution.

We're still exploring richer network policies and would love to hear what controls you'd consider essential for production agent workloads. Thanks for the thoughtful question! 🙌