Optional on-device security scanning for imported skills before they run

Problem Statement

Disclosing affiliation upfront: I work on AgentGuard at GoPlus Security (https://github.com/GoPlusSecurity/agentguard, MIT). Feature request, opening for discussion before any PR as your form intro suggests.

OpenJarvis installs skills from OpenClaw (~13,700 community skills), Hermes (~150), or any GitHub repo, following agentskills.io. Those skills then run locally with shell access, file I/O, code execution (native_openhands CodeAct), and OAuth'd access to Gmail / Calendar / Drive via the digest presets. That's a large untrusted-code surface with a high blast radius on a personal device. A single malicious or compromised community skill could read secrets, exfiltrate personal data, or run arbitrary commands. Right now there's nothing between jarvis skill install and execution that inspects what a skill actually does. agentskills.io has no security gate, and 13,700 community skills can't be hand-vetted.

Proposed Solution

Two optional checks, both fully on-device (no cloud call, no model call, so they don't break the local-first thesis):

Skill scan at install / sync time. Static analysis of each imported skill, SKILL.md included, for backdoors, obfuscation, secret reads, network and webhook exfiltration, and prompt injection, before it enters the catalog. jarvis skill install gets a scan gate. Runtime tool-call guard (follow-up). A pre-execution check on shell / file / code_execution calls in the agent loop (orchestrator, native_openhands), returning allow / warn / block plus reason.

AgentGuard already does both. It ships an OpenClaw adapter and follows agentskills.io, the exact sources you import from, with 24 detection rules. Runs locally, sub-millisecond, no model call, so the overhead is negligible against your energy / FLOPs / latency budget. We already ship this as adapters for Claude Code (PreToolUse / PostToolUse) and OpenClaw (before_tool_call / after_tool_call) on a shared decision engine; an OpenJarvis adapter is the same pattern, third instance. Why this fits OpenJarvis specifically:

Local-first: a cloud guardrail would contradict the entire premise. AgentGuard is on-device, no network round-trip, no model in the loop. agentskills.io alignment: AgentGuard already speaks that standard, so the scanner understands the skill format you load. It also already scans OpenClaw skills, which is most of your skill surface. Intelligence-Per-Watt alignment: the scan adds negligible FLOPs / energy / latency compared to a single inference call, so it fits the project's first-class constraints.

Happy to implement Piece 1 (skill-install scan) as a tight PR scoped to that hook point only. Piece 2 (runtime tool-call guard) as a follow-up PR if Piece 1 lands well. If you'd rather start with a design comment, that works too.

Primitive Area

Agent

Alternatives Considered

Reasoning: the proposal hooks into the agent's skill-install path and tool-dispatch loop. Both live in the Agent primitive. Tools is a closer second if the maintainers prefer that bucket (the tool-dispatch hook touches tool execution directly), but Agent is the primary surface because the skill catalog is loaded into the agent before any tool runs. If the dropdown logic auto-routes to a specific team, follow whatever guidance they provide in the issue comments.

Atakan AgentGuard @ GoPlus Security https://github.com/GoPlusSecurity/agentguard [email protected]