Protecting yourself from insecure skills

Inventory the skills running across your org, read their Snyk-powered security scores, and use install policies to block risky skills before they reach a developer.

Takeaways

• How to inventory the skills across your org and tell first-party skills from matched third-party ones.
• How Snyk-powered security scores surface on import, and how to review any skill on demand.
• How an admin sets org, workspace, or project install policies to block risky skills.

Skills run inside your agent with access to your code, your shell, and your secrets. A skill pulled from a public source can carry a prompt-injection payload or instructions that exfiltrate data, and the risk compounds once a skill spreads across repos. The danger is not only external: a first-party skill can leak credentials through an honest mistake by the developer who wrote it, or carry a deliberate payload from an insider. This tutorial maps what is already installed, reads each skill's security score, and gates future installs against a policy.

Inventory the skills across your org

Start from what is already running. tessl inventory import scans the repositories in a GitHub org through your local gh CLI and uploads the result to a workspace:

tessl inventory import --org your-org --workspace engteam

This relies on the GitHub CLI being installed and authenticated locally, and on being logged in to Tessl for the upload, so run gh auth login and tessl login before you import. For more on inventory, see Understand your skill estate.

The scan collects every SKILL.md and sorts what it finds. Skills that match a published registry skill are flagged as third-party; skills unique to your repos are your first-party skills, marked publishable, untracked, or unmanaged. It also surfaces overlap and drift between near-duplicate copies. Browse the result in the app at Workspaces → your workspace → Inventories. Use --repo to scope the scan, or --dry-run ./inventory.json to write it to disk without uploading.

Read the security scores

Security scores are powered by Snyk. Each score is a severity: LOW, MEDIUM, HIGH, or CRITICAL.

Third-party skills that match a published registry skill show their score in the inventory automatically. For your first-party skills, connect the Tessl GitHub App and import them; the import security-scans each one and brings its score into the inventory. Between the two, your whole skill estate ends up scored in one place. Sort the inventory by security score to find the skills that need attention first.

Review a single skill on demand

You do not need a full inventory to check one skill. Review any skill directly from its directory:

tessl review run security ./path-to-skill --workspace engteam

This is the quickest way to vet a skill before you install it, or to gate a skill in CI. The review is powered by Snyk and returns the same severities. Add --json for machine-readable output, or --fail-on high to make the command exit non-zero when a finding meets or exceeds a severity. The --fail-on values are lowercase: low, medium, high, critical.

Gate risky installs with a policy

An inventory and a score tell you what is risky. An install policy stops a risky skill from being installed at all. As a security admin, this is your main lever.

Policies can be set at three levels, and the tightest one wins:

• Org level: the broadest reach and your most impactful control as a security admin. It applies to every workspace and project in the org.
• Workspace level: tightens the org policy for a single workspace.
• Project level: tightens it further for a single project.

Set policy in the app under Settings → Policy. Setting org-level policy is an organization admin action, so if you do not see it, ask your admin. A policy combines three kinds of rule:

• Security threshold: choose the severity at which an install is warned and the severity at which it is blocked, for example warn at MEDIUM and block at HIGH.
• Source restriction: limit the registry to your own org, or to Tessl plus your org, and choose whether installs from git sources are allowed at all. When git sources are allowed, add a git source allowlist to permit only specific hosts and orgs, for example github.com/your-org, so developers can still install public skills from your trusted vendors while everything else is blocked.
• Minimum release age: for git sources, require a release to be a minimum number of days old before it can be installed.

Once a policy is in place, tessl install evaluates every source against it:

• A source under the warn threshold installs without interruption.
• A source that hits the warn threshold prompts for confirmation. A developer can proceed, or pass --accept-warnings to skip the prompt in automation.
• A source that hits the block threshold cannot be installed. There is no override.

tessl install your-org/some-skill

When the skill's score meets the block threshold, the install is refused and the offending finding is shown. The headline uses a severity label: Passed for LOW, Advisory for MEDIUM, Risky for HIGH, and Critical for CRITICAL. A Risky headline below therefore means a HIGH score that met the block threshold:

Blocked by install policy (not added to tessl.json):
  ✖ Security  Risky · Do not use without reviewing
    your-org/some-skill
    W011 Third-party content exposure detected.
    View full report: https://app.tessl.io/...

You can also set a publish policy that blocks publishing a skill whose security score is under a threshold, so risky skills never enter your registry in the first place. See Codifying and enforcing your company's skill standards.

Where to go next

• Understand your skill estate for more on inventory.
• Administrating organizations, workspaces, and roles to control who can install and publish.
• Codifying and enforcing your company's skill standards to extend governance from security to quality.