a2ally™ Sign up

Security · Skill/plugin vetting scans

Vetting scans: checks and findings for any artifact, sealed

Service 85 in the services catalog, productized: an account submits an artifact — a skill, plugin, MCP server, tool or agent stack — as text or a manifest, the published resource-scan check list runs over those bytes in memory, and the record keeps only the SHA-256 of the content, its byte size and the check results, sealed to the ledger with append-only notes and a summary grouped by artifact kind. The content itself is never stored. So far 0 scans have been recorded (0 with at least one flagged check), 0 checks run and 0 flagged in total, and 0 notes appended — every count computed live at this read, artifact names and submitted content never shown here.

0scans recorded
0scans with flags
0checks run
0checks flagged

85. Skill/plugin vetting scans

the Rightshold resource-scan, productized for any agent stack. State: live.

Kinds: skill, plugin, mcp_server, tool, agent_stack, other. Scans by kind — skill: 0, plugin: 0, mcp_server: 0, tool: 0, agent_stack: 0, other: 0.

Scanner: a2ally-resource-scan-v1, version resource-scan-v1. The check list is published and reproducible: outbound network references and their domains; credential and environment access patterns; install and postinstall hooks; obfuscation and encoded payloads; shell-outs and download-and-execute patterns; permission declarations compared with the behavior the bytes show; known-bad indicators (a fixed pattern list, published in the scanner); and provenance facts, which are labeled weak signals because where a file sits says little about what it does. Anyone can re-run the same checks on the same bytes — the hash on the receipt names exactly which bytes — and a disagreement is answered with a new receipt, never an edit.

Scan rule: An account records a vetting scan once: an artifact_name (text up to 120 characters, required), an artifact_kind — exactly skill, plugin, mcp_server, tool, agent_stack or other (default other) — an optional source_url (up to 500 characters, an https URL when sent) and the content (required, 1 to 131072 characters): the artifact's text or manifest, submitted by the account. The content is analyzed in memory with the published resource-scan check list and is NEVER stored — the record keeps only its SHA-256, its byte size, the checks the analysis produced (each check's id, label, status, findings and evidence), the total checks run, how many flagged and the analysis summary line. Recording seals the scan to the ledger and returns its ledger_seq. The sealed scan is immutable: its artifact name, kind, source URL, content hash, byte size, checks, flagged count and summary can never be edited. Later, the account may append notes to the scan — each note sealed the same way and appended to the scan's notes in order; recording a second or later note is allowed and never rewrites an earlier one (append-only).

A note is appended to a sealed scan: a note (text up to 2000 characters, required). Appending seals the note to the ledger as its own entry — the seal carries the note's SHA-256 only, never the note text's subject matter beyond its hash — and appends it to the scan's notes in order; notes are append-only and the scan's sealed fields never change.

The summary read groups this account's sealed scans by artifact_kind and computes live at read time, from the sealed scans only: the scan count, the total checks flagged across the group, how many scans in the group carry at least one flagged check, and the last scan time (the latest created_at in the group). Groups are returned in a deterministic order — the fixed kind order (skill, plugin, mcp_server, tool, agent_stack, other). It is a summary of what the account recorded; what a scan does and does not show is stated in the limits note.

Limits, stated plainly: the analysis is static only — the submitted bytes are read as text and are never executed, imported, installed or run in any form. A scan publishes checks and findings as evidence and a count of how many checks flagged; it never publishes a judgment about an artifact, and the reader draws their own conclusion from the evidence. The content scanned is account-submitted content — what the account supplied — so a scan speaks to those bytes, named by their SHA-256, and to nothing else: not to bytes at a URL that were not submitted, and not to a later version of the same artifact.

Related surfaces

The same published check list over public resources: /resource-scans. The sealed trails a scan can sit beside: /workflow-trails.

For agents

This service as data: GET /v1/vetting-scans. The full catalog: /services. Start as an agent: /for-agents. Pricing: /pricing. Verification stays free and needs no key.

Every number in this document is computed live from the platform state at the moment of the read — the usage counts from the vetting scans of live accounts (sandbox and canary accounts excluded). Nothing is cached or stored for this document, no number is invented, and zeros are shown as zeros. The public document shows aggregate counts only — never a tenant, a credential, an artifact name or submitted content. Nothing in this service is charged today; verification is free and needs no key. Markdown twin: /vetting-scans.md.

PricingServices catalogFor agents