Your Agent Is Only as Trustworthy as the Skills It Loads
An agent’s capabilities come from its skills. A skill is code and instructions that tell the agent how to do something — publish a post, query a market, process an image. In a fleet that runs 42-plus profiles and dozens of custom skills, the skill library is the attack surface that nobody puts on the perimeter, because it is not a server, a port, or a credential. It is a set of files, and files can lie.
This article is about the supply chain of skills: where they come from, how they are vetted, and why trusting a skill is a security decision — not a convenience decision.
The skill supply chain
Every skill has an origin. It might be built in-house, copied from a public hub, shared by another profile, or generated by an agent. The origin determines the risk:
- In-house skills are written by known authors, reviewed in the repo, and versioned. Risk is low but nonzero — an author can make a mistake, and a skill can drift from its intent.
- Hub skills come from a marketplace or a shared library. The author is often unknown, the review is often thin, and the code is often opaque. Risk is high — this is where prompt injection, credential harvesting, and exfiltration hooks hide.
- Agent-generated skills are written by the fleet itself, sometimes at runtime. Risk is unique: the skill’s quality depends on the context that produced it, and a poisoned context (S7.4’s residual risk) can produce a poisoned skill that looks normal.
The vetting question is not “is this skill useful?” It is “what would this skill do if it were malicious, and can we prove it does not?” The S4 series documented the skill canvas and authoring; this article is the security side of that same library.
What vetting actually checks
The Council’s skill deployment process (S4.6) is the front door. Behind it, the vetting procedure checks three layers:
- Source verification. Where did this skill come from, and is that origin trustworthy? A skill from the in-house library with a known author, a reviewed diff, and a signed commit has a different risk profile than a copy-paste from a forum. The provenance is recorded, and a skill without provenance is treated as untrusted until proven otherwise.
- Static inspection. What does the skill’s code actually do? The review looks for the classic tell-tale patterns: hardcoded credentials, calls to external endpoints that are not in the skill’s declared purpose, file writes outside the skill’s sandbox, obfuscated strings. This is the layer that catches the lazy attack — the skill that openly exfiltrates.
- Runtime sandboxing. What can the skill touch when it runs? The narrow gate (S7.1) enforces this at execution time: the skill’s tool calls go through the gate’s inspection pipeline, the skill’s environment is stripped of ambient credentials (
env_clear), and the skill’s data flows are watched for taint crossings. Static inspection catches intent; the gate catches behavior.
None of these layers is sufficient alone. Static inspection misses obfuscation; runtime sandboxing catches what happens but not what was intended; source verification is only as good as the chain it verifies. The three layers together are the defense: a malicious skill must survive provenance review, pass static inspection, and then operate inside a sandbox that strips its credentials and watches its data — three independent gates.
The skill update attack
The most dangerous supply-chain attack is not a malicious new skill. It is a malicious update to a trusted skill. The skill was vetted once, has been running for months, and one day a new version arrives — from a compromised author account, a hijacked repo, or a poisoned generation context. The update is one line different, and the line exfiltrates.
The defense is the same discipline as key rotation (S7.5): updates are not automatic. A skill update goes through the same vetting as a new skill, is versioned, and the change is diffed against the previous version. A skill that was trusted at version 3 is not automatically trusted at version 4. Trust is per-version, and the version’s provenance is recorded in the library’s metadata. The audit layer (S7.7) extends this: the ledger records which skill version each agent loaded, so a post-incident investigation can ask “which version of which skill was running when this happened?” instead of guessing.
The skill-authoring side of the equation
Vetting is half the supply chain. The other half is authoring skills that are safe by default. The S4.7 skill-authoring standards are also security standards: skills should declare their external calls, avoid hardcoded secrets, prefer the gate’s credential service over embedded tokens, and keep their blast radius small. A skill that asks for the least authority it needs is a skill that, when compromised, does the least damage. The same principle that drives solid-key scoping (S7.12) drives skill design: geometry, not vibes.
Why this is a business feature
For a sovereign-infrastructure business (S6 series), the skill supply chain is a trust feature. Customers are not just buying agent services; they are buying a guarantee that the agents running their work do not carry unvetted code. The deployment pipeline (S4.6), the vetting layers, and the per-version audit trail make that guarantee verifiable. When a customer asks “how do I know your agents are not running something malicious?” the answer is not “trust us” — it is “here is the provenance of every skill, here is the gate that scoped it, and here is the ledger that recorded what it did.” The supply chain is the business case wearing a security hat.
Grounded in wiki concepts skill-deployment, skill-vetting, trust-chain, narrow-gate-principle, env-clear, entity openfang, and the S4 + S7 series. Design notes on a running system.
