The Stage Where Every Other Risk Becomes Real: AST09 Governance and AST10 Cross-Platform Reuse

Cisco’s 2026 data says 83% of organizations are already deploying agentic AI. The same dataset says 29% are ready to govern it. Inside that 54-point gap lives AST09: skills installed with one command that no CMDB, no IAM system, and no SOC ever sees — and the corporations among Bitdefender’s hundreds of corporate OpenClaw installs mostly don’t know they’re in the dataset. The document calls it shadow AI, and the scary version isn’t the malicious skill that got in. It’s the fact that nobody can answer, with a straight face, the question “which skills are running in this organization right now?”

And when someone finally does answer it, they find the second problem — AST10 — waiting: the same skill, ported across agent platforms, silently loses the manifest, the permissions, and the risk tier that made it governable at all. Snyk tracked the same threat actors (zaycv, moonshine-100rze) publishing on both ClawHub and skills.sh, with zero shared intelligence between the registries. And in July 2026, an OpenAI sandbox escape pivoted through Hugging Face production infrastructure into unauthenticated code execution on Modal Labs — harvesting credentials across four ecosystems in one campaign. Adversaries already operate cross-platform. Our defenses don’t.

This is the final deep dive in our series on the OWASP Agentic Skills Top 10 — hub here; earlier parts cover AST01, AST02, AST03, AST04, AST05 + AST06, and AST07 + AST08. We close with the two risks that decide whether everything before them was theater: governance — knowing what runs — and portability — keeping that knowledge intact when skills move.

AST09: the install that never met an inventory

Every control in the previous seven posts — pinning, scanning, sandboxing, allowlists — shares one precondition: someone knows the skill exists. AST09 is the risk that breaks the precondition.

The mechanics are almost embarrassingly simple. A developer wants an agent to manage tickets. One line — openclaw skill install ... — and it works. No procurement ticket, no change request, no container image to register, no OAuth client to create in the identity provider. The skill lands on a workstation with the user’s full credentials, executes through a runtime most SOC tooling doesn’t parse, and fetches further instructions from wherever it likes (that’s AST05 waiting on top). Nothing in the traditional asset pipeline ever observed any step of it.

The numbers say this isn’t an edge case. Bitdefender’s 2026 research counted hundreds of corporate OpenClaw installations and 800+ malicious skills in circulation — with around 400 deep-analyzed. Cisco: 83% deploying, 29% ready. And the US NIST/CAISI RFI process (January–May 2026) landed on a rough consensus that deserves quoting as a stance: agentic AI introduces novel threats, but the right response is largely adapting existing practice — asset management, change control, credential hygiene — rather than inventing a new discipline. AST09 is what happens when we deploy the novel thing without adapting the existing practice.

The seven failure scenarios

The document’s scenario list for AST09 reads like an audit finding generator. Check which ones you can rule out today:

• Undetected compromise: a malicious skill runs for months because no inventory exists to diff against.
• Unapproved install: well-intentioned, business-useful, and entirely outside change control — the classic shadow-IT shape, now with credential access.
• Orphaned skill: the developer left; the skill still runs; nobody knows what it does or whether anyone still needs it.
• Regulatory exposure: you cannot produce records for an asset you can’t enumerate — the audit fails before the questions get interesting.
• Unreachable skill: the tooling to inspect or revoke a deployed skill effectively doesn’t exist, so “remove it” is a manual filesystem hunt.
• Cascading compromise: one agent’s skills pivot to shared infrastructure and other agents — the tree of trust falls in order.
• Manipulated trust: star-farming and fake-review rings inflate ratings specifically because autonomous agents select skills by reputation score. When the selector is a machine, gaming the score is the whole attack.

The controls, concretely

1. Centralized inventory. One registry of record: name, version, content hash, installer identity, scan status, owning team. Start with discovery-based census (posture intelligence) rather than aspirational mandates — see below.
2. Approval workflow. Skill installs in credential-bearing contexts go through the same change control as any other code with production access. Yes, this costs velocity. So does an unlogged exfiltration.
3. Non-human identities with scoped credentials. Agents get dedicated NHI credentials, scoped per-task and revocable independently of any human’s employment. An agent’s blast radius should end at its NHI.
4. Audit logging — the Bilateral Receipt Pattern. Every skill admission writes an admission receipt; every skill-influenced action writes an outcome receipt (COMMITTED/FAILED/DENY states), keyed by a shared attempt_id, with an action_ref whose preimage fields make the chain tamper-evident, and a parent_action_ref linking cascaded actions back to their origin skill. This closes the loop most agent logging leaves open: not just “what happened” but “which piece of third-party content caused it.”
5. Posture-based discovery. The honest admission is that mandates won’t catch everything on day one. Use OAuth token telemetry and NHI behavior — which credentials are agents actually using, from where, for what — to find the installs nobody declared. Inventory by observation, then reconcile.
6. Regulatory alignment as a forcing function. EU AI Act Article 12 requires record-keeping and logging for high-risk systems; NIST AI RMF’s GOVERN function covers accountability structures. Mapping AST09 controls to these turns “security best practice” into “compliance obligation” — which, organizations being what they are, is often what gets budget.

AST10: property loss in translation

Now the finale’s second half — and the most structurally novel risk in the whole Top 10, in our reading. AST10 says: even if you govern skills perfectly inside one platform, the moment a skill is ported to another agent ecosystem, the security properties don’t come with it.

Each platform’s skill format carries its own metadata: manifests declaring permissions, risk tiers, network allowlists, signatures. When a skill moves from OpenClaw to Claude Code, or Claude Code to Cursor, or Cursor to VS Code — typically by copying a folder or re-publishing a repackaged version — the destination format often has no field for the source’s metadata. The manifest isn’t “dropped” dramatically; there’s simply nowhere to put it. The permission grant that said “filesystem read-only, no network” becomes a plain skill with whatever default access the destination grants. The risk_tier flag becomes nothing. The document’s name for this — property loss in translation — is exact: the artifact arrives, its security semantics stay behind.

The consequence: cross-platform reuse is unvalidated reinstallation. That “community port” of a skill you reviewed on another platform is a new, unreviewed artifact that happens to share a name and some content.

The dual-registry problem, and the four-ecosystem campaign

Two findings say adversaries already operate where our controls don’t overlap:

• Snyk (Feb 2026): the same threat actors — tracked identities include zaycv and moonshine-100rze — published skills on both ClawHub and skills.sh. The registries shared zero intelligence: banned on one, still distributing on the other. A fake “Vercel” skill in the wild chained Gemini CLI and OpenClaw runtimes — a cross-runtime payload shaped exactly like the cross-platform blind spot it exploited.
• The July 2026 OpenAI incident chain: an OpenAI sandbox escape pivoted into Hugging Face production infrastructure, which yielded access to unauthenticated code-execution on Modal Labs — ending in credential harvesting spanning four ecosystems. Read that chain as a stress test: every hop landed in a new platform’s trust assumptions, and the defenses didn’t compose even when each organization responded to its own segment.

The scenario set

• Property loss in translation: the port drops manifest, permissions, and risk_tier — described above.
• Cross-registry arbitrage: high install counts on one registry get cited as trust evidence when porting to another — even when the count was manufactured or the other registry already banned the actor.
• Multi-platform campaign: publish on every registry, harvest whichever trusts the others.
• Manifest stripping: an adversarial “port” that deliberately removes the restrictive metadata — a downgrade disguised as a convenience.
• Implicit privilege escalation: destination defaults grant more than the source’s explicit grant did — the port gains permissions silently.
• Silent supply-chain injection: the ported skill becomes the new canonical version on the second platform, inheriting the first platform’s reputation with none of its scrutiny.

The controls — culminating in the Universal Skill Format

1. Mandatory re-validation on port. Treat every cross-platform skill as a new submission: full review, full scan pipeline (AST08 applies), fresh approval. “It was fine on ClawHub” is not evidence; it’s hearsay.
2. Cross-registry intelligence sharing. Banned-actor and malicious-hash feeds need to move between registries the way CVE feeds move between vendors. The zaycv/moonshine-100rze case should have been one takedown, not two discoveries.
3. Platform-agnostic scanning. Detectors that parse any skill directory layout — not one vendor’s format — so a port can’t outrun the scanner by changing zipfiles.
4. Normalized metadata: the Universal Skill Format (USF) proposal. The document’s forward-looking answer — a portable envelope that survives translation:
   • identity — stable skill identity across platforms;
   • content_hash — SHA-256 over the actual content that runs;
   • signature — ed25519 over RFC 8785 JCS-canonical JSON, so verification is deterministic across every implementation;
   • network.allow — default-deny network policy that travels with the skill;
   • files.deny_write — write-protection for identity files (SOUL.md, MEMORY.md), neutralizing the persistence paths from AST01/AST06;
   • tools — explicit tool declarations instead of ambient access;
   • risk_tier L0–L3 — carried as an untrusted-author assertion, to be re-evaluated by each platform, never silently imported as ground truth;
   • scan_status + changelog — the audit trail that makes drift (AST07) visible across platforms.
5. Metadata-loss education. The document even proposes a browser-based simulator that demonstrates — visually, in one click — what a skill loses when ported. The lesson lands harder when you watch the permission fields evaporate yourself.

Why the series ends here

Look back down the list. AST01 (exfiltration) and AST05 (runtime instruction fetch) are content problems. AST02 (supply chain), AST07 (updates) and AST10 (porting) are lifecycle problems. AST03 (over-privilege), AST04 (metadata parsing) and AST06 (isolation) are execution problems. AST08 (scanning) is a detection problem. But AST09 is the meta-risk: without inventory and receipts, you can’t even find the other nine to fix them. Governance isn’t the boring last chapter — it’s the prerequisite that decides whether the other nine chapters exist in your environment as controls or as reading material.

And AST10 is where the whole field is heading: skills that circulate across platforms faster than any single platform’s controls can follow. The Universal Skill Format may or may not win adoption. But its design brief — identity, hash, signature, default-deny, portable risk assertion — is the correct checklist to demand from any skill standard your organization adopts, today.

Common mistakes

• Solving AST09 with a policy document. “Install only approved skills” without discovery-based census just drives the number further underground. Observe first (NHI/OAuth telemetry), mandate second.
• Treating human-audit logs as agent audit logs. “We log user actions” covers the human who typed the install command — not the skill-influenced actions after it. Without attempt-linked admission and outcome receipts, attribution ends where the interesting part begins.
• Trusting cross-platform install counts. Reputation on registry A is not evidence on registry B — especially when actors deliberately farm it (AST09’s star-farming meets AST10’s arbitrage).
• Assuming the port is the same artifact. Property loss isn’t gradual — one copy-paste and the manifest, permissions, and risk_tier are simply gone. Re-validate every port as new code.
• Importing risk_tier as truth. In USF it’s an untrusted author assertion by design. Any pipeline that auto-trusts a portable risk label has re-created AST10 inside its own tooling.

Framework references

• CWE-1357 (Reliance on Untrusted Components) — the AST10 anchoring; AST09 maps to governance function coverage rather than a single CWE.
• EU AI Act Article 12 — record-keeping/logging obligations for high-risk AI systems; the compliance spine for AST09 inventory work.
• NIST AI RMF GOVERN function — accountability, roles, and risk documentation; the consensus home for skill governance.
• NIST/CAISI RFI consensus (Jan–May 2026): adapt existing security practice to agentic AI rather than waiting on a bespoke discipline — the operating theory behind every control in this post.
• MAESTRO: AST09 sits at the governance layer across L1+; AST10 stresses every ingestion boundary (L2/L3) simultaneously.
• In this series: the hub post for the full map, and AST02 for the first-delivery half of the supply-chain story AST10 completes.

AST09 + AST10 in ten lines

1. AST09: one-line installs bypass CMDB, IAM, and SOC — invisibly at fleet scale.
2. 800+ malicious skills in circulation; 83% deploying, 29% ready (Cisco 2026).
3. Scenario set includes orphaned skills, regulatory exposure, and star-farming.
4. Fix: centralized inventory (name/version/hash/installer/scan), approval, NHI creds.
5. Bilateral Receipt Pattern: admission + COMMITTED/FAILED/DENY outcome receipts by attempt_id.
6. Posture-based discovery via OAuth/NHI telemetry finds the undeclared installs.
7. AST10: porting skills across platforms drops manifests, permissions, risk_tier.
8. Same actors on multiple registries (zaycv, moonshine-100rze); no shared intel.
9. Jul 2026 chain: OpenAI → Hugging Face → Modal Labs — four ecosystems, one campaign.
10. Fix: re-validate every port, share cross-registry intel, adopt USF (sha256 + ed25519/JCS + default-deny).

That completes our eight-part walkthrough of the OWASP Agentic Skills Top 10. If you read the series end to end, the through-line is now visible: skills are a supply-chain problem, an execution problem, and a governance problem arriving simultaneously — and the ecosystems that treat all three as one engineering discipline are the ones that will survive their own agents. Start with the series hub, and if you take exactly one action from eight thousand words: build the inventory. Everything else keys off it.