VELA

VELA: Securely execute AI-generated & untrusted code | Product Hunt

VELA

Launching today

Securely execute AI-generated & untrusted code

10 followers

Securely execute AI-generated & untrusted code

10 followers

Visit website

AI Infrastructure Tools

•

Security software

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.

Overview

Reviews

Alternatives

Built with

Forum

Team

More

Free

Launch tags:Developer Tools•Artificial Intelligence•GitHub

Launch Team / Built With

Subscribe

Forum Threads

p/vela-7•

3h ago

How are you safely executing code generated by your AI agents?

Hey Product Hunt community!

As a solo maker, I've been diving deep into the world of autonomous AI agents (LangChain, LlamaIndex, etc.). One of the biggest bottlenecks I kept hitting was code execution.

When an agent needs to analyze data, scrape a site, or run a simulation, it writes code. But where do you safely run it?

exec() or subprocess on the host machine? Terrifying. One bad prompt injection and the LLM accesses your .env files or exfiltrates data.

Standard Docker containers? Too slow and heavy for rapid-fire agent tool calls.

Cloud sandboxes? Great, but I didn't want to send my local data or proprietary agent logic to a 3rd party API just to run a simple pandas script.

View all

Promoted

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. 👇

Report

3h ago

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!

Report

1h ago

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!

Report

1h ago