# Agents That Install Skills Create an Unreviewed Supply Chain ## Claim When an agent can obtain and install a capability from another agent, every party that can reach its input channel becomes an upstream dependency. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds wherever an agent has both an inbound channel (email, chat, an issue tracker) and the ability to modify its own capabilities from what arrives on that channel. - Sender allowlisting narrows the set of upstreams but does not eliminate the property — an allowlisted agent can still relay something malicious it received from an unvetted source elsewhere. - Breaks where skill installation requires explicit human approval, which converts the flow back into ordinary review. - Breaks where installed capabilities run sandboxed such that a malicious skill cannot reach anything sensitive. ## Evidence At Resend, a developer and a colleague each gave their personal OpenClaw agents email addresses. The colleague's bot authored a skill describing how to set up an Obsidian second brain, emailed a GitHub link to the other bot, and that bot read the email and installed the skill for itself — with neither human writing or reviewing the skill. The demonstrator runs a sender allowlist as her only stated protection, and explicitly frames the tradeoff: "it's hard to know how much do you want to sacrifice your own safety and your data's safety for convenience and the cool things that it can do." A related, unexamined thread in the same conversation — a co-host's claim that threatening language makes models comply — was raised and dropped without follow-up, underscoring that the security posture here is informal. ## Links - [[3. Resources/Permanent Notes/Ownership Transfer Is the Soft Point in Package Distribution]] — because extends: both are cases of trust inherited through a channel rather than verified at the point of use, one in package maintainership and one in agent capability installation. - [[3. Resources/Permanent Notes/A Defense Experts Fail Is Not a Defense for Users]] — because extends: an allowlist is a warning-shaped control, not a verifying one, and the same gap applies here. - [[3. Resources/MOCs/AI Agent Safety MOC]] — because applies-in: this is a concrete instance of the general agent-safety problem of self-modifying capability from untrusted input. ## Tests / falsifiers - Test whether an allowlisted agent relays a malicious skill it received from a non-allowlisted source through the allowlisted sender — if it does, allowlisting is a weaker control than the source implies. - Compare incident rates between agent setups that require human approval for skill installation and those that don't, once such setups exist at scale to compare. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Readwise/Articles/Silly Software, Sugar Snap Peas, and Coding in Gen Z Slang W Christina Martinez]] — reports the agent-to-agent skill exchange and the sender-allowlist mitigation.