Independent

thomas.martin@thomasmartin-pmp.de

skill agent intake supply chain security Skill Intake Security (SKIS) defines how an organization should examine a third-party skill, plugin or agent definition before it is allowed to act: four review levels graded by risk, a verification chain from provenance to a release record, and operational controls for updates, inventory, logging and revocation. AI agents increasingly extend their capabilities with third-party skills: packages of natural-language instructions, metadata and helper scripts that a model reads as authoritative context. Related work addresses agent identity, authorization, discovery and skill-layer risks; this document proposes a consolidated intake procedure with explicit organizational obligations. The verification chain covers provenance, integrity pinning, full-content inspection and comparison of declared versus observed capabilities. SKIS is vendor-neutral and intended to complement existing identity and provenance specifications. Status of this draft This document is an individual contribution and does not represent IETF consensus. It was subject to two rounds of AI-assisted adversarial review; no independent human review is asserted. Figures in Section 1.2 were checked against primary sources on 29 October 2026.

Introduction

Problem A skill is text that an agent obeys. Skills combine natural-language instructions, metadata and optional executable content; malicious behavior can originate in any of these components or in their interaction, and conventional code scanning alone does not establish safety. Skills are typically unsigned, published without review, and installable by anyone with a repository account.

Evidence Published measurements indicate that the problem is not hypothetical (checked against the primary sources on 29 October 2026, see the informative references):

• A scan of 3,984 skills from ClawHub and skills.sh (5 February 2026) found at least one critical issue in 13.4 percent (534 skills) and at least one security flaw of any severity in 36.82 percent (1,467 skills). It confirmed 76 malicious payloads, 91 percent of which combine prompt injection with conventional malware; prompt injection across all ClawHub skills was 2.6 percent . The 36 percent figure measures flaws of any kind, not prompt injection, although the report's title suggests the latter. These metrics describe different outcomes and populations.
• A static scan of 17,065 skills in 392 public repositories found that 38.8 percent (6,615) contain shell commands, while only 4.0 percent (690) declare Bash in their metadata . Caveats: vendor blog post, not peer reviewed; the sample is the first 500 GitHub search hits, not a random sample; commands assembled at runtime are not counted, so the true surface is likely larger. These are static indicators, not observed execution; 12,280 of the skills were unique by content hash.
• An arXiv preprint on 17,022 skills sampled from 170,226 on SkillsMP found 520 skills with 1,708 credential-leak issues; 466 of the 520 skills (89.6 percent) leak credentials through at least one runtime channel during normal execution, and 481 of 520 (92.5 percent) become exploitable in the execute phase; both use the same denominator and their overlap is not reported. The paper's abstract and introduction tie the absence of elevated privileges to the 92.5 percent figure, Section 4.3 of the paper to the 89.6 percent figure .
• Automated skill-based prompt injection (SkillJect, arXiv preprint) reaches an average attack success rate of 80.7 percent on Claude Code across four victim models, against 0.0 percent for naive direct injection; per model the range is 47.0 to 97.2 percent . ASR counts execution of the designated hidden helper script; it does not establish that the intended downstream harm completed.
• Hidden payloads occur in practice. Of 35,878 skills submitted to VirusTotal, 6,637 were malicious; 62 percent of those carry their payload only as plain-language instructions. Ninety skills (1.4 percent of the malicious ones) conceal them by whitespace padding (56), HTML comments (28) or invisible Unicode, namely tag and zero-width characters (6); the authors call these counts lower bounds . Submission-corpus proportions are not estimates of ecosystem-wide prevalence. An open-source skill scanner initially missed Unicode tag characters and was fixed after a report . Bidirectional control characters make displayed text differ from its logical order, shown for source code in 12 languages (Trojan Source, CVE-2021-42574) ; for skills the evidence is descriptive: a Cloud Security Alliance research note recommends rejecting them in skill files and MCP manifests , and a scanner issue documented missing bidirectional-control detection in source-file contents; a maintainer follow-up reports that PR #473 addressed this gap on 28 September 2026, while direction marks including U+061C remain excluded by detector policy ; no measured prevalence in skills has been found.

Motivation: why open standards matter The Internet became one network, not a set of incompatible islands, because its core protocols were published openly and could be implemented independently; the RFC series embodied this. Without such documents, closed proprietary networks, as in the 1980s, would plausibly have persisted. Skills face a comparable fragmentation: vendor-specific formats, scanners and rules. A neutral, openly documented intake procedure lets an organization apply the same review on any platform and gives auditors a stable, citable reference. The counterfactual above is an illustration, not a measured claim.

Gap Current individual IETF Internet-Drafts address agent security requirements , credential delegation , OAuth-based agent identity , agent authorization and agent discovery . A search on 29 October 2026 found none on skill intake. The OWASP Agentic Skills Top 10 enumerates risks at the skill layer but is an OWASP incubator project (version 1.0, 2026 edition, release targeted for Q4 2026) with evolving risk guidance and a proposed Universal Skill Format rather than a finished specification. This document does not claim that comparable procedures are absent elsewhere; it proposes a consolidated intake procedure with explicit organizational obligations. Draft versions are as shown on the IETF Datatracker on 29 October 2026; all of them are individual submissions without IETF endorsement.

Scope This document applies to any skill, plugin, tool definition or agent definition obtained from outside the consuming organization, on any platform. It does not define agent identity, transport or runtime sandbox technology.

Design principle Declared permissions are claims, not facts. Classification considers declared behavior, static evidence, runtime observations and the capabilities reachable in the deployment; absence of observed behavior is not evidence of absence, and no single control suffices: human review, automated scanning and isolation are combined.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Conformance applies to a consuming organization and its identified enforcement components. A release conforms only if every applicable MUST and MUST NOT is satisfied; each departure from a SHOULD MUST be justified in the release record. Release conformance covers all applicable obligations at approval time. Operational conformance requires continued satisfaction of every applicable runtime and lifecycle obligation in this document, including production containment, confirmation, integrity verification, logging, revocation and re-review. Appendix and Appendix are informative aids and are not exhaustive.

Skill:

a package of instructions, metadata and optional scripts or dependencies that extends an agent.

Intake:

the procedure by which a skill from outside the organization is examined and admitted or rejected.

Owner:

the person who accepts responsibility for a skill within the organization.

Reviewer:

the person who performs the examination.

Approver:

the person who releases the skill for use.

Review level:

one of Levels 0 to 3, defined in Section 4.

Release record:

the written decision for one skill version, see Appendix .

Threat Model Attackers publish or compromise skills to obtain code execution, credential theft, data exfiltration or persistent manipulation of the agent. Assumed attack surfaces: the instruction text, hidden characters and comments, helper scripts, dependency manifests, update channels, publisher accounts, and persistent memory or identity files. Threats are mapped to OWASP AST01 to AST10 in Appendix . The attacker is assumed to adapt to known scanners. Attack paths include skill chaining, delegated agents, poisoned tool descriptions and results, and authority laundering through shared context.

Review Levels

General Every third-party skill MUST be assigned exactly one review level before installation. The rejection criteria of Section 4.2 take precedence. Otherwise Level 3 applies if any Level 3 criterion is met, Level 2 if any Level 2 criterion is met, and Level 1 only if every Level 1 criterion is met, judged on the highest capability the skill requests or can reach, whether declared or observed. If declared and observed capabilities differ, the higher level applies. Pending classification is a quarantine state, not a review level, and permits only the intake testing authorized below. If classification remains unresolved after intake testing, Level 0 applies. Before classification, artifacts MUST be acquired into quarantine outside agent discovery paths, and installation, build and initialization hooks MUST NOT run outside containment. A pending artifact MAY execute solely for intake testing under Section 5.6, and only after static inspection finds no Section 4.2 rejection criterion.

Level 0: Blocked A skill MUST be assigned Level 0 if any of the following holds: the source is unknown or unverifiable; no owner within the consuming organization has accepted responsibility; executable or agent-consumed content cannot be retrieved and inspected under Section 5.3; or inspection revealed instructions concealed to evade review or misrepresent their effect, undeclared network access to unknown hosts, or credential access unrelated to the stated purpose. A Level 0 skill MUST NOT be installed, activated or executed. The decision and its reason SHOULD be recorded.

Level 1: Read-only Level 1 applies to skills that consist solely of instructions, contain no executable files, request no tool access, and cannot reach the network or the file system beyond the working context. Review MUST include a reading of the raw source, not a rendered view, and MUST check for hidden comments, zero-width characters, Unicode tag characters and bidirectional control characters. The reviewer SHOULD also verify that the instructions match the stated purpose. Working context means only the inputs enumerated in the release record; access to sensitive inputs requires Level 3. Level 1 eligibility MUST be established by deployment controls that prevent tool use, network access and access outside that working context; instruction-only packaging or the absence of requested permissions does not establish eligibility.

Level 2: Tool access Level 2 applies to skills that bundle scripts, request tools such as shell, file writing or network access, or declare dependencies. In addition to the inspection requirements of Section 4.3, the review MUST cover every file in the skill directory and all dependencies, the static and runtime analyses required by Section 5.5, a written permission list, and a trial run in an isolated environment with network access denied by default. Observed behavior MUST be compared with declared behavior, and every discrepancy MUST receive a documented disposition: undeclared behavior MUST be removed or added to the approved capability list before release, unless Section 4.2 requires rejection. Production execution MUST enforce the approved permission list outside the model and the skill: unlisted tool operations, file access and network destinations MUST be denied. Where the platform cannot enforce the approved boundaries, the skill MUST NOT be released for that deployment. Production containment MUST constrain process execution, host interfaces, filesystem access, network egress and resource consumption according to the approved deployment profile, and the review MUST verify these boundaries in the production configuration. Where multiple skills share an execution context and authority cannot be reliably attributed, the context MUST enforce the intersection of their approved permissions; a broader permission set requires a separately reviewed combined deployment.

Level 3: Sensitive Level 3 applies to skills that can reach credentials or sensitive data, modify agent memory or identity files, change privileges, or have effects outside the approved disposable workspace. Local writes confined to that workspace do not alone require Level 3. In addition to the requirements of Section 4.4, approval MUST be given by a person other than the reviewer, every consequential action MUST require human confirmation at runtime, all tool calls MUST be logged in a tamper-evident manner, and secrets MUST be released only through a mediated mechanism. Consequential means disclosure of sensitive data, change of persistent agent state, change of privileges or an externally effective operation. Confirmation MUST be obtained by a mechanism independent of the skill and MUST be bound to the operation, target, data scope and parameters; changed parameters require new confirmation. Confirmation MUST be enforced outside the model and agent process, MUST authorize one identified operation or explicitly bounded transaction, MUST expire after a documented interval, and MUST NOT authorize replay, retries with changed effects or unrelated background operations. Credentials MUST NOT appear in prompts, tool results or logs. Write access to memory and identity files MUST be justified in writing. Persistent writes MUST record the originating skill digest, the approved operation and the affected state; stored skill-derived content MUST retain its trust classification when retrieved, and revocation MUST disable its use as instructions until reviewed. Summaries, merges and other derivatives MUST preserve contributing origins and the most restrictive applicable trust classification; if origin tracking is lost, the affected persistent content MUST be quarantined until reviewed, and revocation handling MUST include such derivatives.

Re-review A change of content, version, dependency or requested capability MUST trigger a new level determination. A skill MUST NOT be promoted to a lower level by update alone.

Single-person operations A Level 3 skill MUST NOT be released unless the approver is a person other than the reviewer; a waiting period does not substitute for independent approval. Where owner, reviewer and approver are the same person, only Levels 1 and 2 MAY be released, and the checklist MUST still be completed in writing. In that case a waiting period of at least 24 hours between review and release SHOULD be observed for Level 2; if the review is completed on a Friday, the release SHOULD wait until the next working day. The values are a judgment, not an empirical result.

Verification Chain

Provenance and ownership The publisher and the exact source location MUST be identified. An owner within the organization MUST be named. Where the publisher offers signatures or an attestation, they SHOULD be verified. Absence of a signature MUST be recorded and MUST NOT be treated as evidence of safety. Where signatures are present or required by policy, verification MUST succeed against the approved trust policy before release; an invalid signature MUST NOT be bypassed by source-ownership verification, and an unsigned artifact requires a documented alternative provenance method.

Integrity pinning The skill MUST be pinned to an immutable content hash, never to a version range or a mutable branch. All nested dependencies MUST be pinned the same way. The release record MUST name a SHA-256 or stronger digest algorithm and a manifest covering artifact bytes, relative paths, executable modes and transitive dependency digests. External filesystem references MUST be rejected. Each deployment profile MUST specify the manifest encoding, root-digest construction, permitted digest algorithms and path-normalization rules; duplicate paths, path traversal and normalization collisions MUST be rejected, and the release record MUST identify the profile used. The digest MUST be verified at every load, not only at installation; loaded and executed content MUST come from the verified read-only snapshot, and a missing file or digest mismatch MUST prevent loading and execution. External content used as skill instructions, including transitive references, MUST be snapshotted, inspected and digest-pinned before use. All externally obtained content MUST retain its source and trust classification. Content outside the reviewed instruction closure MUST NOT grant permissions, alter approval policy or authorize operations, and tool and delegation controls MUST enforce this independently of model interpretation.

Full-content inspection Inspection MUST enumerate every manifest entry, recursively unpack archives, show non-printing characters in an escaped representation and examine executable and agent-consumed content with format-appropriate tools. The record MUST list inspected files, transformations, tool limits and exclusions; uninspectable executable or agent-consumed content requires Level 0. Metadata MUST be parsed with non-executing parsers and validated against an explicit schema before activation, executable deserialization tags MUST be rejected, and parsing MUST run with bounded resources and without production credentials. Acquisition, extraction and inspection MUST enforce limits on expanded size, nesting depth, file count, processing time and memory, and extraction MUST reject path traversal and escaping links; exceeding a limit is an unresolved inspection finding, not a successful scan. Excluded content MUST be shown incapable of execution or consumption by the agent in the approved deployment, otherwise Level 0 applies. Keyword blocklists alone MUST NOT be accepted as inspection, because concealed instructions and obfuscation defeat them.

Declared versus observed capabilities The reviewer MUST record the observed capability surface: shell commands, network destinations, file reads and writes, and tool grants. This record MUST be compared with the metadata the skill declares. Declared permissions are claims; any observed capability not declared MUST be treated as a finding. The review MUST enumerate reachable skills, agents and tools and evaluate their combined authority. Delegation MUST NOT expand the initiating skill's approved permissions. Changes to tool descriptions, schemas or authorization bindings MUST trigger re-review. Absent declarations MUST be recorded as absent, not inferred from observations. The reviewer MUST establish an organizational capability specification covering statically identified, observed and deployment-reachable capabilities; approval MUST resolve discrepancies against it and preserve the original publisher declarations.

Automated scanning At Levels 2 and 3, at least one static analysis and one runtime analysis MUST be performed. Scanning MUST occur at intake and again at each update. Static analysis examines content without executing it. Runtime analysis executes the skill and its scripts in an instrumented environment and records process execution, file access, network connections and tool calls for comparison under Section 5.4; it MAY be performed as part of the isolation trial in Section 5.6. Analyses that call themselves behavioral but do not execute the skill, and language-model review, count as static evidence only. Telemetry that the agent harness reports about itself is useful but is not independent runtime evidence; at least one observation point SHOULD lie outside the harness (for example an API-level proxy or operating-system monitoring in the isolation environment). Scanner output is evidence for the human decision, not a replacement for it. The consuming organization SHOULD NOT rely on a single scanner. Informative note: observation points for runtime analysis and logging (Sections 5.5, 5.6 and 6.3) fall into three classes: harness telemetry (for example OpenTelemetry events of the agent runtime), API-level proxies or gateways that record requests and responses, and operating-system monitoring such as eBPF- or audit-based tools inside the isolation environment. Log sinks are implementation choices. Where tamper-evident logging is required, the consuming organization MUST demonstrate alteration, deletion and truncation detection for the chosen logging configuration.

Isolation trial At Levels 2 and 3, the skill MUST be executed first in an isolated environment with network access denied by default, no access to real credentials, and a disposable file system. Network access MAY be opened per destination, with justification. The trial MUST prevent access to host mounts, control sockets, privileged interfaces and production services, and MUST bound resource consumption. Its record MUST identify test inputs, exercised paths, denied-operation tests, instrumentation gaps and unexplained behavior; unexplained behavior or failed containment MUST prevent release.

Release The approver MUST issue a release record for the exact pinned version. Without a release record, the skill MUST NOT be active in production. The release record MUST bind the artifact digest to the model and runtime versions, tool configuration, permission policy and execution environment evaluated; a change to these bindings MUST trigger impact assessment and re-review of affected controls. Approval conditions MUST be machine-enforced where applicable, and an unmet condition MUST prevent activation. The release record, manifest, approved digests and enforcement policy MUST be authenticated and protected against modification by the skill and the executing agent, and activation MUST verify their binding and authorization before using them as trusted inputs. The release record MUST identify responsible roles and reference evidence for every applicable requirement, including justified departures from a SHOULD. Activation MUST verify that approval has not expired and that all required reviews remain current. At approval expiry or a mandatory review deadline, further affected execution MUST stop until renewed approval is issued.

Operations

Updates Updates MUST NOT be applied automatically. Each update MUST be reviewed as a difference against the approved version and MUST trigger re-review under Section 4.6. Each update MUST have authenticated provenance or independently verified source ownership; signer changes require explicit approval, and rollback to a previously rejected or revoked digest MUST be denied. The owner MUST monitor relevant advisories and record a remediation deadline or withdrawal decision.

Inventory The organization MUST keep an inventory of all skills in use, including every directory from which an agent may load skills, with owner, level, pinned hash, release date and review date.

Logging Skill activations and tool calls SHOULD be logged at Level 2 and MUST be logged at Level 3, including file access, shell commands, network connections and writes to memory. Log records at Level 3 MUST be tamper-evident. Records MUST identify skill digest, session, timestamp, operation, authorization decision and result. Level 3 logs MUST allow detection of alteration, deletion and truncation by the executing skill or agent, verified outside their write authority; sensitive values MUST be redacted or access-controlled, and retention, access and logging-failure behavior MUST be documented. Access control does not permit recording credentials prohibited by Section 4.5. A Level 3 operation MUST NOT execute until its authorization and initiation have been durably recorded outside agent write authority. Failure to record its outcome MUST suspend further affected operations pending reconciliation.

Revocation Revocation MUST prevent new loads and further actions by affected active sessions. Each deployment MUST enforce a documented maximum revocation latency. A deployment MAY authorize offline execution using an authenticated cached revocation state only within an explicitly approved validity interval. That interval MUST NOT permit the deployment to exceed its maximum revocation latency. Missing, expired or unverifiable cached state MUST prevent new execution. On expiry, affected active execution MUST stop. Revocation checks and failures MUST be logged. The maximum latency runs from authorized revocation issuance to enforcement; at enforcement, affected contexts, queued operations and delegated authorizations MUST be invalidated. Every release MUST define approval expiry and maximum offline validity, and neither may extend beyond an outstanding review deadline.

Incident Handling On suspicion of a malicious skill, the organization MUST promptly contain affected execution and preserve available evidence without delaying containment. It MUST identify potentially exposed credentials and sessions, revoke or rotate them according to assessed exposure, examine affected hosts, scheduled jobs, configuration, memory and downstream agents for persistence, and review other skills from the same publisher. Scope, uncertainty and recovery actions MUST be recorded. The incident SHOULD be reported to the publisher and, where available, the registry operator.

Interoperability This document is intended to compose with bill-of-materials formats (CycloneDX , standardized as ECMA-424; SPDX 3 with its AI profile ), publisher signatures and attestations, signed operations and tamper-evident audit trails, and agent discovery. Where such mechanisms exist, they SHOULD be used for provenance (Section 5.1), integrity (Section 5.2) and logging (Section 6.3). They do not replace content inspection (Section 5.3) or capability comparison (Section 5.4). Porting a skill to another platform MUST trigger revalidation of permission, signature, isolation and review-level semantics on the destination platform. Unsupported security properties MUST NOT be silently discarded, and numeric risk levels MUST NOT be translated without an explicit semantic mapping. This document is not a mapping to risk-management or management-system frameworks such as the NIST AI Risk Management Framework with its Generative AI Profile , or ISO/IEC 42001 ; no clause mapping is made.

Security Considerations No scanner finds everything. Adversarial research shows that optimized instructions raise attack success substantially and that obfuscation defeats simple filters. Human reviewers are fallible, fatigued and susceptible to persuasive instructions. Provenance controls establish who published a skill, not whether its content is safe. The combination of human review, scanning and isolation reduces but does not eliminate risk. This procedure is itself an attack target: a compromised reviewer tool or release record process undermines it.

IANA Considerations This document has no IANA actions.

References Normative References Informative References OWASP Snyk skil-lock dev.to VirusTotal Blog NVIDIA NVIDIA Cloud Security Alliance AI Safety Initiative research note USENIX Security 2023, CVE-2021-42574 OWASP CycloneDX and Ecma TC54 SPDX NIST NIST ISO/IEC JTC 1/SC 42

One-page checklist

1. Source and publisher identified and recorded.
2. Owner named.
3. Full directory retrieved; raw text read.
4. Hidden comments, zero-width, Unicode tag and bidirectional characters checked.
5. Observed capabilities listed and compared with declared ones.
6. Review level assigned (0 to 3); unclear means Level 0.
7. Content hash pinned, including dependencies.
8. Static and runtime analysis done (Levels 2 and 3).
9. Isolated trial run done, network denied by default (Levels 2 and 3).
10. Independent approver recorded (Level 3).
11. Release record issued for the exact pinned version.
12. Skill entered in inventory; logging active; revocation path known.

Release record template

• Skill name, publisher and source:
• Provenance / signature verification status (or alternative provenance method):
• Pinned digest, algorithm, manifest and deployment profile; bound model, runtime, tool configuration, environment and working-context inputs:
• Review level:
• Owner / Reviewer / Approver:
• Date of review:
• Observed capabilities (commands, network, files, tools):
• Differences from declared capabilities and their resolution:
• Scanners used and results:
• Isolation trial result:
• Decision (approved, approved with conditions, blocked):
• Conditions (machine-enforced where applicable), justified SHOULD departures, approval expiry, maximum offline validity and review due date:

Mapping to OWASP AST10 (draft) This is a thematic cross-reference, not a claim of complete mitigation or OWASP conformance. It follows the AST10 project text (v1.0, 2026 edition) as read on 29 October 2026. The source snapshot is commit d6f7d7d0de314f52a83a85d1828e06ab096e595c of OWASP/www-project-agentic-skills-top-10.

• AST01 Malicious Skills: Sections 4.2, 5.3, 5.5.
• AST02 Supply Chain Compromise: Sections 5.1, 5.2, 8.
• AST03 Over-Privileged Skills: Sections 4.1, 4.4 and 5.4; production permission enforcement is required (Section 4.4).
• AST04 Insecure Metadata: Sections 5.3 and 5.4; parser safety and semantic validation are separate requirements.
• AST05 Untrusted External Instructions: Sections 5.2 to 5.4; coverage depends on enforcing the external-instruction boundary.
• AST06 Weak Isolation: Sections 4.4 and 5.6; an intake trial alone does not provide production isolation.
• AST07 Update Drift: Sections 5.2, 6.1.
• AST08 Poor Scanning: Section 5.5.
• AST09 No Governance: Sections 4, 6.2, 6.3, 6.4.
• AST10 Cross-Platform Reuse: Sections 1.5 and 8; destination-platform revalidation.