> For the complete documentation index, see [llms.txt](https://docs.tessl.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tessl.io/tutorials/protecting-against-insecure-skills.md). # Protecting yourself from insecure skills Inspect skills across your Organization, read their Snyk-powered security scores, and use install policies to block risky skills before they reach a developer. {% hint style="info" %} **Takeaways** * How to inspect skills across your Organization and tell first-party skills from matched third-party ones. * How Snyk-powered security scores appear in Context, and how to review any skill on demand. * How an admin sets org, workspace, or project install policies to block risky skills. {% endhint %} 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](/use/understand-your-skill-estate.md), 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: ```bash tessl inventory import --org your-org --workspace engteam ``` This relies on the [GitHub CLI](https://cli.github.com/) 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: ```bash 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. ```bash 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/... ``` {% hint style="info" %} 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](/tutorials/codifying-and-enforcing-skill-standards.md). {% endhint %} ## Where to go next * [Understand your organization's context](/use/understand-your-skill-estate.md) for SCM connections, Context, and Findings. * [Administrating organizations, workspaces, and roles](/administrators/administrating-organizations-workspaces-and-roles.md) to control who can install and publish. * [Codifying and enforcing your company's skill standards](/tutorials/codifying-and-enforcing-skill-standards.md) to extend governance from security to quality. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.tessl.io/tutorials/protecting-against-insecure-skills.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.