Kilntainers gives agents ephemeral Linux sandboxes with shell access via MCP — exactly the environment where a deterministic execution boundary adds value.
We're building HELM AI Kernel, a small OSS fail-closed execution boundary that can sit between an agent and that sandbox. It defaults to deny risky commands, routes unknown MCP tools to quarantine until approved, and emits a signed receipt for every ALLOW/DENY/ESCALATE decision — verifiable offline via EvidencePack.
The gap Kilntainers doesn't currently close: there's no signed artifact proving which sandbox commands were dispatched vs. blocked after a session ends. If an agent runs rm -rf or git clean -fdx inside the sandbox, there's no independent proof of what policy was active and what actually executed.
Would you be open to trying one Kilntainers sandbox workflow through HELM with a "block destructive shell verbs" policy and filing an issue with what breaks or feels wrong?
Local demo (~5 min):
brew install mindburnlabs/tap/helm-ai-kernel
helm-ai-kernel serve --policy ./release.high_risk.v3.toml
helm-ai-kernel boundary status --json
helm-ai-kernel receipts tail --agent agent.demo.exec --server http://127.0.0.1:7714
One feedback question: What receipt fields or policy metadata would Kilntainers need before treating an external execution boundary as trustworthy for sandbox dispatch?
Repo: https://github.com/Mindburn-Labs/helm-ai-kernel
Kilntainers gives agents ephemeral Linux sandboxes with shell access via MCP — exactly the environment where a deterministic execution boundary adds value.
We're building HELM AI Kernel, a small OSS fail-closed execution boundary that can sit between an agent and that sandbox. It defaults to deny risky commands, routes unknown MCP tools to quarantine until approved, and emits a signed receipt for every ALLOW/DENY/ESCALATE decision — verifiable offline via EvidencePack.
The gap Kilntainers doesn't currently close: there's no signed artifact proving which sandbox commands were dispatched vs. blocked after a session ends. If an agent runs
rm -rforgit clean -fdxinside the sandbox, there's no independent proof of what policy was active and what actually executed.Would you be open to trying one Kilntainers sandbox workflow through HELM with a "block destructive shell verbs" policy and filing an issue with what breaks or feels wrong?
Local demo (~5 min):
One feedback question: What receipt fields or policy metadata would Kilntainers need before treating an external execution boundary as trustworthy for sandbox dispatch?
Repo: https://github.com/Mindburn-Labs/helm-ai-kernel