KelvinClaw: A secure, modular agent harness with supply-chain validated plugins

Building secure agent systems at scale is a different problem than what most claw runtimes were designed to solve. We’re sick of seeing security duct-taped to existing claw runtimes — in zero-trust settings within enterprises and regulated organizations, this simply doesn’t work.

So we built KelvinClaw, and we’re launching it into the world today. We’re building in the open, warts and all, and need contributors to help make something people feel comfortable running on their own machines. If this is the kind of problem you like working on, the KelvinClaw repos are accepting PRs:

• Core repo (for changes/additions to core source code): https://github.com/AgenticHighway/kelvinclaw
• Plugins repo (for plugin authoring): https://github.com/AgenticHighway/kelvinclaw-plugins

KelvinClaw (or Kelvin) is an agent harness that starts from a minimal trusted core and expands outward. New capability, whether from us or the community, is added deliberately and under explicit constraints. Plugins, Kelvin’s primary extension point, declare their capabilities and scopes before they run. Trust operates in levels, from unsigned local builds up to verified, registry-vetted releases. We'll get into the details below.

Plugin Model

The runtime never has to take a plugin on faith. Every plugin ships as a signed WASM binary and declares its scopes and capabilities upfront, including our own first-party plugins. Kelvin currently has two tested and supported plugin types:

• Tool providers (wasm_tool_v1) — extend what the agent can do (one tool per plugin for now)
  • First-party examples: kelvin.websearch, kelvin.wiki
• Model providers (wasm_model_v1) — swap or add LLM providers without touching the core
  • First-party examples: kelvin.anthropic, kelvin.ollama

Kelvin ships with no plugins by default. Discovery and install go through the integrated plugin manager, backed by a hosted index (currently on GitHub) that tracks versions, checksums, and trust tiers. You can point the plugin manager at our index or fork it and run your own. Nothing installs without passing a quality gate.

$ kelvin plugin install kelvin.openrouter

One last thing: you can widen your trusted_publishers.json to allow any plugin you want. We won't stop you, but we will judge you a little.

Control/Data Plane Split

Memory and orchestration live in separate planes.

The data plane (kelvin-memory-api, kelvin-memory-controller, and kelvin-memory-module-sdk) handles memory in an independent process, communicating over gRPC, validating JWT delegation per operation, and running isolated WASM memory modules.

The control plane (kelvin-brain, kelvin-gateway, and kelvin-host) handles runtimes. It is responsible for validating requests and ingress, dispatching runtimes, enforcing trust policies, and streaming telemetry and lifecycle events. The control plane also assigns privilege by ingress origin. Operators on the websocket get elevated access; Telegram and Discord get a slightly reduced scope; unpaired guests can interact with the owner's agent under different permissions.

This separation means that a compromised plugin in the control plane has no direct path to memory operations.

Local Model Providers

Kelvin’s minimal core and failure containment mechanisms change what’s realistic with local inference. With kelvin.ollama, no prompts, tokens, or tool outputs leave the host. Since Kelvin ships with no plugins by default and the runtime doesn’t rely on a model for security, 4B-class models can do meaningful work. The runtime's failure containment also helps: a flubbed tool call trips a circuit breaker instead of derailing the session.

For enterprises and regulated organizations, this can be a hard requirement. Sending agent interactions to a cloud API means sending data outside your infrastructure, which can conflict with legal, contractual, or internal policy requirements. A local model plugin removes that dependency entirely, and Kelvin's architecture makes it a straightforward swap rather than a custom integration.

Conclusion

Here’s what works:

• Core runtime: prompts, tool executions, and lifecycle events
• Plugin index, search, and installation
• Failure containment: circuit breakers, fuel budgets, bounded retries
• Telegram and Discord ingress
• Session management and notes
• Whitelisted web hosts and restricted filesystem access

Here’s what doesn’t work/isn’t implemented:

• Shell execution in the ABI — this is a tough security problem we haven’t solved yet
• MCP and skills integrations — same
• Other plugin types for memory modules and ingress channels
• Tool plugins only support one tool per plugin — this will be added in coming weeks
• Community plugin development and submissions helpers aren’t fully tested
• Whatever other fun bugs you may find: kick our tires!

A few of these aren't oversights. Shell execution and MCP integration are on the list, but we're not shipping them until we can do it without poking holes in everything we just described. We built the trust model first because it's the part you can't tape on later. Everything else is a work in progress.

Contributing

If this is the kind of problem you like working on:

• Try to break the trust model: kelvin plugin install and have at it
• Open issues tagged help wanted in both repos
• We especially want eyes on the JWT delegation logic in kelvin-memory-controller and the trust-tier enforcement in the plugin manager

PRs welcome.