Skip to content

Layering question: HELM AI Kernel as deterministic execution boundary alongside AgentGuard #105

Description

@peycheff-com

AgentGuard's 24 detection rules, runtime evaluation, and trust registry handle a broad threat surface — skill scanning, secrets, network anomaly, OWASP MCP Top 10. That's genuinely complementary to what HELM AI Kernel does.

HELM is intentionally narrower: a small OSS fail-closed execution boundary that enforces default-deny on side-effectful tool calls (shell, file, DB, cloud) and emits a signed receipt for every ALLOW/DENY/ESCALATE decision, bundled into an offline-verifiable EvidencePack. No pattern-matching classifier — just deterministic policy enforcement and verifiable proof of outcome.

The layering story: AgentGuard classifies and blocks malicious skills before they run; HELM enforces default-deny at the moment of tool dispatch and notarizes what actually happened — producing receipts that survive independent of both runtimes.

Would someone on your team be open to running the HELM local proof demo under an AgentGuard-protected Claude Code session and filing a blunt issue on what's complementary vs. redundant?

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 would a boundary kernel need to prove in receipts, logs, and failure modes before you'd consider recommending it as a companion runtime layer to AgentGuard?

Repo: https://github.com/Mindburn-Labs/helm-ai-kernel
Docs: https://helm.docs.mindburn.org/helm-ai-k...

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions