AI agents need a safer execution boundary.
Local execution, Docker and cloud sandboxes all solve part of the problem. Jhansi focuses on the missing boundary: self-hosted execution where agents do not receive raw credentials.
Why not run generated code locally?
Because the blast radius is your machine: filesystem, shell, environment variables and developer credentials.
Local execution
Fast for prototypes, risky for arbitrary generated code.
Jhansi
Generated code runs in an isolated sandbox. The agent gets the result, not direct access to your machine.
Why not just use Docker?
Docker is a container primitive. Jhansi is an agent execution workflow built around sandbox lifecycle, secret isolation and MCP usage.
| Docker | Jhansi |
|---|---|
| Generic container runtime | AI-agent execution boundary |
| Manual lifecycle wiring | Create, execute, return, destroy workflow |
| Manual secret handling | Credentials mapped at runtime, not given to the agent |
| No MCP-native interface | MCP and SDK based access |
Why not E2B or Daytona?
They are useful platforms, but they are primarily cloud-oriented. Jhansi starts from a different assumption: some teams want the execution layer inside their own environment.
Cloud runtimes
Useful when external cloud execution is acceptable.
Self-hosted teams
Need control over data, credentials, networking and execution boundaries.
Jhansi
Self-hosted by default, designed for agents that need execution without credential exposure.
Jhansi is not another coding assistant.
It is the execution boundary for what AI agents produce.