Is my use case reasonable for Dagger?

[stray kite]

I've already gone through docs, etc... but just wanted to check-in with people who really understand everything to see if I should keep heading in the Dagger direction.

I'm building an open-source, self-hosted platform for discovering and running third-party AI agents.

• Federated (no gatekeepers - anyone can publish agents to a Git-based index)
• Agents run on user infrastructure with injected credentials
• All third-party agents treated as potentially malicious

I was looking at Kata/gVisor for isolation, but Dagger's sandbox looks very promising.

A couple specific questions:

1. Is the sandbox designed for potentially adversarial/untrusted code from arbitrary developers, or is it meant for isolating your own trusted modules from each other?
2. GPU passthrough? We need NVIDIA GPU access for local model inference (via Ollama/llama.cpp) I believe gVisor has issues with this

Thanks!

[blissful skiff]

Hello! The use case seems reasonable, with some caveats.

1. Is the sandbox designed for potentially adversarial/untrusted code from arbitrary developers, or is it meant for isolating your own trusted modules from each other?

Dagger provides a logical sandbox. The API and programming model assume that everything is sandboxed, and the composition model relies on explicit inputs and outputs with mutable artifacts flowing through them. So, it's a clean foundation for building a safe system.

Based on your use case, you probably want to combine Dagger's logical sandbox with VM isolation: deploy different VMs for different tenants, and run a Dagger engine inside each VM. -> This is what most of us do for running tests, builds, coding agents etc.

In the future the Dagger Engine may itself manage this level of multi-tenancy (the primitives are there thanks to the logical sandbox) but today that's not something you can deploy in a turnkey way: you would have to engineer it yourself.

2. GPU passthrough? We need NVIDIA GPU access for local model inference (via Ollama/llama.cpp) I believe gVisor has issues with this

Yes there is experimental GPU support. Here are a few resources about that:

• https://dagger.io/blog/gpu-challenges
• https://www.youtube.com/watch?v=FKfLQcdExxs

[stray kite]

Thank you, @blissful skiff - I will look into these resources. I appreciate your help!

[blissful skiff]

Note, the "injected credentials" part is an especially good fit for Dagger, we have a native API for that

[stray kite]

Thanks, @blissful skiff - your guidance helped a ton and I now have a clear path forward: Kata for VM isolation + Dagger for logical sandboxing.

Great to know Dagger has native credential injection - that's a core part of the vision (agents inherit user's model provider configs at runtime, never see the actual keys). That'll make the integration cleaner.

This combination will create a solid foundation for running untrusted third-party agents on user infrastructure (I see this as inevitable).

If you ever want to take a look: https://github.com/agentsystems/agentsystems

Appreciate the time!

[blissful skiff]

@stray kite coincidentally we're building the infrastructure for this as a cloud service, available in tech preview soon, in case you are interested 🙂

[stray kite]

Yes, very interested! Sounds highly relevant to what I'm working on. Would love to learn more once its ready. Thanks again, @blissful skiff.

[winter belfry]

Curious what this is referring to ? How would one inject a credential today ? (without the module/function invocation having to ask for it / reference the secret in some way)