container-mcp exposes a broad MCP toolbox inside a Podman container: bash shell, file operations, code execution, knowledgebase, and more. That multi-tool surface is exactly where per-tool execution policy matters — the risk level for a file read is different from a bash command that chains into code execution.
We're building HELM AI Kernel, a small OSS fail-closed execution boundary that can sit at that boundary: different policy per MCP tool type, signed receipts for every ALLOW/DENY/ESCALATE decision, and offline-verifiable EvidencePacks per session. Unknown MCP tools enter quarantine until schema and policy are approved.
The gap in a multi-tool MCP server: there's currently no independent signed record of which tools were called, what policy was in effect, and what was allowed vs. blocked. A single agent misdirection can chain shell + file write + code exec without any deterministic boundary between steps.
Would you be open to testing a local HELM policy against one multi-tool container-mcp scenario — e.g. shell + file writes + code execution in sequence — and filing feedback on what per-tool metadata HELM should understand?
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: Should policies in a multi-tool MCP server reference MCP tool names, underlying commands, declared capability tags, or all three?
Repo: https://github.com/Mindburn-Labs/helm-ai-kernel
container-mcp exposes a broad MCP toolbox inside a Podman container: bash shell, file operations, code execution, knowledgebase, and more. That multi-tool surface is exactly where per-tool execution policy matters — the risk level for a file read is different from a bash command that chains into code execution.
We're building HELM AI Kernel, a small OSS fail-closed execution boundary that can sit at that boundary: different policy per MCP tool type, signed receipts for every ALLOW/DENY/ESCALATE decision, and offline-verifiable EvidencePacks per session. Unknown MCP tools enter quarantine until schema and policy are approved.
The gap in a multi-tool MCP server: there's currently no independent signed record of which tools were called, what policy was in effect, and what was allowed vs. blocked. A single agent misdirection can chain shell + file write + code exec without any deterministic boundary between steps.
Would you be open to testing a local HELM policy against one multi-tool container-mcp scenario — e.g. shell + file writes + code execution in sequence — and filing feedback on what per-tool metadata HELM should understand?
Local demo (~5 min):
One feedback question: Should policies in a multi-tool MCP server reference MCP tool names, underlying commands, declared capability tags, or all three?
Repo: https://github.com/Mindburn-Labs/helm-ai-kernel