Harshit Shah

[WIP] Agents Keep Eating Local Skills — We Built a Registry That Won’t Trust Them Blindly

Submitted Oct 9, 2026

One-line summary
Local agent skills (folders, clones, drop-in scripts) have no platform control plane. This session walks through Skillward: an open protocol to discover, fetch, checksum-verify, and sandbox-execute remote skills over HTTPS — and the trade-offs vs MCP and filesystem Agent Skills.

What problem are you addressing?
Teams shipping AI agents need tools/skills on demand. The easy path is local installs: a SKILL.md tree, a script next to the agent, or a cloned repo mounted into the runtime. That scales poorly for platform and security teams:

  • No inventory of what’s running across the org
  • No integrity between “what was reviewed” and “what executed”
  • Weak access control (filesystem access ≈ skill access)
  • No central revocation or audit trail
  • Version drift across machines

Skillward explores the opposite: skills as registry-hosted artifacts behind auth, with manifest + sha256, deny-by-default sandbox capabilities, and framework adapters so agents don’t each invent their own loader.

What’s interesting is the split: discovery/auth at the gateway, authorization per skill, integrity before exec, capabilities only if granted — and being explicit that this is not a replacement for MCP or Agent Skills, but a third distribution/execution path with different guarantees.

Who is the intended audience?
Platform Engineering / SRE / DevOps / Security / AI platform engineers / Engineering leaders deciding how agents get tools in enterprise environments.

Level: intermediate

List one or two practical takeaways.

  1. A concrete checklist of what local skill installs fail to provide (visibility, integrity, ACL, revoke, audit) — and which controls map to each gap.
  2. A reference flow you can clone: Envoy auth → registry ACL → fetch → sha256 → sandboxed invoke, plus where MCP / SKILL.md still fit better.

What will you share?

  • Architecture / design (gateway vs registry vs orchestrator vs sandbox)
  • Implementation details (manifest schema, capability policy, Python/Node runtimes, text skills)
  • Open-source tooling (Skillward protocol + reference orchestrator)
  • Live demo: publish → discover → verify → sandbox run; private skill hidden from wrong account
  • Trade-offs vs MCP tools and filesystem Agent Skills
  • Failure modes: checksum mismatch, over-broad capabilities, “text skill vs code skill” confusion

What is your experience with this problem? Choose any that apply:

  • Open-source project
  • Experiment or prototype
  • Internal engineering project (platform concerns around agent tooling)

What approaches failed, disappointed, or created unexpected problems?
Treating “ship a folder of skills” as enough for multi-team use. It works for authoring velocity and retrieval (e.g. SOP corpora), but collapses the moment you ask “who ran what, was it the reviewed bits, and can we pull it back?” Also: assuming MCP or Agent Skills already solve integrity + sandbox of fetched executable payloads — they optimize for different layers.

What will you do differently today?
Separate instructions (markdown SOPs) from executable skills (code with a capability surface). Put executables behind discover/auth/verify/sandbox. Keep MCP for live tool servers and SKILL.md for procedural guidance — don’t force one mechanism to do all three jobs.

What trade-offs did you consider?

  • Registry + HTTPS vs local mount: stronger control plane; more moving parts (gateway, accounts, backends)
  • Checksum verify every fetch vs trust the disk: integrity by default; requires publishing discipline
  • Subprocess sandbox vs full Wasm/WASI: shippable reference now; weaker isolation than a heavier runtime later
  • Own protocol vs extend MCP: clearer integrity/sandbox story for payloads; not interoperable with MCP registry
  • Optimized for: enterprise-ish guarantees (authn, ACL, verify, sandbox, telemetry)
  • Knowingly gave up: zero-ops local DX; federation with official MCP registry

How can this help other practitioners?

  • A pattern for agent tool distribution as a platform product, not a laptop folder
  • A way to evaluate competing approaches (local skills vs MCP vs remote verified skills)
  • Mistakes to avoid: unbounded capabilities, skipping verify, conflating “skill as docs” with “skill as code”
  • Operational practices: private skills + allowed_accounts, invocation logging, central revoke

Current state - choose one:
Open source + experimental/prototype (reference implementation; not claiming production-hardened)

Tags
#agents #security #sandboxing #governance #platformengineering #sre #devops #developerplatforms #demo #workinprogress #opensource

Comments

{{ gettext('Login to leave a comment') }}

{{ gettext('Post a comment…') }}
{{ gettext('New comment') }}
{{ formTitle }}

{{ errorMsg }}

{{ gettext('No comments posted yet') }}

Hosted by

We care about site reliability, cloud costs, security and data privacy