In early 2026, Cisco AI security tested a third-party skill from the OpenClaw marketplace and found it was performing data exfiltration and prompt injection on the user without the user's awareness. The skill repository, like most community marketplaces, depends on reactive moderation: skills are vetted after being flagged, not before being published.
For users who do not read every skill before installing it (which is approximately 100% of users), the supply-chain risk is non-zero and is worth thinking about before you commit to a stack.
What an AI agent skill actually is
Most users encounter agent skills as "the thing that lets the agent do X." Send an email; book a meeting; pull stock data. Under the hood, a skill is a small program (or a small contract pointing to a larger one) that the agent calls during a conversation.
The skill has access to whatever the user authorized it for. If the skill is "send an email," it has access to the user's email. If the skill is "look up customer records," it has access to the customer database. The principle of least privilege says skills should have only the access they need for their declared function. The reality of open marketplaces is that skills sometimes claim more access than they need, and the user authorizes it because the user does not read every line of the skill manifest.
This is the supply-chain attack surface.
The three questions to ask
Before installing any agent skill from a marketplace, three questions:
1. Who vetted this skill? "The community" is not a vetting answer; it is a reactive moderation system. Reactive moderation catches problems after they happen. If you want pre-shipping vetting, the marketplace contract is not it.
2. What permissions does the skill actually exercise? The manifest claims certain access. Does the skill exercise only those, or does it reach for others? Most users will not audit this; the runtime should bound the skill to its declared scope.
3. What happens if the skill misbehaves? Per-skill sandboxing? Per-user isolation? An audit log you can review? "Nothing" is a real answer in some shapes; that is how the OpenClaw file-deletion incident happened.
Vetted catalog vs open marketplace
The two dominant patterns:
Vetted catalog. The vendor curates the available skills. Each one is reviewed before shipping. The catalog is smaller; safety is higher. Examples: Apple's App Store (slow review, low malware rate), Ajeris's built-in tool catalog.
Open marketplace. Anyone can publish; community-driven moderation; high breadth; reactive safety. Examples: npm, PyPI, the OpenClaw skill marketplace.
Both are legitimate models for different populations. Engineers who can vet skills themselves benefit from the marketplace's breadth. Non-engineers (and engineers who do not have time to vet every skill) are safer on a vetted catalog.
What Ajeris does differently
Three structural choices that bound the skill-safety problem:
- Built-in tools are vetted before ship. No marketplace to police; we own the catalog.
- Custom MCPs are explicit. When you add a custom MCP server, you know exactly which one you added and what its bearer token is. The agent does not pull tools from a community marketplace.
- Permission scoping per tool. Each tool authorizes specific scopes; broader access is an explicit choice.
The trade-off is breadth. We do not have 13,000 skills to install. We have the vetted-and-popular ones plus your custom MCPs. For most users, this is the better trade.

What changed in 2026
Three things shifted the conversation around agent skill safety in early 2026:
The Cisco finding. A respected security research team published evidence that the marketplace contract has real supply-chain risk for users who do not vet skills themselves.
The OpenClaw file-deletion incident. Even when the skills themselves are fine, broad permissions on real infrastructure can produce catastrophic outcomes from misconfiguration alone.
The MoltMatch consent incident. A user discovered his OpenClaw agent had created a profile on an experimental platform and was screening matches without his explicit direction. The agent did not exfiltrate data; it acted in a domain the user had not specifically authorized. Different failure mode from the file deletion; same root cause: too-broad default permissions.
The collective effect: the industry shifted from "raw capability" to "bounded capability" as the framing for what users want. Ajeris's contract was already on the bounded side; it became more obviously the right shape over the year.
- 1Built-in toolVendor-vetted. Permissions documented. Scoped to your account.
- 2Custom MCPYou add it explicitly with the URL and bearer token. Permissions scoped.
- 3Approval gatingConsequential actions queue. You authorize.
- 4Audit trailEvery action logged. You can review at any time.
- Anyone publishes; community moderates after.
- Breadth is high; vetting is reactive.
- User responsible for checking each skill.
- Cisco-found data exfiltration is the worst-case skill.
- Best for engineers with operational competence.
- Vendor curates the built-in catalog.
- Breadth is narrower; vetting is pre-shipping.
- Custom MCPs are explicit and scoped.
- No marketplace skills to police.
- Best for non-engineers and bounded use cases.
Frequently asked
Are open-source agent skills always unsafe?
Can I bring custom MCPs to Ajeris?
What about my engineering-savvy partner who self-hosts?
How does Ajeris vet built-in tools?
What if I really want a third-party skill?
Try it
Free to start. Text +1 (470) 821 4265. The contract is bounded by design; you authorize what the agent can do.
For the head-to-head comparison with the open-marketplace contract, see Ajeris vs OpenClaw.


