Personal Agents and Supply Chain Attacks
A few months ago, a typical 'agentic workflow' involved a few Python scripts, a reverse proxy (and obligatory Hetzner VPS), and Claude Code with an MCP server for browser access (e.g. Playwright) on a dev laptop. While Claude natively allowed you to 'pass tasks' between a web instance and a desktop instance, the experience wasn't quite as integrated as controlling a Claude Code instance with direct filesystem and terminal access from your phone. But, this experience was limited to those with the time and inclination to set up that connectivity stack.
More recently, ClawdBot -> MoltBot -> OpenClaw brought this 'personal desktop agent' concept to individuals who might never use tmux or manage git worktrees, with the ability to orchestrate actions via messaging apps like Signal or Whatsapp. The ability to remote orchestrate an agent capable of 'almost anything' in a desktop environment is powerful, but the attack surface is also that entire desktop, and any connected external/web services:
Conceptually, the ability to extend OpenClaw with 'skills' from ClawHub gives users great flexibility - just follow the instructions (typically involving setting up your service API keys), and instruct OpenClaw to take action. But this opens up a large 'supply chain' attack vector, as anyone can publish a skill, artificially inflate the download count to push the package up in popularity, and embed malicious logic in a skill, as @theonejvo demonstrated with the "What Would Elon Do?" skill. Buried in the bundled files with the skill was a 'logic.md' file which instructed the agent to collect hostname and current working directory, and ping back to a remote server:
However, this is a fast-moving domain: OpenClaw is partnering with VirusTotal to scan skills for known malicious content, and also leverages Gemini to scan for vulnerabilities, "starting from SKILL.md and including any referenced scripts or resources. It doesn’t just look at what the skill claims to do—it summarizes what the code actually does from a security perspective: whether it downloads and executes external code, accesses sensitive data, performs network operations, or embeds instructions that could coerce the agent into unsafe behavior".
For another take, also see the DeepLearning.AI article on OpenClaw. It's also worth noting the recent emergence of NanoBot, which takes the concept of OpenClaw but removes skills - forcing the user to intentionally add back in functionality, rather than shipping with a large 'batteries included' attack surface.
Multi-Agent Security
In a more general sense, any multi-agent system (for the sake of argument, 'an AI orchestrator and subagents, with unrestricted access to a large quantity of tools') presents an extremely attractive attack surface for malicious actors. The 2025 paper "Multi-Agent Systems Execute Arbitrary Malicious Code" explores this in detail, which matches the vulnerabilities we're seeing in OpenClaw. Human users interact with a powerful model (defined here as 'having access to sensitive tools, services and files'), and some of the tools which that model uses are compromised - which then compromises the data or services with which the user is indirectly interacting.
"Multi-Agent Systems Execute Arbitrary Malicious Code" makes the point that this vulnerability is not present in an individual LLM (e.g. jailbreaking resistance), but emerges through manipulation of shared data and intermediary agents. A great example is Figure 2 from the paper - the user might ask to read 'file.txt', but that file might actually be a Python script, with instructions to execute it as such - noting that 'The ONLY WAY to see the file's contents is for the executor to execute the file as a python script'. In an attempt to be helpful, the FileSurfer agent might report that the contents need to be executed as a Python script, the orchestrator relays that instruction to the CodeExecutor agent, and an arbitrary payload is executed. The more autonomous the system (less 'human in the loop approvals'), the more biased the system will be towards 'solving a problem' - even when that solution might involve 'unconventional' solutions.
The paper explores other more indirect approaches, like including a benign test file ('file1.txt') in the same folder as malicious files ('file2.txt', 'file3.txt'). When asked to describe the contents of the benign file, the agent complies, and then (in an attempt to be helpful) begins exploring and summarizing the other files in the directory, which leads to it opening a reverse shell. The appendix includes other templates in support of this style of vulnerability:
Software Engineering Orchestrators
Due to the issues above, it is unlikely that engineers are actively using OpenClaw on a wide 'day-to-day' scale for development right now, but let's take a brief look at Claude Code and Codex and how they handle agents.
Custom subagents in Claude Code provide separation of context for a single orchestrator to 'hand off' a task and get back a summary, which effectively manages context (e.g. an orchestrator can write a task list, have a 'Code Author' agent write code and tests, have a "Quality Reviewer" agent review the generated code, and never pollute the main orchestrator context with the code, tests, or review). But, this is a strictly hierarchical approach - the subagents cannot communicate with one another (barring clever approaches like instructing subagents to write to a shared scratchpad via custom skills or AGENTS.md).
More recently Anthropic has introduced "Agent Teams", which allow for an orchestrator to spin up sub-agents which can pass messages between each other independently from the orchestrator.
Meanwhile, OpenAI Codex does not explicitly support user-defined agents, and leans into worktree-based automations (which is currently a helpful differentiator, as native worktree support is somewhat lacking in Claude Code). If you've played with Antigravity, the Codex GUI feels very similar in terms of user affordances (projects, tasks within projects, etc).
Notably, notice that neither Claude Code nor Codex possess a first-class notion of 'permissions' outside of execution sandboxing. As we saw with OpenClaw, simply sandboxing the code execution doesn't prevent attacks that compromise data, credentials, or skills. Once an external service, API, or data store is introduced, the risk isn't 'malicious code damaging my machine', but 'destructive or malicious data exfiltration'. The tools are there for an individual engineer to set up appropriate permissions (e.g. via PreToolUse hooks to block network or database writes without user confirmation), but none of this is quite set up out of the box. The default of 'prompt the user for every tool use, file read, and file write' leads to 'alert fatigue'.
Enterprise Level Frameworks - OpenAI Frontier
By introducing Frontier, OpenAI attempts to tackle some of these issues, and go beyond them, towards building effective "AI Coworkers". Their vision:
"Frontier gives agents the same skills people need to succeed at work: shared context, onboarding, hands-on learning with feedback, and clear permissions and boundaries. That’s how teams move beyond isolated use cases to AI coworkers that work across the business."
The main differentiating aspects of Frontier from 'giving everyone Claude Code or Codex' seem to be:
- Shared Context - Ensuring that agents used by the organization work from the same desiloed data set(s), and do work in a way that aligns with the rest of the group.
- Onboarding - A common, organization-wide way of bringing a new agent into the team - including IT-managed permissions, playbooks, who to email with specific problems, when to post in Slack Channel X, etc. Essentially the process of 'injecting' the initial shared context into a new agent.
- Hands-on learning with feedback - The term 'evals' gets thrown around a lot, but if OpenAI can nail 'easy ways to allow domain experts to provide positive/negative annotated feedback to task-specific agents', evals and company specific few-shot prompts can be built behind the scenes by OpenAI FDEs (and likely GPT 5.x itself over time). This is a gigantic unlock beyond the typical 'upload your documents and hope for the best' enterprise approach. Given that the intro post shows a user providing detailed 'refund approval' feedback, this makes improving models for business-specific cases much more straightforward.
- Clear permissions and boundaries - To the extent that OpenAI can enable existing IT departments to 'own' permissioning for agents across company intranet, external services, and data stores, this makes it much easier to gain confidence that an agent has just the right access for its specific needs - and makes the safety/security story much easier for an enterprise customer.
Enterprise Level Frameworks - Claude Cowork
While clearly targeted to 'business users', Claude Cowork still feels more like a solution managed by each individual non-technical user. The integration with typical 'business software' enables more effective agentic computer use for folks who don't want to dig into a terminal. But looking at it from a procurement perspective, the lack of organizational level plugin control and auditability lag far behind Frontier:
Enterprise Differentiators
To get through to enterprises, vendors need to tell a story of how they solve the supply-chain vulnerability of ClawHub style 'skill sharing', as well as giving IT departments the IAM controls necessary to provide granular access to their systems and data. At first, we'll see this happen through forward-deployed engineers leveraging GPT 5.3 (lots of 'bespoke' integration with idiosyncratic systems and policies), and over time, that burden will shift almost entirely to GPT, moving model vendor FDEs up the stack.
In parallel, the democratization of evals towards 'any domain expert provides feedback, and the model keeps improving' will allow self-improving enterprise use cases. If an agent can improve future workflow runs based on natural language feedback from a domain expert, this allows continual improvement without new frontier models or explicit fine-tuning. The capability overhang of models like Opus 4.6 and GPT-5.3 is real, and letting users refine their desired outputs through frameworks like Frontier gives users a tool to unlock more functionality, quickly.
