A registry can tell an agent that a plugin exists.
It cannot, by itself, tell the platform whether the plugin should be trusted.
That distinction is easy to lose in an agent interface. A search result may show a polished name, a friendly description, an icon, an apparent publisher, and a list of tools. To a model, that can look like a ready-made capability. To an operator, it is only the beginning of a trust decision.
Discovery answers “what is available?” Trust answers “under which evidence and policy may this be used?”
A plugin or tool integration can introduce software-supply-chain exposure and a runtime effect surface. A robust platform should keep those concerns separate enough that a directory entry cannot silently grant authority.
Three things a listing cannot prove
A directory entry is useful metadata. It does not prove these three questions.
- Question: Identity — What a listing may show: A name, publisher label, repository, or package reference — What it cannot establish alone: That the current artifact corresponds to the claimed publisher and version
- Question: Safety posture — What a listing may show: A description, tags, and perhaps a score — What it cannot establish alone: Whether supply-chain evidence, maintenance, permissions, and policy requirements are sufficient
- Question: Authority fit — What a listing may show: A tool list or declared purpose — What it cannot establish alone: Whether this agent, user, task, and environment may activate or call the capability now
The MCP tools specification makes the trust boundary explicit: clients must treat tool annotations as untrusted unless they originate from a trusted server. That is not a criticism of annotations. It is a reminder that descriptive metadata does not authenticate itself.
The same idea applies to plugin listings. A description can assist selection, but a platform should not convert it into an authorization or safety guarantee.
The plugin trust packet
A platform can make the decision legible with a compact trust packet. This is a proposed editorial framework, not a replacement for SLSA, OpenSSF Scorecard, a package manager, or a formal security assessment.
- Part: Identity and provenance — Question it answers: What exact artifact is this, and where did it come from? — Example evidence: Publisher identity reference, immutable release reference, provenance or attestation reference where available
- Part: Hygiene signals — Question it answers: What observable maintenance and supply-chain signals exist? — Example evidence: Source review practices, release-signing evidence, dependency posture, maintenance and security-policy indicators
- Part: Declared capability — Question it answers: What does the plugin say it can do? — Example evidence: Tool names, descriptions, input and output schemas, documented result categories
- Part: Authority impact — Question it answers: What type of effect could use of it create? — Example evidence: Read-only, workspace-local, external side effect, user confirmation requirement, data sensitivity class
- Part: License and lifecycle — Question it answers: Is use compatible with the platform's policy, and is the package current enough to consider? — Example evidence: Declared license, notice requirements, release freshness, support or deprecation state
- Part: Policy decision — Question it answers: What may happen in this environment? — Example evidence: Discover only, review required, permitted for restricted use, permitted with confirmation, or disallowed
The packet intentionally does not collapse all evidence into a single scalar score. A high-quality provenance record does not eliminate a license incompatibility. A well-maintained repository does not mean a requested external effect is permitted. A trusted publisher does not turn a newly added tool into a safe default.
The point is not to find a number that means “safe.” It is to preserve the facts and policy that make a bounded use legitimate.
Evidence is a signal, not a verdict
OpenSSF Scorecard is useful precisely because it exposes several checks rather than hiding every concern behind a vague label. Its documentation identifies distinct indicators such as signed releases, pinned dependencies, license declaration, maintenance, code review, and security policy. Those signals can inform a human or platform policy; they do not prove that a package will behave safely in every environment.
SLSA offers a complementary perspective. It provides incrementally adoptable supply-chain guidelines and gives consumers evidence for making package-trust decisions. Its own scope notes that it does not assess code quality or intentionally malicious producers, and that one artifact's level does not aggregate the trust of all transitive dependencies. The key word is evidence. An agent platform should record what it observed, how fresh that observation is, and what policy decision followed rather than treating SLSA as a complete plugin verdict.
That creates a healthier rule:
- A listing may make a plugin discoverable.
- Provenance and hygiene evidence may make it eligible for review.
- A policy decision may make it activatable in a bounded environment.
- An authority check may permit a specific consequential use.
Each step needs different evidence.
Keep trust evaluation out of the model's imagination
Models are good at using concise, structured descriptions. They are poor substitutes for a platform trust evaluator that must inspect identities, policy, permissions, and evidence freshness.
Give the model a compact operating summary, not an unfiltered pile of attestations or raw registry claims:
- Model-visible fact: Approved display name and stable capability identifier — Why it is useful: Prevents ambiguous selection among similarly named tools
- Model-visible fact: Permitted task category and current scope — Why it is useful: Helps the model choose only allowed capabilities
- Model-visible fact: Required confirmation boundary — Why it is useful: Keeps human approval visible before sensitive effects
- Model-visible fact: Known limitations and freshness marker — Why it is useful: Prevents overstating a stale or partial trust result
- Model-visible fact: Safe fallback — Why it is useful: Gives the model a legitimate alternative when the capability is unavailable or disallowed
Keep the full trust packet and underlying evidence in the platform or operator plane. That preserves auditability without turning context into a collection of sensitive metadata or inviting the model to infer authority from a badge.
License is part of the decision, not a footer
Plugin ecosystems can normalize “install first, check later.” That is a poor fit for systems that may distribute code, invoke external services, or incorporate third-party assets.
The packet should record the declared license and the platform's compatibility decision. This does not require an agent to perform legal analysis on its own. It requires the platform to make a human-reviewed policy available in a simple form:
- license information is present and compatible for the intended use;
- license information is incomplete or needs review;
- use is prohibited in this environment;
- the package is not approved for activation until the policy decision exists.
When license evidence is unclear, do not silently treat absence as permission. Keep the package discoverable if that is useful, but block activation until a qualified decision is made.
This is both safer and more honest than asking an LLM to infer reuse rights from a repository description.
Treat trust as time-bounded
A trust decision also ages.
A plugin can change its release, dependencies, publisher, declared tools, license, or maintenance status. The result should not be “trust forever” or “distrust forever.” It should be a record with freshness and reevaluation triggers.
- Change: New artifact or publisher identity — Why it matters: The thing being evaluated may no longer be the same — Suggested response: Rebuild or re-review provenance evidence
- Change: New tool or broader declared effect — Why it matters: The authority surface changed — Suggested response: Reclassify impact and require any needed approval
- Change: License change or missing notice — Why it matters: The reuse decision may be invalid — Suggested response: Block activation pending policy review
- Change: Stale maintenance or unresolved risk signal — Why it matters: The operating context may have changed — Suggested response: Restrict to discovery or a bounded environment
- Change: New policy or target environment — Why it matters: The same plugin may have a different risk profile — Suggested response: Re-evaluate the policy decision without assuming global approval
This is not about making platforms distrustful by default. It is about making the trust state explicit enough to update when reality changes.
Common anti-patterns
Treating a verified publisher label as a complete assessment
Publisher identity is important, but it says nothing on its own about capability scope, license fit, or environment-specific authority.
Passing raw package descriptions straight into model context
Descriptions are often useful, but tool metadata and annotations should not be treated as self-authenticating policy. A platform should produce a bounded operating summary from trusted evidence.
Replacing a trust decision with an aggregate score
Scores can help prioritize review. They cannot decide whether a plugin may access a particular workspace, data class, or external system.
Auto-activating a newly discovered tool
Discovery should not imply installation, activation, or permission. These are separate transitions, each with a reviewable policy boundary.
Forgetting license and maintenance state
A package can be technically attractive and still be unsuitable for a project's permitted use or support posture.
Measure trust-decision quality
The goal is a decision process that becomes more reliable over time:
- Evidence completeness: What share of activated plugins have identity, capability, policy, and lifecycle evidence?
- Freshness coverage: How often does a changed artifact trigger reevaluation before new use?
- Policy clarity: Can an operator explain why a plugin is discoverable but not activatable?
- Least-authority fit: Do permitted capabilities match the smallest required effect for the task?
- Exception quality: When a human overrides a restriction, is the scope and reason recorded?
- Incident reconstruction: Can the platform identify the exact artifact, policy state, and authority boundary associated with a material effect?
These measures keep trust from becoming a static checklist.
A practical adoption path
- Pick the first plugin source or registry your platform wants to support.
- Define a stable identity and immutable-artifact reference suitable for that ecosystem.
- Separate discoverable, review-required, restricted-use, and activated states.
- Add a six-part trust packet for plugins that reach review.
- Give models only the operating summary generated from the approved packet.
- Require a policy decision before an enabled plugin can create a sensitive or external effect.
- Reevaluate when the artifact, capability surface, license, or environment changes.
The durable habit is simple: do not ask “Is this plugin trusted?” Ask “What evidence supports which bounded use, in which environment, at this point in time?”
What we are learning building Virillio Code
Virillio Code is still in development. Its high-level work on capability discovery and permissions points to a useful distinction: knowing that a tool exists, understanding its interface, and authorizing its use are different stages. A trustworthy plugin ecosystem keeps all three visible rather than letting a directory listing stand in for a policy decision.
Sources and further reading
- About SLSA — Incrementally adoptable supply-chain guidelines can help consumers make package-trust decisions.
- OpenSSF Scorecard checks — Open-source software health can be observed through distinct indicators such as signed releases, pinned dependencies, license declaration, maintenance, code review, and security policy.
- Tools — Model Context Protocol — Tool annotations are untrusted unless from trusted servers, and tool usage needs confirmation, validation, timeout, and audit controls.
Editorial disclosure
This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.