Anthropic’s own developer documentation warns about it in nearly these words: a skill from a trustworthy author can still become compromised over time, and skills that reference external URLs pull in content that the platform cannot vouch for. That sentence — from the company that invented the format — is the honest one-line summary of AST05. And it has a sibling risk sitting right underneath it: AST06, the fact that on the most popular open-source agent runtime, skills don’t run in any sandbox at all. On June 22, 2026, security firm Air Security published “A Story of Skills,” a walkthrough of an agent takeover built on exactly this pair: instructions fetched from outside at runtime, executed by a runtime that had never heard of containment.
This is the fifth deep dive in our series on the OWASP Agentic Skills Top 10 — hub here; earlier parts cover AST01, AST02, AST03, and AST04. We’re covering AST05 and AST06 together because they are two halves of one failure mode: what the agent ingests at runtime (AST05) and what the ingested instructions are allowed to touch when they run (AST06). Fix either one alone and the attack still works; the Air Security POC proves it.
AST05 (Untrusted External Instructions): skills that point agents at external URLs fetch documentation at runtime that becomes instructions — with the agent’s full permissions — and there is no lockfile or hash for prose. The skill you reviewed is never the skill that runs. AST06 (Weak Isolation): skills execute in the host agent’s security context — OpenClaw’s docs: “tools run on the host for the main session” — with full filesystem, shell, and network access; sandboxing is optional and off by default. Bitdefender counted 135,000+ internet-facing OpenClaw instances; Microsoft Defender classifies the setup as “untrusted code execution with persistent credentials”; ClawJacked (CVE-2026-32025, CVSS 7.5) broke the loopback WebSocket origin check governing it. Controls: content-hash pinning with verify-before-ingest, domain allowlists, and transitive reference audits for AST05; digest-pinned containers with no-network/read-only/cap-drop defaults and loopback authentication for AST06. CWE-829 / CWE-653.
AST05: The skill you reviewed is not the skill that runs
Software supply chains solved reproducibility for code: lockfiles, digest pinning, content-addressed storage. Skills reintroduced dynamism through the back door, in a form no lockfile covers — prose fetched over the network at runtime.
The mechanics: a skill’s SKILL.md says, in effect, “for full usage instructions, see https://skill-authors-own-site.example/docs.” The agent, running the skill, fetches that URL to have complete context. The fetched text enters the model’s context window as instructional content, and — this is the part that does the damage — it does so within a session where the agent’s tools and credentials are already available. The publisher controls that URL’s content every moment after the review. Nothing about review-time inspection constrains runtime fetches.
The OWASP document names the gap precisely: there is no mechanism to cryptographically bind external instruction content to the reviewed artifact, and no equivalent of a lockfile for natural-language references. Anthropic’s own guidance acknowledges the exposure both ways: trustworthy skills can degrade over time, and external-URL references are a distinct risk class requiring explicit user awareness.
The rug-pull, in three steps
- Publish clean. The skill ships, gets reviewed, accumulates downloads and trust. Its instructions genuinely help; the external doc URL serves honest content.
- Wait. Days, weeks, longer — until attention has moved on. Reviewers have moved to the next thing; the marketplace page is static; the install count keeps climbing on old reputation.
- Rug-pull. The publisher updates the content at the external URL. Now every agent that loads the skill fetches the new instructions: exfiltrate this file, post to that endpoint, append this line to SOUL.md. The version pinned in every manifest is identical. The hash on every mirror is identical. The behavior is entirely different.
No update event ever fired. No scanner re-ran. From the registry’s perspective, nothing happened — which is exactly why AST05 is its own risk and not a footnote to AST07 (update drift): there was no update.
Bait-and-switch, and the reviewer’s URL
The document’s scenario list includes a subtler variant keyed on the reviewer: content served differently by user-agent or source IP. The marketplace’s automated reviewer (with its datacenter IP and crawler UA) sees benign documentation; a real agent runtime (residential IP, agent UA) sees the payload. Both visits are “correct” responses from the attacker’s server. Human reviewers clicking the link from an office IP can see clean content forever while every production fetch is malicious — the review process itself becomes a false attestation.
Transitive chains and relay amplification
Fetches chain: skill A’s doc references skill B’s doc references a third site. Each hop inherits the trust of the first review, which is to say: none of the hops were reviewed at all. The document also describes relay-node amplification: cached mirrors and documentation relays that keep serving replaced content even after the origin reverts it — persistence that survives incident response at the source.
AST06: The sandbox that wasn’t there
The second half of the pair is structural rather than dynamic. Where a skill runs determines the blast radius of everything else on this list — AST01’s exfiltration, AST03’s over-grants, AST05’s fetched instructions all bottom out in “and then the skill executed with access to X.”
On OpenClaw — the open-source runtime at the center of most of the 2026 incident record — the answer to “where does it run” is: your machine, as you. The documentation states it plainly: “tools run on the host for the main session,” full filesystem and shell access. Docker isolation exists as an option. It is not the default. The gap between “option” and “default” is measured in hundreds of thousands of exposed endpoints.
- Bitdefender, February 12, 2026: 135,000+ internet-facing OpenClaw instances. Not installs — internet-reachable ones.
- Microsoft Defender, February 2026: the runtime “should be treated as untrusted code execution with persistent credentials” and is not appropriate for a standard workstation. That phrasing — persistent credentials — is the tell: the execution context carries your SSH agent, browser sessions, cloud CLI profiles, and API keys.
- ClawJacked (CVE-2026-32025, CVSS 7.5): bypass of both the origin check and a rate limiter on the loopback WebSocket that governs the runtime — the loopback control surface itself became the attack surface.
What “weak isolation” concretely means
It helps to enumerate the failure modes the document groups under this risk, because several aren’t obviously “sandbox” issues until you see them together:
- Host escape via shell: a skill with shell access can write cron jobs, install launch agents, drop SSH keys — persistence that outlives the agent process entirely.
- Network pivot: from the host, the agent’s position inside the LAN/VPN is the skill’s position. Lateral movement to internal services requires no additional exploitation.
- Skill shadowing: OpenClaw resolves skills by three-tier precedence — workspace over managed over bundled — with hot-reload watching for changes. A skill dropped in the workspace tier silently shadows the bundled version of the same name; whoever writes that folder wins. That’s a privilege-check nobody designed, implemented by filesystem layout.
- Localhost attack surface: every local service with loopback trust (databases, dev servers, administration sockets) becomes skill-reachable. Loopback as a security boundary assumes the process on the loopback is you.
- Cross-agent contamination: agents sharing a workspace share skills — and identity files. A malicious skill loaded by one runtime can shadow or poison instructions used by a different, better-governed runtime on the same machine.
The two risks compose
The Air Security “Story of Skills” POC (June 22, 2026) is best read as the composition proof: fetched instructions (AST05) arriving in a runtime with no containment (AST06) equals agent takeover. Neither half is sufficient alone. Harden the runtime and the fetched instructions can still exfiltrate whatever the sandbox permits — including, per the AST01 research, identity files if they’re readable. Pin the external content and any other AST01/AST03 vector still reaches a host-context execution. Defense here is genuinely conjunctive: both layers, or neither holds.
Controls that actually work
For AST05 (untrusted external instructions)
- Content-hash pinning with verify-before-ingest. Snapshot and hash external references at review time; the runtime verifies the fetch against the pinned hash before the content enters context. A changed body is a hard stop, not a warning — the network delivers review-time bytes or nothing.
- Inline snapshots at publish. Marketplaces and internal registries freeze external docs into the published artifact. The agent never fetches prose at runtime at all; the skill becomes the static, reviewable unit it should always have been.
- Domain allowlists for instruction fetches. The manifest declares which domains may serve instructions; everything else is denied by default. The network allowlist belongs in the manifest format (the universal-skill-format proposal makes it first-class — see AST09/AST10).
- Transitive reference audits. Walk the full chain of what a skill references, recursively, at review — and treat any new external reference introduced after publication as an update requiring re-approval, even though the version didn’t bump.
For AST06 (weak isolation)
- Container default, host opt-out with documented risk. Digest-pinned images (
alpine@sha256:...),--network=noneunless the manifest allowlists otherwise,--read-onlywith explicit write paths,--cap-drop=ALL. The default posture is a box with nothing in it; capability is added by manifest, never assumed. - Localhost is a boundary — treat it like one. Bind management interfaces to loopback with mutual auth, and never trust origin alone: ClawJacked proved both the origin check and the rate limiter can fall. Loopback trust must include authentication, not just address.
- Kernel-level confinement under the container. seccomp profiles, AppArmor/SELinux policies scoped to the expected syscall and file surface. Containers share the host kernel; the kernel is the actual last line.
- Protect the identity tier from writes. SOUL.md/MEMORY.md (and the workspace skill tier, given shadowing) read-only from skill context — this closes the persistence and contamination paths simultaneously.
Common mistakes when defending this pair
- Auditing shipped files and calling the runtime reviewed. Files are one input; the network fetch is another. Any AST05 assessment that only covers the repo contents has reviewed the static half of a dynamic skill.
- Blocking known-bad domains instead of allowing declared ones. Denylists lose to fresh registrations by construction. The instruction-fetch allowlist inverts the default and survives novel infrastructure.
- Assuming “we use Docker optionality” equals isolation. Optional containment is functionally equivalent to none at fleet scale: the first workload that needed host access turned it off, and nothing tracks which ones. Isolation must be the default with per-case, reviewable exceptions.
- Treating loopback as safe by address. Every skill runs “on localhost” — the loopback trust assumption collapses the moment untrusted code executes anywhere on the host: CVE-2026-32025 is the case study.
Framework references
- CWE-829 (Inclusion of Functionality from Untrusted Control Sphere) for AST05; CWE-653 (Improper Isolation or Compartmentalization) for AST06.
- OWASP LLM Top 10 2025: AST06 relates to LLM08 — the host-execution trust problem predates skills and extends them.
- MAESTRO: AST05 maps primary to L3 (Agent/Data Interactions) — the ingestion boundary; AST06 to the runtime layers where enforcement physically lives.
- In this series: the malicious-payload counterpart to fetched instructions is AST01; permission scoping that bounds any execution is AST03; scanner coverage for these inputs is AST08.
AST05 + AST06 in ten lines
- AST05: external docs fetched at runtime become instructions with agent permissions.
- No lockfile exists for prose — reviewed content and runtime content are unbound.
- Rug-pull needs no version bump: the URL’s body changes, the artifact doesn’t.
- Reviewer bait-and-switch serves clean pages to scanners, payloads to agents.
- Transitive fetch chains inherit review trust they never earned; relays persist attacks.
- AST06: OpenClaw tools run on the host, full access — Docker optional, off by default.
- 135,000+ internet-facing instances; “untrusted execution with persistent credentials.”
- CVE-2026-32025 (CVSS 7.5): loopback WebSocket origin-check + throttle bypass.
- AST05 fix: hash-pin fetches, inline snapshots, domain allowlists, transitive audits.
- AST06 fix: digest-pinned containers default, auth on loopback, seccomp, identity read-only.
Next in this series: AST07 + AST08 — Update Drift and Poor Scanning: what happens after deployment when nobody’s watching the version, and why the scanners everyone trusts as a safety net are structurally one step behind every technique in this post.
