---
type: "TechArticle"
softwareVersion: "1.0.0"
url: "https://registry.docsloth.dev/trust"
markdown: "https://registry.docsloth.dev/docs/trust.md"
route: "https://registry.docsloth.dev/trust"
catalog: "https://registry.docsloth.dev/catalog.json"
api: "https://registry.docsloth.dev/api/v1/index.json"
generator: "docsloth-registry/scripts/market-site.mjs"
---

> Index: [Agent index](https://registry.docsloth.dev/llms.txt)

# Trust and abuse

What a published package passed before it was hosted, what no check can promise, the signals you can verify yourself, and where to report a problem.

## Every hosted publish is machine-scanned before it is stored

A publish runs a deterministic, offline scan over the manifest and every payload byte before anything is stored. A blocking finding refuses the publish: nothing is stored, nothing is served, and the refusal names the file and line.

| Checked | What it refuses |
| --- | --- |
| Committed secrets | Private keys, API tokens, JWTs and bearer credentials in any file (blocking) |
| Injection surface | Script tags, inline event handlers, javascript:/vbscript: URLs, iframes, meta refresh and document-typed data: URLs (blocking) |
| Executable payloads | Executable extensions and executable magic bytes in a declarative package (blocking) |
| License policy | A license outside the allowlisted SPDX set or a safe `SEE LICENSE IN <path>` (blocking) |
| Dangerous examples | Download-pipe-to-shell, recursive root deletes, world-writable permissions and disabled certificate/hook verification in prose (advisory) |
| Binary payloads | Files carrying NUL/control bytes are still matched as text and reported, so a NUL byte is never a silent pass (advisory, visible in the package trust block) |

The registry and the CLI never execute package code: components are declarative payloads. `kind: plugin` packages are refused by default and install only behind an explicit operator trust policy plus `--allow-plugin`.

## What no scan promises

The publish scan is a bounded, deterministic check over bytes and the manifest. It is not a malware scanner, not a code audit and not a human review of the package's content, and a passing package carries no endorsement. The signals below are what you can verify yourself.

## Signals you can verify

| Signal | What it proves |
| --- | --- |
| Package digest | The manifest digest the registry pins; the index, the manifest and `docsloth component add` all recompute it |
| File digests | Each declared file's sha256; a mismatch, a missing file or an undeclared file is refused before anything is written |
| Publisher identity | `key_pinned` when the namespace was proven by a signed challenge, `verified_identity` when it was also proven by DNS; both are on every catalog entry |
| Trust class | What the package may do at runtime (pure, interactive, connected, agentic), derived from its declared capabilities, never from its prose |
| Review state | Whether the publishing organization recorded a decision for this version; no record means no review was recorded |
| Scan status | `passed` or `blocked` with finding counts and scan time in the catalog entry's `trust.security` block |

## Report a problem

Report abuse of a published package to maintainers@docsloth.dev. Include the package name and version, what you observed and any links; reports go to the registry operator, not to the package publisher, and a name+version can be pulled from the catalog while the report is investigated.

Security vulnerabilities in the registry software itself go through private vulnerability reporting on the [registry repository](https://github.com/rextail-ai/docsloth-registry).