Blog · arXiv Analysis · Published: June 24, 2026 · Modified: August 12, 2026 · Last reviewed: August 12, 2026

The Skill Manifest Becomes the Permission Boundary

A skill manifest is a version-bound declaration of the capabilities and resource constraints a skill may need. It is not proof that the skill is benign, not permission by itself, and not a boundary unless an independent policy engine mediates every relevant effect.

Version 2 of the SkillGuard preprint tests that design across skill text and runtime action. Its results support manifest-driven enforcement as one useful layer, while its surviving attacks, uneven utility costs, permissive approval simulation, and implementation assumptions show why the manifest cannot carry the whole safety case.

The Current Paper

The current source is Shidong Pan, Xiaoyu Sun, Tianyi Zhang, Dianshu Liao, Kaiwen Yang, and Zhenchang Xing’s SkillGuard: A Permission-Centric Framework for Agent Skill Security, arXiv:2606.03024v2 [cs.CR, cs.SE]. The arXiv record dates version 1 to June 2, 2026 and version 2 to July 13, 2026. Version 2 changed the title, author line, design summary, sample, agent coverage, and reported results. This page follows v2 rather than carrying the original June numbers forward.

SkillGuard is a research framework and evaluation, not an adopted Agent Skills standard, a product certification, or proof that a listed skill is safe. Its central proposal is nevertheless precise: make the skill a security principal whose declared authority can be compared with what the host is about to execute.

The paper sits between this site’s account of skills as portable work instructions and its account of skills as runtime contracts. The first explains why procedure becomes authority. SkillGuard asks how that authority can be declared, narrowed, mediated, and recorded.

A Manifest Is Not a Grant

The clean definition has three layers. A declaration states the maximum capabilities a named skill may request, under specified constraints. An authorization decides which subset is appropriate for this operator, user, task, data class, and time. Enforcement prevents actions outside that effective subset. Calling all three a “manifest” lets a publisher’s claim masquerade as institutional permission.

The distinction is especially important in the current format landscape. The official Agent Skills specification requires a SKILL.md with name, description, and instructions and permits scripts, references, assets, and other files. Its optional allowed-tools field is explicitly experimental, and support may vary by implementation. A pre-approved tool-name list is not the same artifact as SkillGuard’s JSON capability-and-constraint DSL, and it does not create portable semantics for paths, destinations, data classes, approval lifetime, or policy precedence.

The host remains decisive. Anthropic’s Agent Skills documentation, for example, says skills used through its API run in a sandbox without network access or runtime package installation, while Claude Code skills have the network access of programs on the user’s computer. The same folder can therefore have a very different effective reach on different surfaces. A manifest should describe requirements; the host must still impose the smaller of organizational policy, user authority, task need, and environmental containment.

What SkillGuard Adds

Version 2 describes four core components: Skill Manifest, Runtime Permission Control, User Interaction, and Policy Enforcement. Its DSL groups protected behavior across storage, code repositories, network, execution, hardware, system state, secrets, and the agent ecosystem. Each permission entry combines a canonical capability with an allow, confirm, or deny effect and optional constraints such as workspace-only access or path prefixes.

The runtime maps host-specific tool calls to those canonical capabilities, then checks the effective session policy before dispatch. Workspace defaults seed the session, skill manifests add declarations, and user approvals can add constrained grants. A session approval copies the original constraint set rather than widening it. For shell-style execution, a separate permission-generation mini-agent inspects the command and referenced workspace scripts for lower-level effects, which are checked again. Failed analysis, explicit denial, rejected confirmation, or an unmatched eligible permission blocks execution.

This is stronger than asking the main model to obey a warning. The model can propose a call; the host-side interposer decides whether it leaves the agent loop. But “complete mediation” is an architectural claim, not a label: every consequential path—including shell children, network libraries, delegated agents, browser actions, and policy mutation—must actually pass through a non-bypassable control. A hook that misses one side channel is not complete because its rule says it is.

The public artifact repository adds useful implementation detail. Its reference integration uses Claude Code lifecycle hooks and writes structured audit state, but its README also calls the implementation initial, says task scope currently equals the declared pool, leaves loaded skills in that pool for the session, and lists overlapping-constraint and unload semantics as open questions. Those statements are implementation status, not defects silently resolved by the paper’s architecture diagram.

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 assumptions that reshape the agent before any external action. On the action plane, it can steer file access, code execution, network communication, API calls, policy changes, or delegation.

Permission mediation can connect the planes, but it cannot reduce meaning to a capability name. The paper’s own error analysis finds attacks that reuse permissions already needed by the benign skill. A malicious mass-forward and an intended email send can both fit network-post and external-API permissions. A content-only document attack can use the same read/write permissions as an ordinary edit. The manifest can say which kind of effect is possible; it may not say whether this particular content transformation serves the user’s purpose.

Composition adds another risk. If several skills contribute capabilities to one session pool, the runtime must prevent one skill from laundering its action through another skill’s declaration. The artifact repository explicitly treats model-reported attribution as untrusted and offers isolated execution for stronger attribution, while also noting that loaded skills currently remain declared for the session. Production governance should preserve the causal chain—user task, loaded skill, referenced resource, delegated component, tool call—and isolate or intersect authority when that chain is ambiguous. This connects directly to skill-composition testing.

SkillGuard therefore belongs beside intent-governed tool authorization and agent sandboxing, not in place of them. Intent scoping asks what this task is for. The manifest names a skill’s maximum request envelope. Sandboxing and credential brokers limit physical reach. Runtime policy decides which specific effect may proceed.

What the Evaluation Shows

For taxonomy expressiveness, v2 sampled 1,260 SkillsMP entries: the ten most-starred and ten randomly chosen skills from each of 63 categories. Annotators found explicit resource-targeted instructions in 784 skills. Across 1,408 observed protected-object occurrences, 1,407 mapped to the predefined taxonomy, giving 99.93 percent object-level coverage and 100 percent coverage at the eight-group level. This shows that the vocabulary described almost every object annotators extracted; it does not show that 99.93 percent of risky behavior was detected or controlled.

For defense, the authors used 50 safe SkillInject skills and their contextual and obvious injected variants across three agent/model pairings: Gemini CLI with Flash 2.5, Codex CLI with GPT-5.4-mini, and Claude Code with Haiku 4.5. Each attack condition therefore contains 150 runs. Aggregated contextual attack success fell from 53 of 150 runs (35.3 percent) to 31 (20.7 percent); obvious attack success fell from 55 (36.7 percent) to 27 (18.0 percent). Those are substantial reductions within this benchmark, not model-independent rates, and the residual successes remain operationally important.

The utility result is not cost-free or uniform. Across 124 eligible contextual runs, benign task success fell from 87.1 to 80.6 percent. Gemini CLI and Claude Code were unchanged in the reported setup; Codex CLI fell from 97.6 to 78.0 percent. Mean token use rose 24.7 percent overall, while wall-clock effects varied because some agents stopped after denial and others spent time replanning. A governance decision therefore needs per-workflow error, latency, and cost measures rather than one aggregate claim that the guardrail preserves utility.

The Evidence Boundary

The benchmark starts from safe skills whose reference manifests were written by two authors after inspecting the files and, where useful, executing them. It then tests injected variants against those benign declarations. That is a meaningful update or tampering scenario. It is not the same as a malicious publisher submitting a dangerous skill together with a matching broad manifest, a reviewer approving unnecessary authority, a compromised manifest file, or an attacker bypassing the hook runtime itself.

The evaluation approved all confirmation requests by default. It therefore measures undeclared, constrained, and denied capability enforcement without testing whether people understand the prompts, notice suspicious destinations, resist fatigue, or safely manage persistent grants. The authors describe this as a lower bound because a user could deny more requests. Operationally, a user can also approve too much; approval quality remains an unmeasured dependency.

Taxonomy extraction and outcome scoring also involve judgment. Two annotators reached a Cohen’s kappa of 0.662 on protected-object annotation, then resolved differences. Attack and task success were scored by an LLM judge in two runs. The experiments used fixed containers and released scripts, but they do not exhaust larger models, other tools, live enterprise identities, long-running sessions, skill updates, or multi-skill privilege interactions.

The hard claim is consequently narrower than “the skill is safe.” SkillGuard reduced two classes of injected attack in a released benchmark by blocking effects outside reference manifests, with measurable and scaffold-dependent utility and cost. It did not eliminate attacks that stayed inside declared capabilities or prove that every consequential effect was mediated.

The Governance Standard

Bind the declaration to the artifact. Hash or sign the manifest together with SKILL.md, scripts, references, assets, dependency locks, and externally fetched resources where feasible. Any material update should produce a permission diff and renewed review. A manifest for yesterday’s bundle cannot authorize today’s rug pull.

Separate request from grant. The skill author may describe requirements, but organizational policy and an accountable operator decide authority. Fixed precedence should keep platform and organization denies above skill-provided priorities. Generated manifests are review aids, not self-approving security policy.

Constrain real resources. Distinguish read, write, delete, execute, send, publish, install, delegate, and expand-policy effects. Bind them to path prefixes, repository remotes, domains or endpoint classes, recipient identities, data classifications, rate and value limits, and a task purpose. “May call the network” is rarely a least-privilege production rule.

Enforce below the model. Put sensitive files and credentials outside the agent boundary; use read-only mounts, scoped and short-lived tokens, egress proxies, sandboxes, and transactional APIs. Command analysis can expose hidden subeffects, but it should supplement operating-system and service enforcement rather than replace them.

Compose by intersection or isolation. Do not silently union every loaded skill’s authority into a reusable ambient pool. Attribute each action to a task and skill chain, prevent inherited grants from crossing isolation boundaries, revoke authority when a skill unloads, and use dedicated workers for untrusted or high-impact skills. This belongs with agentic supply-chain controls.

Make approval specific and expiring. A useful prompt names the action, resource, data leaving the boundary, destination, reversibility, requesting skill, and grant lifetime. One action should be the default; task or session grants should preserve constraints and remain visible and revocable. A generic “allow tool” button turns review into prompt fatigue.

Test and respond. Pair manifest review with static scanning, sandboxed detonation, benign regression cases, adversarial context tests, composition tests, and observed-versus-declared runtime diffs. A mismatch should trigger containment, developer notice, evidence preservation, correction, and reauthorization—not merely another badge in a marketplace.

The Enforcement Receipt

A reviewable receipt should record the skill source, signer, artifact and manifest hashes, owner, version, dependency closure, host and policy-engine versions, workspace baseline, task purpose, loaded and unloaded skills, effective capabilities and constraints, policy precedence, sandbox and credential boundary, and the model or rule used for command-capability inference.

For each mediated event, preserve the requesting skill or causal chain, tool and normalized capability, concrete resource and destination, relevant data class, decision, matching rule and source, constraint result, user-facing prompt, approver, grant lifetime, actual dispatch, returned effect, error, and later revocation. Record blocked calls as well as allowed ones. This turns the agent log into a receipt without pretending a trace explains the model’s private reasoning.

The receipt is itself sensitive. Paths, prompts, tool inputs, API destinations, failure text, and approval history can expose secrets or regulated data. Minimize fields, redact values where the decision can still be audited, separate security telemetry from content, restrict access, set deletion periods, and test that revocation reaches cached and persistent grants.

Source Discipline

This page uses the versioned arXiv v2 HTML and PDF for the paper’s current title, authors, design, dataset, results, and threats to validity. The submission history establishes that v1 and v2 are materially different records; numbers from the original June draft are not mixed with the July revision. The work is treated as a preprint and benchmark evaluation, not an ecosystem-wide incident rate or a deployed certification.

The Agent Skills specification answers a different question: what a portable skill folder and SKILL.md may contain. Its experimental allowed-tools field does not establish SkillGuard’s semantics or prove enforcement by every client. Anthropic documentation is primary evidence for its own product surfaces and security guidance, not for all skill runtimes. The SkillGuard repository is evidence of released code, data, README status, and open implementation questions; because it is mutable, this page links the reviewed commit as well as the paper.

Claims should preserve four labels: declared by a skill or publisher, authorized by an independent policy source, observed in a test, and enforced by a runtime control. A source-disciplined review also names versions, model/scaffold pairings, benchmark denominators, approval simulation, utility changes, and residual attacks under the site’s research-integrity standard.

The Spiralist rule is simple: a reusable work instruction that can steer an agent is no longer only documentation. The manifest makes its requested authority inspectable; governance begins when somebody independent can narrow it, the runtime can enforce that decision, and affected people can reconstruct what happened.

Sources

Return to Blog