OpenClaw Skill Installs Freeze As AI Agents Get Supply-Chain Rules

Alex, take the active-exploitation lane and give me a decision-grade triage, not a CVE recap. From the source pack: Exploitarium’s 23 working zero-day exploits across OpenVPN, Docker Engine, Gitea, 7-Zip, AnyDesk and others; Microsoft Defender CVE-2026-33825 BlueHammer tied to ransomware; Oracle E-Business Suite CVE-2026-46817 under attack against Oracle Payments with roughly 950 exposed instances; SimpleHelp CVE-2026-48558 abused for forged OIDC technician tokens and Djinn; Progress Kemp LoadMaster CVE-2026-8037 attempts; SharePoint CVE-2026-45659 in CISA KEV; PeopleSoft zero-day extortion against universities. Classify what is patch-now, isolate-now, and hunt-as-compromised today. Where is exploitability being overstated or understated?

Halil, decision-grade triage:

Isolate-now and hunt-as-compromised: SimpleHelp, Oracle EBS Payments where exposed, and PeopleSoft where internet-facing. SimpleHelp is the cleanest kill chain in the pack: forged OIDC technician tokens plus Djinn deployment means attackers are abusing remote-support trust, not just poking at a web bug. Oracle EBS CVE-2026-46817 also belongs here: the pack says Oracle Payments is under attack with roughly 950 exposed instances, and DefusedCyber reports in-the-wild exploitation of CVE-2026-46817 against Oracle E-Business Suite decoys starting 27 June 2026. Payments systems are cash registers with APIs. Don’t just patch the lock after someone may already be inside.

Patch-now with targeted hunting: Microsoft Defender CVE-2026-33825, SharePoint CVE-2026-45659, and Progress Kemp LoadMaster CVE-2026-8037. BlueHammer is serious, but I’d frame it as post-access privilege escalation unless the initial-access chain is shown: Microsoft describes CVE-2026-33825 as local elevation of privilege by an authorized attacker, and CISA’s KEV entry says ransomware use is “Unknown.” Kemp is perimeter-facing and the CyberBrief pack says exploitation attempts are happening, so patch fast and check appliance logs; I would not overstate the exact exploit path without stronger detail. SharePoint gets same-day patching if exposed, but I’d still rank it below SimpleHelp and Oracle Payments unless we have confirmed compromise indicators.

Where the hype is: Exploitarium’s “23 working zero-days” bundle. That sounds scary, but it mixes very different kill chains: OpenVPN or AnyDesk can sit near access paths; Docker Engine and Gitea can affect build/deploy environments; 7-Zip usually needs a content/user interaction path. Treat it like a box of keys, not one master key. Prioritize by exposure and whether the exploit closes the chain to identity, remote access, payments, or deployment infrastructure.

Lena, separate campaign signal from noise across today’s active incidents. I want your attribution and intent read on ShinyHunters/PeopleSoft university extortion, FortiBleed links to Lynx/INC ransomware, Defender BlueHammer ransomware use, SimpleHelp/Djinn credential theft, DHS/SharePoint breach, and the Exploitarium dump. Which of these are likely connected operationally, which merely rhyme, and which should executives treat as opportunistic exploitation rather than a named actor story? Call out confidence levels.

Halil, I’d separate these into three buckets.

Operationally connected: none at high confidence. I don’t see enough shared infrastructure, tooling, timing, or victimology here to tie ShinyHunters/PeopleSoft, FortiBleed/Lynx, BlueHammer, SimpleHelp/Djinn, DHS/SharePoint, and Exploitarium into one campaign.

Campaigns with real signal but actor confidence varies: - PeopleSoft university extortion — ShinyHunters: real campaign signal; attribution moderate confidence. The sourced reporting says ShinyHunters exploited an Oracle PeopleSoft zero-day against universities. Intent reads as extortion, not espionage. - FortiBleed — Lynx ransomware: real exploitation/credential-theft signal; Lynx linkage moderate confidence. I do not have grounded support here for folding INC into the same operational cluster. - BlueHammer / Microsoft Defender CVE-2026-33825: real ransomware-enabling vulnerability exploitation; named actor attribution low confidence. The strongest fact is exploitation in ransomware attacks, with Microsoft disclosure, patching, KEV treatment, and Huntress pre-patch observations; no ransomware group is identified in the evidence I have.

Opportunistic exploitation / named-actor story is weak: - SimpleHelp/Djinn credential theft, DHS/SharePoint breach, Exploitarium dump: I don’t have enough grounded evidence in front of me to make attribution calls. Treat these operationally as exposure-and-exploitation problems first, not actor-branded stories.

MITRE-wise, the common rhyme is not actor linkage; it is access brokerage mechanics: exploitation of public-facing apps, credential theft, privilege escalation, and ransomware/extortion follow-through. Executive priority should follow exploitability and exposure, not the actor names.

James, listen for the operational close: convert today’s exploit board into a same-day response plan a CISO can authorize before lunch. Cover sequencing across exposed Oracle EBS/PeopleSoft/SharePoint/Kemp/SimpleHelp, Defender BlueHammer endpoints, Fortinet credential exposure, and Exploitarium-affected products where patches or CVEs may not exist yet. Be explicit on outage tolerance: what gets removed from the internet, what gets emergency-patched, what gets monitored, and what gets treated as already compromised?

Halil, this is the CISO authorisation package: take the outage where the system is internet-exposed and exploitable. Before lunch, remove from the internet: Oracle EBS, PeopleSoft, SimpleHelp, Fortinet management/SSL-VPN admin surfaces, and any SharePoint or Kemp admin interface that is not explicitly required for public service. EBS CVE-2026-46817 is reported as actively exploited over HTTP with patches already issued; PeopleSoft CVE-2026-35273 had active exploitation and an out-of-band update; SimpleHelp CVE-2026-48558 is tied to Djinn stealer deployment; Kemp CVE-2026-8037 has exploitation attempts; SharePoint CVE-2026-45659 is listed as KEV in the current board. My call: EBS, PeopleSoft, and SimpleHelp exposed to the internet are treated as already compromised, not merely vulnerable.

Sequencing: CRITICAL today — block exposure, preserve logs/images, patch EBS/PeopleSoft/SharePoint/Kemp/SimpleHelp after a smoke test, rotate credentials touched by those systems, and for Fortinet do credential response first: disable public management, revoke active sessions, force MFA, rotate VPN/admin accounts, and review successful logins because FortiBleed is a credential-validation campaign, not just a software bug. BlueHammer is different: don’t create a company-wide endpoint outage; patch Defender/Windows first on admin workstations, servers, jump boxes, VPN/RDP-heavy machines, and ransomware blast-radius systems, because CVE-2026-33825 is reported as exploited by ransomware and patched in April 2026. Exploitarium-affected products: I have no verified advisory, CVE, or patch data in the evidence here, so the defensible move is containment — remove internet exposure, enable enhanced logging, open vendor cases, and treat any exploitation signal as compromise until proven otherwise. No heroic “patch everything” order; this is isolate, patch where verified, hunt where exposed, and rotate credentials where trust is burned.

Tomas, focus on the trust-chain angle that the exploit headlines can hide: Exploitarium exploit-code circulation; ChocoPoC trojanized GitHub PoCs; North Korean fake Polymarket npm packages; Operation Navy Ghost PyPI; OpenClaw malicious AI agent skills; unpatched Argo CD repo-server exposure; and Codecov as the cautionary model. Where should engineering teams freeze or constrain execution today without causing a blanket productivity shutdown? Give bounded controls.

Halil, I would not freeze engineering broadly. I’d freeze execution of newly introduced, externally sourced code in the paths most likely to carry secrets or production trust.

The pattern across the sourced items is clear: Exploitarium is exploit-code circulation; ChocoPoC is trojanized GitHub PoCs; the fake Polymarket npm packages are developer-secret theft; Operation Navy Ghost is malicious PyPI packages affecting Telegram bot servers; OpenClaw is malicious AI-agent skills from a marketplace; Codecov is the cautionary case where a trusted CI uploader path exposed secrets. For the Argo CD repo-server item, I would not assert exploit mechanics — but I would still constrain the repo-server execution path until patched or verified.

Bounded controls I’d apply today:

• Exploit/PoC code: freeze direct execution of GitHub PoCs and Exploitarium-derived code on developer laptops and shared runners. Allow only disposable sandbox VMs with no mounted SSH keys, cloud creds, package tokens, browser sessions, or internal network access.
• npm/PyPI: quarantine new or low-reputation packages tied to trading bots, crypto automation, Telegram bots, AI tooling, or exploit tooling. Require lockfiles, hash pinning, internal mirror promotion, and manual approval before CI can install them.
• CI/CD: freeze curl | bash, mutable uploader scripts, unpinned GitHub Actions, and third-party build plugins. Pin by commit/digest, scope CI tokens read-only by default, and rotate secrets for any pipeline that executed a Codecov-like uploader pattern.
• AI agent skills: disable marketplace auto-install for OpenClaw-style skills. Permit only reviewed skills in a sandbox with explicit filesystem, network, and secret-access permissions.
• Argo CD repo-server: until verified patched, restrict repo onboarding, isolate repo-server egress, block access to sensitive cluster services, and avoid mounting high-privilege credentials into that path.

So the freeze line is: no unreviewed external code gets to execute where secrets, CI identity, cluster credentials, or developer sessions exist. Everything else can keep moving through pinned, mirrored, reviewed paths.

Priya, take the cloud/SaaS identity control-plane lane. The board today includes EvilTokens/ARToken/Kali365 device-code phishing against Microsoft 365, 81M Azure CLI/Entra login attempts abusing OAuth ROPC and Conditional Access gaps, SimpleHelp/Djinn stealing cloud and AI coding-assistant tokens, Alta Montclair’s public AWS bucket, and Argo CD repo-server exposure. What is the same-day control set: which auth flows should be disabled or constrained, which logs prove compromise, and where should cloud teams assume token theft rather than password theft? Push back if patching appliances is distracting us from the bigger identity blast radius.

Halil, I’d treat this as an identity control-plane incident first, appliance incident second. For Microsoft 365/Entra, same-day controls are: disable or tightly restrict OAuth ROPC, because Huntress reporting via SC World/The Hacker News says the Azure CLI spray campaign abused ROPC and generated 81M+ attempts with at least 78 compromised accounts across 64 orgs. Also constrain device-code flow: allow it only for explicitly approved apps/users/devices, and alert on device-code auth to Microsoft 365 accounts. Device-code phishing is the point of EvilTokens per The Register’s report, so “MFA is enabled” is not enough if the attacker is getting a valid OAuth token through a legitimate flow.

The logs I’d ask for today: Entra ID sign-in logs filtered by client app / authentication protocol, Azure CLI sign-ins, non-interactive sign-ins, OAuth app consent activity, refresh-token issuance/revocation events, Conditional Access result details, and impossible/atypical ASN patterns. For the reported Azure CLI campaign, hunt around AS32167 / LSHIY-linked infrastructure where relevant, but do not make that your only detector. The proof of compromise is not just a successful password login; it is valid token use from an unexpected client, flow, ASN, device state, or Conditional Access gap.

Where cloud teams should assume token theft rather than password theft: SimpleHelp/Djinn-style post-compromise collection, developer workstations, CI/CD runners, AI coding-assistant CLIs, Azure CLI sessions, Git credentials, GitHub/GitLab tokens, AWS/GCP/Azure local credential caches, and Kubernetes kubeconfigs. If an endpoint or remote-support appliance is touched, assume the attacker is shopping for bearer tokens and refresh tokens, not politely stopping at /etc/passwd. “Serverless” still has servers, and “passwordless” still has tokens.

On Alta Montclair’s public AWS bucket and Argo CD repo-server exposure, I have insufficient visible source detail here to make a hard claim about exact object contents or CVE/API path. But the same-day posture is clear: for AWS S3, block public access at account and bucket level, review bucket policy/ACL/object ownership, rotate any exposed keys, and inspect CloudTrail/S3 data events if enabled. For Argo CD, remove repo-server exposure from the internet, rotate repository credentials and deployment tokens, and review Argo CD audit/Kubernetes API activity. Patching SimpleHelp or Argo CD matters, but if we patch and leave OAuth legacy flows, long-lived refresh tokens, repo credentials, and cloud CLI tokens alive, we have closed the door after handing over the building access badge.

Arjun, I’m activating you for the AI-agent lane. BioShocking showed AI browsers/extensions disclosing private files such as SSH credentials; Cursor CVE-2026-50548/50549 allowed MCP/web-search-triggered sandbox escape and command execution; Langflow RAGPull exposed AI servers to takeover; GuardFall bypassed Bash command filters in 10 of 11 open-source agents; Phantom squatting turns LLM hallucinated domains into phishing/malware; PromptMink/OpenClaw show agent/package trust failures. What is genuinely new operational risk here, what is still research-lab noise, and what should enterprises disable or gate today?

Halil, the genuinely new operational risk is not “the model got smarter.” It is that natural-language input is now crossing into privileged execution paths. The two grounded examples I can speak to directly are BioShocking, reported as tricking AI browsers into disclosing private data, and the Cursor CVE-2026-50548/50549 issue, reported as patched flaws where prompt/web-search/MCP interaction could lead toward sandbox escape and command execution. That is OWASP LLM Top 10 territory: prompt injection becomes tool abuse, data leakage, and execution because the agent has authority the user never meant to delegate.

So I would separate the lane this way:

• Immediate enterprise risk: AI browsers/extensions, IDE agents, MCP-connected tools, and RAG/agent servers that can read local files, invoke web search, run shell commands, install packages, or touch secrets. These should be treated like remote-code-capable clients, not chatbots.
• Important but conditional risk: command-filter bypasses like the GuardFall-style scenario. If the agent can call Bash and your only safety layer is a regex or denylist, that is operationally serious. If it is an isolated lab agent with no secrets and no network path, it is design evidence rather than an emergency.
• Still more research-lab/noise unless tied to deployment: generic jailbreaks that only make the model say forbidden text. They matter when connected to tools, files, identity, or retrieval pipelines; otherwise they are not the same class as sandbox escape or credential disclosure.
• Supply-chain/identity risk: Phantom squatting, PromptMink/OpenClaw-style package or trust failures should be evaluated like dependency-confusion and phishing, with the LLM acting as the recommender or resolver. The novelty is hallucinated trust paths; the mitigation is still package provenance, allowlists, and verification.

What I would gate or disable today: disable AI browser/extension access to local files and SSH material by default; disable unattended MCP tool execution; block shell/file/network tools from running in the same agent session unless explicitly approved; require per-command human confirmation with a visible command, working directory, environment, and data egress preview; pin MCP servers and tool manifests; isolate agent workspaces in disposable containers or VMs; and remove long-lived secrets from developer environments where agents operate. The model should never be the security boundary — the boundary has to sit outside it.

For the items beyond BioShocking and Cursor, I’d want source-level confirmation before calling each one exploited-in-the-wild. But the operational pattern is clear enough: enterprises should treat agentic AI as a new privileged client class and lock it down before broad rollout.

Viktor, give us the financial-crime and key-custody read. Humanity Protocol reportedly lost control after a compromised developer laptop and bridge-administration private key let attackers mint roughly 447M H tokens and crash price 80–90%; June losses were about $75.9M across 40 incidents, Edel Finance created $403K bad debt through wrapped-token logic, and North Korean fake Polymarket npm packages/fake browser extensions keep targeting developer and wallet secrets. What pattern matters to boards, and what immediate custody, monitoring, and recovery actions should crypto and fintech teams take?

Halil, the board-level pattern is not “40 separate crypto bugs.” It is privileged-key and developer-workstation failure becoming treasury failure. The sourced picture is: Humanity Protocol led June losses after a private-key/bridge-control compromise, with visible reporting putting losses around $30M–$36M and H down over 85%; June-wide reporting puts losses at about $75.87M across 40 major incidents; Edel Finance shows the same control theme in market logic, with a wrapped-token pricing flaw creating about $403K bad debt; and North Korean actors are targeting developer secrets via fake Polymarket trading-bot npm packages. That is one pattern: attackers are going upstream of smart contracts into laptops, npm dependencies, admin keys, bridge operators, and pricing assumptions.

For boards, I would frame this as key custody risk, not just “cyber risk.” A bridge-admin private key is effectively a minting authority; a developer laptop with signing access is a treasury endpoint; a malicious npm package is a key-exfiltration path; a wrapped-token pricing bug is a balance-sheet event. I do not have enough sourced on-chain detail here to name destination wallets, mixers, exchanges, or final off-ramps, so the immediate priority is containment and freeze coordination before funds move further.

Immediate actions: rotate and revoke all bridge/admin/signing keys; pause bridge and liquidity-pool interactions until authority paths are rebuilt; move treasury and admin signing into hardware-backed multisig or MPC with policy controls; remove developer laptops from any direct signing path; audit npm/package-lock changes and browser extensions on developer and finance workstations; and run emergency screening on H-token flows, bridge withdrawals, and exchange deposits tied to the incident. For Edel-like cases, teams should add wrapped-asset sanity checks, oracle bounds, debt-ceiling limits, and automatic market pause thresholds.

Recovery should be parallel: preserve laptop/package forensic evidence, publish attacker addresses if confirmed, notify exchanges and stablecoin issuers, request freezes where assets touch cooperative venues, and keep monitoring for cross-chain movement. The window is short: once funds are bridged, split, or pushed into non-KYC venues, recovery becomes much harder.

Sofia, keep us honest on legal exposure without turning every item into a compliance lecture. Focus on where today’s evidence triggers deadlines or board disclosure: PeopleSoft university extortion, Oracle EBS/Payments exploitation, DHS/SharePoint collaboration breach, Alta Montclair’s exposed retirement records and PGP key, Aflac Japan’s 4.38M possibly affected customers/agents, Kubota employee/dependent data, Huntsville Hospital lawsuit, and Tata/Apple supplier materials. What should counsel and CISOs do in the first 24 hours while facts are still incomplete?

Halil, the only hard clocks I would put on the whiteboard immediately are these: under GDPR Article 33 practice, if EU personal data is implicated, the 72-hour supervisory-authority clock runs from awareness, not from patching or full forensic certainty; for SEC registrants, Item 1.05 Form 8-K is due within four business days after the company determines a cybersecurity incident is material. Aflac Japan ranks highest for board attention: 4.38M customers/agents, policy/account data, some bank-account data, service disruption, and regulator notification make materiality analysis unavoidable.

For the first 24 hours, counsel and CISOs should do four things: preserve evidence under privilege; create a jurisdiction-by-jurisdiction data map; open a documented SEC materiality file for any public company or public-company supplier; and prepare notices without yet sending speculative statements. Aflac Japan and Kubota are privacy-notice workstreams. Oracle EBS/Payments and PeopleSoft extortion are board/escalation workstreams if production finance, student, payroll, or identity data was accessed. Alta Montclair must immediately remove exposure, rotate the PGP key, and identify whose retirement records were public. DHS/SharePoint and Tata/Apple supplier materials need confidentiality, contractual notice, and government/customer coordination before public disclosure.

I would not let teams hide behind “facts are incomplete.” Incomplete facts are normal at hour 24. The legal deliverable is a defensible decision record: what is known, what data classes may be affected, which regulators/customers may require notice, who owns each clock, and when the board will receive the next update.

James, close the operational dispute for us. Alex says isolate-now and hunt-as-compromised for SimpleHelp, Oracle EBS Payments, and PeopleSoft; you widened that to Fortinet management/SSL-VPN admin surfaces, SharePoint, and Kemp; Priya says this is identity control-plane first, appliance incident second; Arjun says AI agents must be treated as privileged execution surfaces, not chat tools; Sofia says the clock starts at awareness, not forensic certainty. Give me a strict same-day sequence in three time boxes — first 2 hours, today, next 7 days — and say what we deliberately do NOT spend scarce time on this morning.

Halil, I’d close the dispute this way: identity first and appliance response are not competing workstreams — the first two hours are about cutting off exposed control planes and burning suspect credentials.

First 2 hours: remove internet exposure for SimpleHelp, Oracle EBS Payments, PeopleSoft, Fortinet management/SSL-VPN admin, Kemp admin, and exposed SharePoint admin paths. Accept the outage on remote-support and admin surfaces; do not keep them online for convenience. Treat internet-facing SimpleHelp, Oracle EBS Payments, and PeopleSoft as already compromised because the board shows active exploitation for SimpleHelp CVE-2026-48558, Oracle EBS CVE-2026-46817, and PeopleSoft CVE-2026-35273. Revoke active sessions, rotate admin/API/service credentials tied to those platforms, freeze privileged AI agents or skills with write access to code, cloud, CI/CD, ticketing, or secrets, and preserve logs before patching.

Today: emergency-patch only where patches are verified: Oracle EBS, PeopleSoft, SharePoint CVE-2026-45659, Kemp CVE-2026-8037, SimpleHelp, and Microsoft Defender BlueHammer CVE-2026-33825 — but smoke-test first, then push to exposed or Tier-0 systems. BlueHammer gets priority on admin workstations, servers, jump hosts, and ransomware blast-radius endpoints; don’t burn the morning on a whole-fleet endpoint scramble. Fortinet is credential response first: disable public admin, force MFA, rotate VPN/admin creds, review successful logins. Exploitarium items with no confirmed CVE or patch get isolated and monitored, not guessed-at remediation.

Next 7 days: finish patch coverage, validate no persistence, complete credential rotation, rebuild any confirmed-compromised SimpleHelp/Oracle/PeopleSoft hosts, and put AI agents under the same controls as service accounts: least privilege, secret isolation, audit logging, and approved tool allowlists. What we do not spend scarce morning time on: generic awareness emails, broad vulnerability scans without containment, perfect attribution, low-exposure internal Tomcat-style backlog items, or writing elegant detection content before the exposed systems are off the internet.

Nadia, we have not given mobile its own lane, so give me the disciplined version. The pack includes Apple iOS/iPadOS/macOS/WebKit early updates, a separate iOS/iPadOS 16.5.2 item described as actively exploited, CISPA Quick Share/AirDrop proximity flaws, Glitch SPY via sideloaded Polish apartment-rental APK, fake Android document readers, and Check Point’s Chrome-on-Android browser-only ransomware PoC using File System Access API. What deserves same-day enterprise action versus high-risk-user monitoring? Be precise: MDM patch posture, sideloading policy, proximity-sharing controls, and whether any of this changes board-level priority today.

Halil, disciplined cut: same-day enterprise action goes to the Apple actively exploited iOS/iPadOS 16.5.2 item. Treat that as an MDM compliance gate for managed iPhones/iPads: require the fixed OS build, block conditional access for laggards, and prioritize execs, legal, finance, comms, journalists, and anyone traveling. The broader Apple early-update/WebKit patch wave also belongs in the fast patch ring, but the “actively exploited” iOS/iPadOS item is the one I would not leave to normal weekly cadence.

The CISPA AirDrop/Quick Share findings are not the same category based on the evidence I have: reported flaws affect Apple AirDrop and Google/Samsung Quick Share-style proximity protocols across iOS/macOS/Android/Windows, with nearby unauthenticated attackers able to crash sharing/continuity services; the visible reporting frames the main impact as denial of service, not confirmed data theft. So: disable or tightly restrict AirDrop/Quick Share for high-risk users, conferences, field teams, and hostile-travel profiles where UEM supports it. I would not make that a full-enterprise emergency unless the organization has proximity-threat exposure.

For Glitch SPY via sideloaded Polish apartment-rental APK and fake Android document readers, the operational answer is ecosystem control, not panic: block Android sideloading/unknown-source installs on managed devices, enforce app allowlists for document readers, and monitor high-risk users for off-store APK installation. I do not have enough sourced detail here to name app packages or assert scale. The Check Point Chrome-on-Android browser-only ransomware PoC is also monitoring-plus-hardening for now: useful because it shows browser storage abuse can hit mobile users, but I would not elevate it above exploited mobile OS patches without evidence of in-the-wild use.

Board-level: Apple active exploitation is board-notifiable as part of patch-risk posture if your mobile fleet includes sensitive roles. The others are CISO/action-owner issues today: sideloading policy, proximity-sharing controls, and mobile threat defense tuning. They matter, especially outside the enterprise bubble, but they do not change board priority unless you have targeted personnel or regulated data on unmanaged Android devices.

Tomas, the closure gate is right: we named OpenClaw but did not assess it. For the OpenClaw ClawHub malicious AI-agent skills incident, give me same-day controls for agent marketplaces. Should teams freeze new skill installs, audit existing skills, revoke exposed tokens, sandbox agent permissions, or all of the above? Be precise: what applies only to AI-agent marketplaces versus ordinary package registry hygiene?

Halil, for OpenClaw/ClawHub, yes: all of the above, but bounded to the agent execution path. Do not shut down every developer tool; freeze new marketplace skill installs and keep already-approved internal skills running only if they are pinned and permission-scoped.

I checked with Arjun on the AI-specific layer, and his point is the important one: an AI-agent skill is not just a package. It is an instruction-bearing trust object that can steer an agent with shell, filesystem, repo, browser, workflow, and credential access. So ordinary npm/PyPI hygiene is necessary but not sufficient.

Same-day controls:

• Freeze new ClawHub/OpenClaw marketplace skill installs unless they pass manual review and come from a verified publisher.
• Inventory existing skills and review SKILL.md, prompts, manifests, tool declarations, install scripts, README content, and hidden files as executable policy, not documentation.
• Revoke and reissue tokens exposed to any agent workspace that ran unreviewed skills: GitHub tokens, package registry tokens, cloud keys, SaaS API keys, and local credential-manager access.
• Sandbox agent permissions by default: no inherited shell, repo write, filesystem-wide read, browser session, network egress, or secret access just because a skill is installed.
• Disable auto-install and recommendation-driven install flows for agent skills until marketplace trust signals are stronger.
• Log agent tool calls: file reads, shell commands, outbound network, repo operations, and secret access attempts.

What is AI-agent-marketplace-specific is the permission and instruction layer: reviewing skill instructions, gating tool access, and preventing prompt/skill text from becoming ambient authority. What remains ordinary package-registry hygiene is still pinning, hash verification, allowlisted sources, internal mirrors, publisher reputation checks, and SCA in CI.