AI agents often write and run code, and that code needs somewhere safe to run. Docker containers share the host kernel, which is a weaker boundary. Full virtual machines isolate better but start slowly and use a lot of memory. CubeSandbox aims for the middle: a small VM per sandbox that starts quickly.

Each sandbox is a MicroVM with its own OS kernel, built on RustVMM and KVM. The README says resource pooling and snapshot cloning keep cold starts under 60ms on bare metal, with under 5MB of memory overhead per sandbox. eBPF handles isolation between sandboxes and outbound filtering, and a built-in proxy can inject credentials so secrets never appear inside the sandbox.

The obvious alternatives are Docker containers, traditional VMs and the hosted E2B Cloud. CubeSandbox is compatible with the E2B SDK, and the README says you can switch from E2B Cloud by changing one environment variable. It runs on one node or scales to a cluster. The speed and memory figures are the project's own benchmarks.

Read more on interesting repos · GitHub

Traditional scanners often flag issues that are not really exploitable, and manual pentests are slow and costly. Strix takes a different route. AI agents run your app, poke at it the way a human tester would, and try to build a working proof-of-concept for each suspected flaw.

Each agent gets a toolkit inside a Docker sandbox: an HTTP proxy (Caido), a browser, a shell, a Python runtime for writing exploits, and recon tools. Several agents can work together, sharing what they find and chaining weaknesses. You supply an LLM API key from a provider such as OpenAI or Anthropic, or point it at a local model.

You aim it at a folder, a GitHub repo, a live URL or an API spec. Results are saved to disk, and a local web viewer shows findings and the agent team. The README also describes a hosted Strix Cloud and an Enterprise tier. The open-source version runs locally and is free apart from your LLM costs.

Read more on interesting repos · GitHub

Every LLM provider has its own SDK, login method, request shape and error types. If your app talks to several, that mess spreads through your code. LiteLLM puts one interface in front of all of them, using the OpenAI format you may already know.

You can use it two ways. The Python SDK is a library: you call completion() with a model name like openai/gpt-4o or anthropic/claude-sonnet-4-20250514, and it handles the provider details. The AI Gateway is a proxy server you run for a team. Apps point any OpenAI client at its URL, and the gateway forwards each call to the right provider.

Beyond plain chat calls, the gateway adds virtual keys, spend tracking, guardrails, load balancing and an admin dashboard. It also fronts MCP tool servers and A2A agents. The README reports 8ms P95 latency at 1k requests per second, which you should check against your own setup.

Read more on interesting repos · GitHub

Agent skills run inside tools like Claude Code, Codex CLI and Gemini CLI, and they are usually trusted with little checking. The README cites a research dataset of 31,132 skills, where 26.1% had vulnerabilities and 5.2% looked intentionally malicious. SkillSpector is built to answer one question: is this skill safe to install?

You point it at a local folder, a single SKILL.md, a zip file, a URL or a Git repo. It first runs fast static checks against 71 patterns in 17 categories, such as prompt injection, data exfiltration, privilege escalation, MCP tool poisoning and dangerous code. Optionally, an LLM then reads the skill for meaning that simple patterns miss. The result is a 0-100 risk score with severity labels and recommendations.

It is part of NVIDIA's Verified Skills pipeline, which scans, evaluates and signs skills before publication. It also supports a baseline file, so you can accept known findings and see only new ones on later scans.

Read more on interesting repos · GitHub

AI agents can run commands, call APIs and touch files, which is risky on your own machine. NemoClaw runs the agent inside an NVIDIA OpenShell sandbox instead, so you control what it can access.

A command-line tool walks you through onboarding: you choose an agent, a sandbox name, an inference provider and a model. NemoClaw then handles network policy, managed inference, integrations, saved state and the sandbox lifecycle.

It sits on top of OpenShell and the agents themselves. The docs have a page on when to use NemoClaw versus OpenShell alone. The README calls it an alpha project, with maintainers responding on a best-effort basis.

Read more on interesting repos · GitHub