Skill security

Codenskills checks the exact package that will become Ready. A scan is not a label attached to a skill name: it is a trusted report bound to one version, one package hash and, in an organization workspace, one policy revision.

The release flow

1. Validate the package. Import requires SKILL.md with valid frontmatter, safe relative paths and bounded file sizes. Codenskills inventories the files but never executes package scripts during import or security review.
2. Create an immutable snapshot. When you submit a Workspace Draft, Codenskills hashes the normalized package. If any file changes later, that hash and its scan are no longer valid for release.
3. Run the built-in security assessment. The engine treats every instruction as untrusted data and checks seven areas: secrets exposure, prompt injection, unsafe execution, external access, dependency/package risk, data handling and permission boundaries.
4. Apply deterministic checks. Credential and private-key patterns are checked by server code and combined with the assessment. A model response cannot suppress those findings.
5. Evaluate organization criteria. Workspace criteria run as an independent pass against the same package snapshot. They may add findings or block release, but can never lower the built-in risk.
6. Record a trusted attestation. Only the Codenskills server can record the completed or failed scan. The result includes the package hash, risk, findings, policy snapshot and attestation version.
7. Apply the release gate. A version enters the human review queue only after the automated gate passes.
8. Re-check before Ready. The database verifies the same latest scan, package hash and attestation again when the version is released or approved.
9. Distribute only the Ready version. Connected agents still need an access grant. Installation uses a short-lived signed ZIP and checksum, and its manifest points back to the trusted report for that Ready package. Before scanning, the exact Draft author may privately test their own package; that exception is labelled Unreviewed, has no trusted report and is not governed distribution.

Risk outcomes

Result	Company Workspace release gate
Clean / Low	The version can enter human review.
Medium	The version can enter review; approval requires a reviewer note.
High / Critical	No review is created.
Scan failed	The version stays Draft and no review is created.

There is no owner/admin override for high or critical built-in risk or for a violated blocking organization criterion. Fix the reported package files, import the corrected version and scan it again.

What is inspected

Every package file is represented by its path, size, encoding and content hash. SKILL.md, scripts and normal text resources are prioritized for content inspection. Large base64 or machine-readable reference assets are inventoried and hashed instead of being expanded without limit; deterministic checks can still inspect stored content for obvious credential patterns.

The report groups findings by:

• secrets exposure;
• prompt injection;
• unsafe execution;
• external access;
• dependency and package risk;
• data handling; and
• permission boundaries.

Exact reports, not “latest” shortcuts

Open Security profile from the skill, pending review or version history to see the full report. Each link carries the exact scan id shown in that context; it does not silently switch to a newer report.

Changing a draft invalidates its package hash. Changing organization criteria creates a new immutable policy revision. A scan that races either change is rejected, and a new submission must scan the new snapshot. Once an organization review exists, it keeps the exact scan and policy revision that created it.

See Skills & versions for version states, Security policies for organization criteria and Connect agents for signed installation.