#Protecting yourself from insecure 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.

#Find skills across your Organization

The primary path is to connect an SCM account, then open your Organization's Context page. Tessl scans the repositories in scope and shows the skills and configuration it observed.

You can also upload a GitHub scan through your local gh CLI:

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 first. The workspace selects the reporting Organization and checks your publishing access. Upload results remain owned by that workspace, so only people who can view the workspace can view those Context and Findings results. The upload does not establish SCM ownership and does not require an SCM connection.

Without --repo, the scan selects eligible repositories and scans up to the 100 most recently pushed. It does not provide complete repository coverage. Within the repositories it scans, it collects the SKILL.md files and manifests it finds. Skills that match a published registry skill are third-party; skills unique to your repositories are first-party. Open your Organization's Context page to browse the result and Findings to inspect reported issues. Use --repo to choose a specific subset, 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.

Indexing and security scoring run as separate background work after scan analysis. A skill can appear in Context before its security score is available, and not every skill is guaranteed to receive a score. Use the available scores and Findings to prioritize investigation, then run an on-demand review when you need a current result for one skill.

#Review a single skill on demand

You do not need an Organization scan 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

Context, Findings, and security scores help you identify risk. 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/...

#Where to go next

• Understand your organization's context for SCM connections, Context, and Findings.
• 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.