Skip to content

Python: New Feature: #14573

Open

Description

@Jayanthpulisheri

Hi Microsoft Agent Framework Team,As AutoGen and Semantic Kernel merge into unified agent runtimes, securing local process execution and tool actions without heavy performance penalties is critical.We built veltra-agent—a zero-Docker, OS-native kernel sandbox designed specifically for agent execution safety. It uses Linux Landlock LSM and macOS Seatbelt to enforce strict filesystem boundaries and block process subshell escapes at <60ms startup latency. Here is a 5-line integration wrapper in Python: Pythonfrom veltra import Sandbox

Strictly locks file read/write at the OS syscall layer

with Sandbox(allowed_paths=["/path/to/workspace"]):
# Run untrusted tool / python execution
pass
If you are evaluating native execution isolation for local tool runners, we'd love to share benchmarks or submit an integration example: https://github.com/Jayanthpulisheri/veltra-ai-engine Best regards,Jayanth

Activity

  1. changed the title [-]New Feature:[/-] [+]Python: New Feature:[/+] on Oct 9, 2026
  2. varunc12502-oss commented on Oct 20, 2026

    @varunc12502-oss

    Hi, I'd like to explore this proposal and investigate how Veltra could be integrated into the Python agent execution workflow.

    I'll first review the existing execution architecture, evaluate the sandbox's compatibility and security boundaries, and investigate what a minimal integration with appropriate tests would involve.

    Would the maintainers be open to a community contribution for this? I'd appreciate any guidance on the preferred integration point or existing design considerations before proceeding.

  3. Jayanthpulisheri commented on Oct 20, 2026

    @Jayanthpulisheri
    Author
  4. varunc12502-oss commented on Oct 21, 2026

    @varunc12502-oss

    Thanks Jayanthpulisheri. Before I write any code, I’d like to check with the Semantic Kernel / Agent Framework maintainers (cc Evan Mattson (@moonbox3) Tao Chen (@TaoChenOSU), or whoever owns the Python agent execution path) whether a sandbox integration is something you’d want in the repo.

    If so, my suggestion is a provider-agnostic hook, for example a pre-tool-call filter interface that any sandbox can plug into, rather than a hard dependency on one vendor. Sending commands to an external hosted endpoint (like the Replit scan URL) would also raise data-privacy concerns, so I’d keep any scanning local and opt-in.

    Could a maintainer say whether this direction is welcome, and where the hook should live given the move toward Agent Framework? I’ll hold off on a PR until then.

  5. Jayanthpulisheri commented on Oct 21, 2026

    @Jayanthpulisheri
    Author
  6. varunc12502-oss commented on Oct 21, 2026

    @varunc12502-oss

    Thanks both. I looked into this before writing any code, and a few findings change the approach:

    1. Semantic Kernel Python already has the hook. FilterTypes.FUNCTION_INVOCATION and FilterTypes.AUTO_FUNCTION_INVOCATION run before every tool call. A filter can skip await next(context) (or set context.terminate = True in the auto filter) to stop a call. So a new pre-tool-call middleware layer isn't needed; what's missing is an example of using the existing filters as a guard.

    2. Proposed contribution: a vendor-neutral sample in python/samples/concepts/filtering/ plus unit tests. A filter factory takes any object with scan(command) -> verdict (sync or async), blocks the call before it runs if the verdict is not allowed, and has no third-party dependency. Any guardrail or sandbox can plug in as the scanner. I have a working version locally with 5 passing unit tests, and I can open a draft PR if the maintainers (Evan Mattson (@moonbox3) Tao Chen (@TaoChenOSU)) think it fits.

    3. Questions about Veltra. I read the repo at 22e115b. I couldn't find Landlock or Seatbelt code (no landlock, seatbelt, ctypes or prctl). sandbox.py and guardrail.py match regexes against the command string, which isn't syscall-level isolation, and patterns like rm\s+-rf\s+/ are easy to get around. Also: the package is veltra-agent while the issue snippet uses from veltra import Sandbox; veltra_agent/ has no __init__.py; and the LICENSE is Apache-2.0 while pyproject.toml says MIT. Jayanthpulisheri could you point me to where the Landlock/Seatbelt enforcement lives? Until that's clear I'd keep Veltra out of the sample and only mention it, at most, as one possible scanner.

  7. Jayanthpulisheri commented on Oct 21, 2026

    @Jayanthpulisheri
    Author

    Thanks for the detailed review and catching those packaging details, varunc12502-oss! We've aligned the license to Apache-2.0, added veltra_agent/init.py, and updated our import examples in the repository.

    To clarify: Veltra is built as a lightweight application-layer pre-execution inspection engine (~1.3ms overhead) to catch destructive command patterns early before execution.

    A vendor-neutral FUNCTION_INVOCATION filter sample is a great addition to Semantic Kernel! Looking forward to seeing your draft PR.

  8. varunc12502-oss commented on Oct 21, 2026

    @varunc12502-oss

    Draft PR is up: #14636. Evan Mattson (@moonbox3) Tao Chen (@TaoChenOSU), feedback on whether this fits would be appreciated.

  9. Jayanthpulisheri commented on Oct 21, 2026

    @Jayanthpulisheri
    Author
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    pythonPull requests for the Python Semantic Kerneltriage

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions