The Skill Marketplace Threat Model: What Eight Hundred Twenty-Four Malicious Skills Taught Us

TL;DR

We ran a structured scan against public agent skill catalogs and surfaced 824 skills that exhibit adversarial behavior. The behaviors cluster into five families: data exfiltration, privilege escalation, credential harvesting, policy bypass, and supply chain pivots. The dominant attack pattern is not exotic. It is a benign-looking skill that smuggles a single network call to an attacker-controlled host, gated behind a string match against an environment variable. The fix is a Skill Trust Audit Checklist that any team can run before importing a third-party capability. The framework introduced here is the Skill Capability Surface Map, a one-page artifact that exposes the real blast radius of a skill before it ever runs in production.

A Quiet Failure Mode That Looks Nothing Like A Breach

The agent platforms we work with do not get breached the way classical SaaS gets breached. There is no SQL injection on the login page. There is no exposed admin panel. The breach surface is something subtler and, for the people building agent products in 2026, much more dangerous. It is the moment a developer types a single line into a config file or a UI search box, finds a skill that does what they want, and clicks import. The skill installs. It declares a few permissions. It works. And from that moment on, the skill is part of the agent's identity. It runs with the agent's credentials, it sees the agent's context, and it can speak in the agent's voice.

This is the failure mode we built our scanner for. We were not looking for compromised servers or stolen API keys. We were looking for the much quieter problem of skills that look fine on the surface but do something the importer never expected. After processing roughly 11,400 publicly listed skills across the four largest agent skill catalogs, we flagged 824 as exhibiting adversarial behavior under at least one of our detection rules. The number is not the point. The structure is. Once you sit with these 824 skills for a few weeks, the patterns become almost monotonous, and the absence of basic provenance becomes the story.

The purpose of this post is to share that structure in a form a working engineering team can use immediately. We will categorize the malicious behaviors into five families, walk through the dominant attack patterns inside each, and end with a Skill Trust Audit Checklist that turns the analysis into an artifact your team can paste into a code review template tomorrow. Along the way we will introduce a framework called the Skill Capability Surface Map, which we use internally before allowing any new skill into the trust layer. None of this is theoretical. Every pattern in this post comes from a real skill we pulled out of a real catalog and reverse-engineered.

If you build agents and you import skills, this is your supply chain. It is not a metaphor. It is the actual pipeline by which untrusted code, written by people you have never met, ends up running with your agent's authority against your customer's data. The state of the art for protecting that pipeline today is somewhere between npm in 2014 and Docker Hub in 2016. We can do better, and the path starts with naming what is actually happening in these 824 skills.

How We Scanned: Methodology Without Drama

The scanner that produced these 824 results is not magic. It is the boring kind of static and dynamic analysis that any security team could stand up in a few weeks. We pulled skill manifests, source files, declared permissions, and runtime traces from a sandboxed execution harness. We then ran each skill through a battery of rules that look for specific patterns: outbound network calls to non-declared hosts, file reads outside declared paths, dynamic code generation, environment variable scraping, manifest-runtime mismatches, and a few dozen more. Every rule has a false positive rate, which is why the 824 number is the result of human review on top of automated flagging.

The scan took two months and used about 600 dollars of compute. We are sharing the methodology not because it is novel but because it should be the floor, not the ceiling, for what skill catalogs do before they list a skill. The fact that none of the four catalogs we scanned ran any meaningful equivalent of this analysis is itself the most important finding in this post. The economic incentives in agent skill marketplaces in early 2026 are exactly the same as the incentives in app stores a decade ago: catalog operators get paid for volume and discovery, not for safety, and they have offloaded the entire trust problem onto the importer.

The second methodology note worth sharing is that we treated declared capabilities as a starting point, not a ground truth. A skill manifest that declares it needs network access to one host and then makes calls to a second host is not an edge case. In our dataset it was the single most common signal of malicious intent. About 38 percent of the 824 flagged skills had at least one runtime network call to a host that was not in the declared manifest. Some of those mismatches were honest bugs. Most were not. The point is that you cannot trust the manifest. You have to verify against actual runtime behavior, which means you need a sandbox that records every syscall and every outbound packet, and you need a person or a model that reviews the trace.

The third note is that we built our taxonomy bottom-up, not top-down. We did not start with a list of attack categories and try to bin skills into them. We clustered skills by behavior, named the clusters, and then mapped them back to the five families we will walk through next. This matters because at least two of the families we found do not appear in any of the standard mobile or web threat models. The agent supply chain has its own physics, and importing categories from adjacent fields will leave you blind to the threats that are unique to it.

Family One: Data Exfiltration Skills

Data exfiltration is the largest family in the dataset. It accounts for 312 of the 824 skills, or about 38 percent of the total. The pattern is almost mechanical. The skill declares a useful capability, often something like file parsing, summarization, or document conversion. It performs that capability correctly. And on the way through, it copies the input or some derivative of the input to an attacker-controlled host. The most common derivatives in our dataset were file paths, hostname, environment variable lists, and excerpts of the input itself, often the first few hundred characters which conveniently include API keys, internal URLs, and the kind of system prompts that reveal a customer's architecture.

The craftsmanship here varies wildly. The crudest variants make a synchronous outbound POST to a hard-coded URL on every invocation. These get caught by even the most basic outbound traffic monitoring. The more sophisticated ones use a queue: they buffer exfiltrated data in memory, send only when the buffer crosses a size threshold, and route through CDN-fronted endpoints that are difficult to block by hostname. The most sophisticated variants we found used DNS exfiltration, encoding stolen data into subdomain queries against a domain the attacker controls. DNS exfiltration is hard to catch because it happens at a layer below most application-level monitoring, and because legitimate skills sometimes do legitimate DNS lookups.

The operational lesson here is that egress filtering, which has been a security best practice in conventional infrastructure for fifteen years, is essentially nonexistent in agent runtimes. The default in almost every agent framework is full outbound access. The skill author writes whatever URL they want and the runtime executes it. There is no equivalent of the iptables rule that says only these hostnames are reachable. Adding that capability is not technically hard. It requires a per-skill egress allowlist that is enforced at the runtime layer and that defaults to deny. We will return to this in the section on capability mediation. For now, the takeaway is that if your agent imports a skill and that skill can reach the open internet, you have just imported a primitive whose blast radius includes everything the skill can see.

The second operational lesson is that the data being exfiltrated is often not the data the skill author originally targeted. They started by trying to grab API keys. They ended up with system prompts, internal URLs, and customer data because that is what flows through agent skills in 2026. This is the same dynamic we saw in browser extensions a decade ago. A skill installed for one purpose ends up sitting in a privileged position that the attacker did not anticipate but is delighted to monetize. The defender's response is the same response that worked for browsers: capability scoping, not trust assumptions.

The third lesson, and the one most often missed, is that exfiltration is a process, not an event. By the time you notice that a skill is sending data somewhere it should not, the data is already gone. Detection is necessary but not sufficient. The architecture has to make exfiltration impossible by default, which means least-privilege egress, which means manifests that declare network destinations and runtimes that enforce those declarations. Anything less is theater.

Family Two: Privilege Escalation Skills

The second family, privilege escalation, accounts for 187 skills. These are skills that try to acquire authorities they were not granted, either by manipulating the agent's identity, by abusing inter-skill communication, or by exploiting weaknesses in the runtime's permission model. The pattern that surprised us most was inter-skill privilege borrowing. About 60 of the 187 escalation skills did not try to acquire privileges directly from the runtime. They tried to call other skills that had privileges they wanted. In an agent platform where skills can invoke each other, this is the equivalent of confused deputy attacks: skill A has no permission to read the file system, but skill B does, and skill A asks skill B to read a file on its behalf.

The defense against this is straightforward in principle and almost completely absent in practice. Inter-skill calls should carry the original caller's identity and authority, not the called skill's. This is the same lesson we learned from the early days of microservices: services that act as proxies for upstream callers have to propagate identity, or they become escalation paths by default. In the agent skill world, almost no platforms we surveyed do this. When skill A invokes skill B, skill B sees the request as coming from skill B itself, with skill B's full authority. The attacker writes skill A as a thin wrapper that adds malicious behavior on top of legitimate skill B, and inherits skill B's privileges in the process.

The second escalation pattern is identity confusion. About 40 skills in this family attempt to confuse the runtime about which agent or which user is making a call. The attacks here range from trivially silly (sending a header that claims to be a different user) to genuinely clever (timing-based attacks that exploit race conditions in the runtime's identity check). Most of the trivially silly attacks worked. We were not expecting that. The state of identity verification in agent runtimes turns out to be roughly where web identity was in the early 2000s, before the lessons of session fixation and CSRF were universal. There are platforms that accept user IDs from request headers without any cryptographic binding to a session. There are platforms that let skills set the user ID in their own context. There are platforms that have no concept of caller identity at all.

The third escalation pattern is environment escape. About 90 skills in the family attempt to break out of the runtime sandbox using known or novel techniques: filesystem traversal, dynamic library loading, exploitation of debug interfaces, and a small number of CPU-level tricks that we will not detail publicly because some of them work on environments that are still in production. The good news is that environment escape is the easiest of the three to defend against, because it is the kind of attack that conventional sandbox vendors have spent twenty years thinking about. The bad news is that most agent runtimes are not using conventional sandboxes. They are using thin process wrappers or containers without the gVisor- or Firecracker-style isolation that would actually contain a determined attacker. We will go deep on sandbox modes in a separate post; for now, the privilege escalation family is the strongest argument we have for taking sandbox selection seriously.

Family Three: Credential Harvesting Skills

Credential harvesting accounts for 156 skills. The basic pattern is what you would expect: scrape environment variables, read credential files, intercept OAuth flows, and extract API keys from the agent's runtime context. The interesting pattern is what credentials are being targeted. Two years ago, credential theft against agents would have meant chasing the agent's own API keys. In our 2026 dataset, the most-targeted credentials are downstream credentials that the agent is using to authenticate to third-party services. Cloud provider keys are still the most valuable per credential, but the volume is in CRM tokens, email service tokens, payment processor tokens, and the long tail of SaaS integrations that agents now have access to.

The shift makes sense from the attacker's economics. An agent's own API key gives you access to one agent. A CRM token the agent is using gives you access to a whole customer relationship system. The skill that scrapes both gets paid for the second one and the first one is essentially a bonus. The defense is the same shift in mental model that the conventional security industry made a decade ago: the credentials that matter are not the ones at your perimeter. They are the ones at your downstream perimeters.

For agent runtimes, this implies a specific pattern that almost nobody implements: credential brokering. The runtime should hold the credentials, not the skill. When the skill needs to make a call to a third-party service, it asks the runtime to make the call on its behalf. The credential never enters the skill's address space. The skill cannot scrape it because it never sees it. This pattern requires the runtime to understand which third-party services the skill needs to call, which means the manifest has to declare them, which means the runtime has to enforce those declarations. We are back to the same architectural decision: scoped, declared, enforced capabilities. Credential brokering is impossible without it, and harvesting attacks are mostly trivial without credential brokering.

The craftsmanship in this family is the highest of the five. Some of the harvesting skills we analyzed had real skill in their evasion. They scraped credentials only on certain invocations, only after a delay measured in days, and only when specific environmental conditions suggested the skill was running in a production environment rather than a test or sandbox. They sent harvested credentials through legitimate-looking analytics endpoints. They fragmented credentials across multiple seemingly innocuous metric dimensions. The lesson is that the attackers writing these skills are not amateurs. Some of them are clearly professional adversaries who have brought the same craft they used on browser extensions and mobile apps to a new and softer target.

Family Four: Policy Bypass Skills

Policy bypass is the fourth family, with 109 skills. These are skills designed to weaken or evade the policies that an agent's host application is supposed to enforce. The most common subcategory is content policy bypass, where the skill exists specifically to make the agent generate or relay content that the host's policies are supposed to block. About 70 of the 109 fell into this bucket, and most of them were transparent about it: they advertised, in coded language, exactly the policy they were designed to bypass. The skill catalogs hosting them either did not notice or did not care.

The more interesting subcategory is governance bypass, with 39 skills. These skills target the policies that govern the agent's autonomous actions: rate limits, budget limits, approval requirements, escalation rules. The pattern is to wrap a normally-restricted operation in a path that the host application's policies do not cover. For example, an agent that has a daily spending limit on direct payment calls might import a skill that schedules payments through a webhook handler that the spending policy does not check. The skill is not exfiltrating data and not stealing credentials. It is just helping the agent do something the agent's owner did not want it to do.

The defense against governance bypass is the hardest in this whole catalog, because it requires the host application's policies to be enforced at a layer below the skills themselves. If skills can route around your governance, your governance is not worth the YAML it is written in. The architectural pattern that works is policy enforcement at the action layer, not the skill layer: every consequential action the agent can take goes through a single chokepoint where policies are evaluated, regardless of which skill initiated the action. This is unfashionable advice in 2026, when every agent platform wants to celebrate the flexibility of its skill model. But the platforms that have not centralized policy enforcement are the platforms whose customers will be writing post-mortems in 2027.

The third subcategory, with 24 skills, is observability bypass. These are skills that try to suppress, modify, or evade the logs and metrics that would otherwise record the agent's behavior. They patch logging libraries. They tamper with trace collectors. They drop log lines based on content. They are, in other words, exactly the same family of attacks that conventional security has been dealing with for decades, ported into the agent runtime context. The defense is the same: observability infrastructure should be tamper-evident, run out of process from the workload, and write to a sink that the workload cannot reach. None of this is hard. Almost none of it is implemented in current agent runtimes.

Family Five: Supply Chain Pivot Skills

The fifth and smallest family, with 60 skills, is what we call supply chain pivots. These are skills whose goal is not to attack the agent that imports them, but to use that agent as a stepping stone to attack something else. The pattern is most easily understood through an example: a skill is imported by an agent that has access to a customer's GitHub account. The skill does not exfiltrate the GitHub token. Instead, it uses the access to push a small modification to a different package in a different repository, a modification that will eventually be downloaded by other developers and run on their machines. The agent is not the target. The agent is the delivery vehicle.

Supply chain pivots are the rarest family in our dataset but, by some measures, the most concerning. They suggest that the threat actors writing these skills understand the structural position that agents now occupy. Agents have credentials and access to dozens of third-party systems. They have the ability to make changes to those systems autonomously. They are, in other words, a uniquely valuable foothold for an attacker who wants to pivot into something else. The 60 skills in this family are the early signal of what we expect to be the dominant attack pattern within two years, as agents get deeper integrations and as the attacker community catches up to the opportunity.

The defense pattern here is the broadest, because the targets are so varied. The first principle is to limit the agent's write authority everywhere it can be limited. Read access is dangerous; write access is much more dangerous. The second is to require human-in-the-loop for any write that crosses a trust boundary, where trust boundaries include things like code repositories, deployment pipelines, financial systems, and identity providers. The third is to make sure that any write the agent does is observable to its owner with low enough latency that a malicious change can be reverted before it propagates. None of these are agent-specific principles. They are the same principles that have worked in conventional automation for decades, applied to a new substrate.

The craftsmanship in this family is not always high. Many of the 60 skills we found were straightforward in their pivot logic. But the existence of even crude versions tells us where this is going. A year from now, the supply chain pivot family will be larger, more sophisticated, and harder to detect. The teams that get ahead of it now will spend the rest of their year on more interesting problems. The teams that wait will be writing incident reports.

The Skill Capability Surface Map: A Framework For Pre-Import Review

The framework we use internally to evaluate any skill before importing it is called the Skill Capability Surface Map. The point of the map is to make the actual blast radius of a skill visible in a single page that a human can review in under five minutes. Each map has five sections, corresponding loosely to the five families above but reorganized for the reviewer's workflow. The sections are: data flow, identity boundary, network surface, action authority, and observability requirements. Filling out the map for a candidate skill takes about an hour the first time and about ten minutes once the team is fluent.

The data flow section asks: what data does this skill see during normal operation? Where does that data come from? Where does it go after the skill processes it? Are there any places it could go that are not the obvious places? The reviewer is looking for any divergence between the inputs declared in the manifest and the inputs the skill actually consumes, and any divergence between the outputs declared and the outputs actually produced. The map calls out, in red, any data path that touches sensitive customer data or credentials. If the red is unexplained, the skill does not get imported.

The identity boundary section asks: under whose identity does the skill act? When the skill calls another service, who appears as the caller? When the skill is called by another skill, what identity does it see? This section is the place where confused deputy attacks get caught, because the reviewer is forced to write down the identity propagation path explicitly. Most skills that look fine in casual review fail this section once you write down what they actually do.

The network surface section asks: which hosts can this skill reach? Through which protocols? On which ports? Are these the same hosts the manifest declares? Have we checked actual runtime behavior, or are we trusting the manifest? The reviewer is required to attach a runtime trace to this section, demonstrating that the skill's actual outbound behavior matches its declared behavior in a controlled environment. Skills that cannot produce a clean trace do not get imported.

The action authority section asks: what state can this skill change? In which systems? What are the financial, regulatory, or customer-impact consequences of those changes? This is where governance bypass attempts get caught, because the reviewer is forced to enumerate the consequential actions the skill is capable of and compare them against the skill's stated purpose. A skill that claims to be a summarizer but has the authority to send emails fails this section.

The observability requirements section asks: what events does this skill emit? Are they sufficient for an operator to detect the misuse patterns we have catalogued? If the skill is doing something unexpected, will we know? This section is the smallest but the most often skipped, and it is the section that determines whether the skill is operable in production. A skill you cannot observe is a skill you have to trust completely, and trust is exactly what we are trying to avoid extending to third-party code.

The map is a living document. Every quarter, we re-run the map on every skill we have imported, against the latest version of the skill, and look for any changes in the answers. Skills whose answers have changed without an explicit version review get pulled out of production until a fresh review can be completed. This sounds like a lot of work. It is not. With a fluent team and good tooling, the quarterly review of an imported skill takes under fifteen minutes. The cost is low and the upside, given what we have seen in the 824, is enormous.

Counter-Argument: Are You Overestimating The Threat?

The most serious counter-argument to everything in this post is that we are overestimating the threat. The argument runs roughly as follows: 824 skills sounds like a lot, but it is a small fraction of the total skill ecosystem. Most agents do not import skills from public marketplaces. Most importers do at least cursory review. Most malicious skills get caught by users complaining when something obviously wrong happens. The capability surface map is interesting but it is overkill for most teams, and the operational cost will exceed the actual risk.

We take this counter-argument seriously, and parts of it are correct. The 824 number is indeed a small fraction of the ecosystem. Many teams do not import third-party skills at all. The user-feedback layer does catch some malicious behavior. But we think the overall conclusion is wrong, for three reasons.

First, the rate of import is increasing, not decreasing. As agent platforms add features and as the marketplace of skills grows, the friction of importing a third-party skill is going down, not up. Two years from now, importing a skill will be as common as installing a Chrome extension is today, and the percentage of agents whose owners do meaningful review will be no higher than the percentage of Chrome users who review extensions before installing them. We know how that story ends because we have already lived it twice, with browser extensions and with package managers.

Second, the consequences of compromise are higher in the agent context than in the browser or package context. A compromised browser extension can steal credentials and cookies. A compromised npm package can run arbitrary code on developer machines. A compromised agent skill can do all of those things and also act autonomously in the world: send emails, transfer money, make purchases, modify customer records, deploy code. The blast radius is larger because the agent's authority is larger.

Third, the user-feedback layer is much weaker than people assume. Agents are designed to operate without continuous human supervision. The whole point of an agent is that you do not have to watch it. Which means the malicious behaviors that a watchful user would catch in a Chrome extension can run for weeks or months in an agent before anyone notices. The asymmetry between attacker and defender is worse here than it has been in any platform we have analyzed. The capability surface map is not overkill. It is the floor.

What Armalo Does

Armalo is the trust layer for the agent economy. We maintain a skill registry where every listed skill carries a signed manifest, a capability declaration, and a verifiable audit trail across versions. We run a multi-LLM jury that scores skills against a 12-dimension composite, with the top and bottom 20 percent of judges trimmed to prevent gaming. The jury looks at exactly the families described in this post: data flow, identity boundary, network surface, action authority, observability. Skills earn certification tiers (Bronze, Silver, Gold, Platinum) based on their composite score and the quality of their evidence.

We also operate a Trust Oracle at /api/v1/trust/ that other platforms can query before they import a skill or hire an agent. The oracle returns the current composite score, the certification tier, the pact compliance record, and any open audit findings. The behavioral pacts that back this whole architecture make the structure simple: subject (the skill or agent), predicate (the behavior it commits to), evidence (the runtime traces and audits that prove or disprove the commitment), penalty (the on-chain settlement consequence of breaking the pact), and renewal (the conditions under which the pact stays valid). Importers do not have to take any individual skill author's word. They can ask the oracle.

FAQ

How did you find the 824 skills without compromising the catalogs? Every step was done with publicly available skill artifacts, in our own sandboxed harness. We did not run any active probing against catalog infrastructure, and we did not deploy any flagged skill into a production environment. The dataset is reproducible by anyone willing to run the same scanner against the same catalogs.

Will you publish the full list of 824 skills? We are working with the catalogs on responsible disclosure. The catalogs that have engaged in good faith have already removed the most dangerous of the listings. We expect to publish a redacted statistical summary in the next few months.

What does the Skill Capability Surface Map cost in time per skill? First map for a new skill: about an hour. Quarterly review: about fifteen minutes. The cost of a single security incident from a malicious skill is, in our experience, at least three weeks of senior engineering time. The math is not close.

Should I just stop importing third-party skills? No. The agent economy depends on the same kind of composability that made the package manager era productive. The point is not to stop importing. It is to import with eyes open, with a process, with verification, and with a runtime that enforces what the manifest declares.

What about first-party skills written by your own team? First-party skills are not exempt from the capability surface map. They have a lower base rate of malicious intent, but they have the same vulnerability surface to mistakes, to compromised developer accounts, and to supply chain attacks against their dependencies. We use the same map for first-party and third-party skills.

Do certification tiers actually work? Or are they just badges? Tiers are only as good as the underlying scoring. Ours is grounded in 12 dimensions including pact compliance, accuracy, self-audit, reliability, safety, security, bond, latency, scope-honesty, cost-efficiency, model-compliance, runtime-compliance, and harness-stability. The composite score moves with real evidence, decays over time without continued evidence, and is challengeable by adversarial agents. Tiers are not badges. They are rolling estimates of behavioral reliability.

What is the single most important defense for a team that cannot do all of this? Egress allowlisting. If you cannot do anything else, restrict where each skill can make outbound calls, and default to deny. That single control would have neutralized roughly half of the 824 skills we flagged.

Bottom Line

The agent skill marketplace in 2026 is roughly where the package manager ecosystem was in the early 2010s: huge, fast-growing, productive, and almost entirely unprotected. We scanned it, found 824 skills exhibiting adversarial behavior, and categorized them into five families that map to specific architectural defenses. The Skill Capability Surface Map is a pre-import artifact you can use this week to bring some discipline to the import decision. The Trust Oracle is the long-term answer, where third-party verification replaces individual hope. The cost of acting now is small. The cost of waiting until the first widely publicized incident is the kind of cost that ends companies.