The AI artifact is the supply chain

For the last eighteen months, the AI security conversation has orbited two words: prompt injection. It is a real threat and security teams are right to care about it. But prompt injection is a runtime concern. It describes what happens in a single model call, on a single conversation turn, against a single user.

The actual attack surface that has emerged in 2025 and 2026 is not runtime. It is persistent. It lives in the files developers check into git, the MCP servers they install, the skills they download from a marketplace, and the rule files that sit in their repo root telling every AI agent how to behave. These are artifacts, and they form a supply chain with the same shape as npm or PyPI.

What counts as an AI artifact

An artifact is any persistent piece of content that changes agent behavior at runtime and was authored by someone other than the person running the agent. The specific ones we see in customer environments:

• Anthropic Skills — directory-structured capability bundles distributed via the Anthropic skills marketplace and private registries. A skill is Markdown plus executable code.
• MCP servers — Model Context Protocol implementations that expose tools, resources, and prompts to any MCP client (Claude Desktop, Cursor, Zed, Windsurf). Most are distributed as unsigned npm packages or binaries.
• IDE rule files — .cursorrules, agents.md, .windsurfrules, .github/copilot-instructions.md. Plain text files that are loaded as system prompts on every agent invocation in that repo.
• Custom GPTs and Claude projects — hosted configuration that bundles a system prompt with a set of tools, uploaded files, and connected services.
• Agent configuration repos — LangChain, CrewAI, and LlamaIndex agents often ship as entire repositories where the prompt, the tool definitions, and the orchestration logic are all checked in.

Every one of these properties:

1. Is authored elsewhere and imported.
2. Has a publishing mechanism (marketplace, registry, GitHub org).
3. Is executed inside a trust boundary — your IDE, your developer's shell, your agent's credentials.
4. Persists across invocations — it's not a one-shot prompt, it runs every time.

That is the definition of a dependency.

npm in 2018, again

In 2018, npm was hitting the tipping point where the weekly cadence of supply chain compromises finally broke through to general security awareness. event-stream, getcookies, flatmap-stream, the ua-parser-js incidents — none of them were zero-days in Node itself. They were authored-elsewhere code running inside a trusted boundary. The fixes that emerged — dependency auditing, lockfile discipline, scoped publishing, registry-level policy — were not about patching Node. They were about treating the dependency as the new attack surface.

We are at that tipping point for AI artifacts now.

The parallels are not loose.

• Typosquatting. Skills and MCP servers published to registries with names one character off from legitimate ones. We catalog the specific families we've seen at intel.jiffylabs.app.
• Dependency confusion. Private skill names getting shadowed by public ones when a tool resolves against a broader registry set.
• Post-install hooks. Skills with initialization code that runs on first load and makes unauthenticated outbound calls.
• Capability sprawl. The MCP equivalent of transitive dependencies: one MCP server pulls in another, which pulls in another, and none of it is enumerated.
• Secret exfil in config. Plaintext API keys in mcp.json files committed to developer dotfiles, lifted in a single git log.

Why runtime defenses miss this

A runtime AI firewall or DLP proxy inspects model input and model output. It is a necessary layer and we are not arguing against it. But the threat model here is not a user sending something bad to a model. The threat model is a trusted agent, with legitimate credentials, loading an artifact and doing exactly what the artifact tells it to do.

The artifact is part of the agent's identity. By the time the runtime proxy sees the behavior, it sees:

• An authenticated session.
• A legitimate tool call.
• A plausibly-formatted request to a domain that the artifact author registered last week.

The runtime layer cannot tell the difference between a skill that legitimately needs network access and a skill that's exfiltrating a customer list. You cannot answer that question at runtime. You have to answer it on ingest, before the artifact gets loaded.

What "scanning" actually means for artifacts

Scanning an artifact is not the same as scanning source code. Source code scanners assume the code will be compiled, executed by a single process, and observed through standard telemetry. Artifacts are different:

• They are prompt + code + config combined, and the prompt part can carry the attack.
• They run under the agent's credentials, not the artifact author's.
• They can spawn sub-agents or invoke other tools, so a single artifact's blast radius is the blast radius of everything transitively reachable from it.
• They frequently ship with explicit network capability, which makes "ever make a network call" not a useful heuristic.

A real artifact scanner needs to do at minimum:

1. Static signature matching against known-bad patterns (credential regex, suspicious network targets, tool-call smuggling constructs). We publish our catalog openly at intel.jiffylabs.app.
2. Heuristic analysis of the prompt portion for jailbreak, override, and sub-agent-spawn patterns.
3. Sandboxed execution of any code path triggered during initialization, with full network and filesystem telemetry.
4. Cross-ecosystem dedupe — the same malicious skill shows up on Anthropic marketplace, GitHub, and Hugging Face under three different names.
5. Confidence scoring — binary "malicious / not" is useless; security teams need a tier.

We walk through exactly how Jiffy does these steps in our technical overview post.

Getting started

If you operate an engineering org that uses AI agents — and at this point that is most engineering orgs — the minimum viable program is:

1. Inventory. What skills, MCP servers, and rule files exist across your repos, developer machines, and AI subscriptions. If you cannot answer this in a week, that is your real exposure.
2. Block the known-bad. Feed the Jiffy intel catalog or an equivalent into whatever policy layer you have (MDM, Zero Trust, git pre-commit).
3. Scan on ingest. Any new artifact, scan before it loads. Any update, re-scan.
4. Publish an artifact SBOM. You publish one for containers. Publish one for AI.

This is a tractable program. The reason most organizations don't have it yet is that the category has not been named. We think that matters, so we are naming it: AI artifacts are the supply chain. Scan accordingly.

Further reading from this site:

• MCP security: a security team's field guide
• Scanning AI skills at scale: what we learned
• .cursorrules and agents.md: the config backdoor
• OWASP LLM Top 10 is not enough