The Video Signal

Topic

Sandboxing

All digests tagged Sandboxing

Ask the Experts: Evaluating Agent Skills | Nemotron Labs thumbnail

· 55:19

Ask the Experts: Evaluating Agent Skills | Nemotron Labs

This session details the evaluation of autonomous AI agent skills using NVIDIA's open-source framework, SkillEvaluator. The system provides a comprehensive, multi-tier pipeline to ensure that skills are safe, reliable, and genuinely useful before deployment. The evaluation process covers static security scanning (detecting risks like prompt injection and data exfiltration), deduplication checks, and live agent testing in a sandbox environment. This framework is critical for establishing quality gates in AI-driven workflows.

Key takeaways

  1. Three-Tier Evaluation Framework 2:00

    Skill evaluation utilizes a three-tier framework: 1) Static/Security checks (using SkillSpector), 2) Deduplication checks against an internal registry, and 3) Live Agent Testing, which assesses if the skill improves task performance in a sandbox environment.

  2. Security Scanning for Agent Risks 4:00

    SkillSpector is a standalone security scanner that checks for agent-native risks, including prompt injection, data exfiltration, trigger abuse, and tool poisoning. It combines static analysis with optional LLM semantic analysis.

  3. Measuring Skill Utility (Skill Lift) 7:30

    The evaluation measures 'Skill Lift' across five dimensions: efficiency, correctness, effectiveness, discoverability, and security. This determines if the skill genuinely helps the agent perform the task better compared to a baseline.

  4. Live Agent Testing Methodology 9:00

    Live agent evaluation runs the agent in a secure sandbox, performing an A/B test by comparing the agent's performance when the skill is available versus when it is restricted. This confirms if the skill is functionally necessary for the task.

Watch on YouTube Full article

Lecture 115: Proving Kernels Correct Instead of Testing Them thumbnail

· 40:07

Lecture 115: Proving Kernels Correct Instead of Testing Them

This lecture details the necessity and methodology of formally verifying GPU kernels, moving beyond traditional testing due to the massive input space and non-deterministic nature of GPU execution. The core approach involves reasoning about kernel correctness at the PTX level using Satisfiability Modulo Theories (SMT) solvers. The process requires modeling mathematical concepts (like floating-point operations and unbounded integers) as abstract 'reals' to prove equivalence between a candidate kernel and a reference implementation, thereby guaranteeing algorithmic correctness.

Key takeaways

  1. Limitations of Testing GPU Kernels 1:30

    Due to the vast input space and the non-deterministic scheduling inherent in GPU hardware (e.g., Nvidia), testing alone cannot guarantee correctness. Errors can occur across various boundaries (e.g., denormal boundaries, cancellation terms), and the execution order cannot be guaranteed at runtime. (0:01:30)

  2. Formal Verification at the PTX Level 2:10

    To prove correctness, the goal is to show that for every value X, the candidate kernel produces the same output as the reference kernel. This verification is performed at the PTX level because it provides relatively well-defined semantics, allowing the system to cover inputs from various sources (Triton, CUDA, inline PTX). (0:02:10)

  3. SMT Solvers and Mathematical Abstraction 3:20

    Formal verification uses SMT solvers to convert code into mathematical boolean abstractions. By modeling values as 'reals' (abstract values with infinite precision) and unbounded mathematical integers, the system can prove algorithmic equivalence without requiring bit-exact checks, which would lead to an unmanageable 'explosion' of clauses. (0:03:20)

  4. Advanced Verification Boundaries 4:30

    Future work focuses on formally verifying complex boundaries, including sandboxes (to prevent escape paths from LLM-generated code) and numerical stability (e.g., quantization stability), which are addressed separately from algorithmic correctness. (0:04:30)

Watch on YouTube Full article

Engineers… Your Software Factory NEEDS Agent Sandboxes to SCALE (exe.dev) thumbnail

· 37:15

Engineers… Your Software Factory NEEDS Agent Sandboxes to SCALE (exe.dev)

The video argues that traditional methods of running AI agents—such as allocating a small corner of a local machine or relying solely on containers/CI/CD—create bottlenecks. To achieve true scale and autonomy in an 'AI developer workflow' (ADW), the entire software factory must be moved into dedicated, isolated agent sandboxes (e.g., using exe.dev). This architecture enables complex workflows like running 'Best of N' comparisons across multiple model configurations while maintaining zero blast radius via disposable keys.

Key takeaways

  1. The Bottleneck Problem

    If an engineer is 'in the loop,' they are the bottleneck. True scaling requires moving beyond local compute limitations by giving every agent its own isolated computer, achieving isolation, scale, and autonomy.

  2. Three-Tier Architecture for Scale 23:25

    The recommended architecture involves an Out-loop orchestrator (on the engineer's machine), an In-sandbox orchestrator (on each VM), and the core Software Factory/ADW agents running inside the sandbox. This allows the top-level agent to kick off work and then go quiet, only requiring human intervention at planning and reviewing stages.

  3. Best of N Pattern 17:05

    Sandboxes enable running 'Best of N' patterns by simultaneously executing the same prompt/workflow across multiple agent configurations (e.g., Default, Frontier, Deepest, Open Weights), allowing for comparison and selection of the optimal outcome.

  4. Security and Isolation 27:50

    Sandboxes provide critical security by ensuring a 'bounded blast radius.' Agents use ephemeral resources, such as OpenRouter provisioning keys with hard spend caps, which are revoked upon teardown, preventing unauthorized access to production systems (e.g., AWS).

Watch on YouTube Full article

Build a secure computer for your agent thumbnail

· 36:51

Build a secure computer for your agent

As agents evolve beyond simple Q&A to writing and executing complex code (e.g., data analysis, software engineering), they require an isolated, persistent computing environment. The session details the architecture of LangSmith Sandboxes, a solution designed to provide production-ready, secure execution by giving each agent its own disposable computer. This system addresses critical challenges like untrusted model-generated code, container escape vulnerabilities, and scaling limitations inherent in traditional local or vanilla container setups.

Key takeaways

  1. Production-Grade Isolation 20:45

    Sandboxes utilize hardware virtualized microVMs for kernel-level isolation, ensuring that malicious code cannot escape the environment (preventing issues like container escapes). This level of separation is necessary because agents run untrusted, model-generated code.

  2. Scalability and Performance 23:50

    The platform supports scaling from one to thousands of isolated sandboxes in parallel. Benchmarking shows a median spin-up time of approximately one second, making it suitable for high-volume, user-facing applications.

  3. Secure Credential Management 25:20

    The O proxy acts as a man-in-the-middle proxy controlling all egress from the VM. This ensures that credentials never touch the runtime, significantly mitigating risks associated with data exfiltration or malicious network calls.

  4. State Persistence and Resilience 27:10

    Sandboxes support persistent state across long-running, interruptible tasks. Users can snapshot and restore the entire environment (including file system and memory), allowing for rollbacks or forking to test multiple scenarios.

Watch on YouTube Full article