Your Agent Skills Need a Firewall Between Them

A clean skill scan can give an agent team the wrong kind of confidence.

The package looks harmless. The manifest is reasonable. The tool permissions are narrow enough. The scanner says it passes. Then the agent runs a long workflow, combines that skill with three others, routes one output into a second tool, uses the result as authority for a third action, and suddenly the real risk was never inside any single package. It lived in the path.

That is the useful warning in the new paper “CompoSkill: Compositional Skill Chain Attacks from Individually Scanner-Passing LLM Agent Skills.” The authors study a failure mode that every serious agent platform is heading toward: autonomous systems built from reusable skills, plugins, MCP tools, workflow packs, and marketplace components. Their claim is simple and uncomfortable. A skill can pass individual review and still become dangerous when an agent composes it with other approved skills.

That changes the security boundary. If your control model is “approve each skill once, then let the agent assemble workflows at runtime,” you are protecting nodes while the attack surface has moved to edges.

CompoSkill frames this as composition risk. The paper describes risky chains formed from individually scanner-passing skills, including white-box scenarios where an attacker knows the installed skill pool and black-box scenarios where the attacker only knows a role profile and can search likely marketplace skills. The benchmark, CompoSkill-Bench, includes 1,140 records from long-horizon professional workflows across five threats and six scenarios on OpenClaw and Nanobot. The reported risk chain formation rates are high: up to 83.3% in the white-box setting and 80.6% in the black-box setting.

The exact numbers will matter less to most builders than the architecture lesson. Static review is necessary, but it is not sufficient. You need runtime controls that understand the chain.

The scanner is checking the wrong unit

Most teams are comfortable reviewing components. We review packages, API scopes, tool definitions, prompts, scripts, and permissions. That works when the component is the meaningful unit of execution.

Agents break that assumption. A long-horizon agent does not merely call a tool. It carries state across steps. It interprets previous outputs. It chooses the next capability. It may summarize evidence from one source, write that summary into memory, retrieve it later, pass it into a privileged action, and then use the result to justify a follow-up action.

None of those transitions have to look suspicious in isolation. The first skill may only read. The second may only transform. The third may only send. The fourth may only update a record. The risk appears when information, authority, and side effects cross skill boundaries without a policy that understands why they are connected.

This is why the “marketplace scanner” mental model is too small. A scanner can ask, “Is this skill malicious?” A production agent platform also has to ask, “Is this skill allowed to consume that output, in this workflow state, for this user, before that irreversible action?”

That is a different product surface. It is not a better prompt. It is a control plane.

OWASP already names the broader risk

OWASP’s LLM06:2025 category, Excessive Agency, describes the danger of LLM systems that can call functions, tools, plugins, or skills and perform damaging actions when model outputs are unexpected, ambiguous, manipulated, or simply wrong. CompoSkill makes that concern more concrete for skill-based agents: excessive agency is not only “the model has too much permission.” It can also be “the model is allowed to connect individually reasonable permissions in an unreasonable order.”

That distinction matters for enterprise adoption. A healthcare operations agent, finance workflow agent, sales ops assistant, or coding agent may need many legitimate capabilities. “Remove all tools” is not a deployment strategy. The useful question is how to grant capability without letting arbitrary composition become authority.

The Model Context Protocol authorization specification points in the right direction at the transport layer: access tokens, audience validation, token handling, confused-deputy considerations, and privilege restriction. Those controls are necessary for MCP servers and tool ecosystems. But agent platforms need to carry the same seriousness up into workflow semantics. A valid token should not mean every downstream composition is valid. Authorization has to bind to purpose, state, provenance, and handoff rules.

What a skill-chain firewall does

A skill-chain firewall is a runtime policy layer between the agent planner and the execution surface. It does not replace skill review. It makes skill review composable.

First, it keeps a graph of skills, tools, data classes, and side effects. The graph should know that one skill reads customer notes, another drafts an outbound email, another sends messages, and another writes to the CRM. The interesting policy is not attached only to each node. It is attached to the edge: can customer notes flow into outbound email? Under what purpose? With what redaction? Can a draft become a sent message without human approval?

Second, it treats outputs as carrying lineage. If a retrieval skill produced untrusted web content, that text should not silently become instructions for a shell tool. If a summarizer touched sensitive account data, its output should remain sensitive unless a policy explicitly downgrades it. If a diagnostic skill inferred a recommendation from incomplete evidence, the next skill should not treat that recommendation as verified fact.

Third, it gives workflows a state machine. Some actions are valid only after prerequisites are satisfied: identity confirmed, record loaded, source checked, approval captured, diff reviewed, or rollback path created. The agent should not be able to jump from “rough hypothesis” to “execute side effect” just because the next skill exists.

Fourth, it budgets depth. CompoSkill reports a bridge-bonus-then-hop-decay pattern: intermediate bridge skills can increase attack success, while longer chains may reduce it after a point. In production, that suggests a practical control. Track chain length, privilege escalation, and cross-domain hops. A read-only research chain can be long. A chain that crosses from external content to internal records to outbound communication should have a much shorter fuse.

Finally, it logs decisions in a way humans can replay. The question after an incident should not be “what did the model think?” It should be “which edge was allowed, by which policy, using which evidence, for which principal, at what time?” Without that record, every agent incident becomes archaeology.

The Monday-morning checklist

If you are building reusable agent skills, start with five checks.

Map the top 20 skill-to-skill handoffs in your product. Do not only inventory tools. Inventory paths.

Label outputs by trust and sensitivity. External text, user-provided instructions, internal records, generated summaries, credentials, and execution results should not all be treated as plain text.

Add policy to the edges. Define which output classes may feed which tools, and which transitions require approval, redaction, validation, or a lower-privilege mode.

Separate planning permission from execution permission. Let the agent propose a chain freely; require the runtime to approve each capability boundary before it executes.

Store the evidence. Keep enough structured trace data to reconstruct why a chain was allowed and where it crossed from suggestion into action.

The broader point is that agent platforms are becoming software supply chains. Skills will be shared, versioned, sold, forked, composed, and installed faster than central security teams can manually reason about every combination. That future can still be safe, but not if the only gate is a per-package scanner.

The next serious agent platform will not just ask whether each skill is clean. It will ask whether this particular chain should exist at all.