DEF CON 34 — Part 4

Models, loaders, skills and repositories are becoming initial-access vectors

By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.

For most of the software era, security teams learned to distrust executable artifacts.

• We scan binaries.
• We inspect packages.
• We verify container images.
• We analyze dependencies.
• We sign releases.
• We protect build pipelines.

And beneath all of those controls sits a remarkably persistent assumption:

Data is safer than code.

A JPEG may contain an exploit for a vulnerable parser. A PDF may trigger a vulnerability. A serialized object may abuse a loader. But conceptually, we still tend to separate the world into two categories:

things that execute and things that are consumed.

Artificial intelligence is making that distinction increasingly unreliable.

• A model is consumed.
• A checkpoint is loaded.
• A Skill is installed.
• A repository is cloned.
• A configuration file is read.
• A context document is interpreted.

None of those actions sounds equivalent to executing an unknown binary.

Increasingly, however, they can produce exactly that security consequence.

That is why one of the most important supply-chain lessons emerging from DEF CON 34 is not specifically about machine learning.

It is about execution.

The AI ecosystem is creating new ways for organizations to execute attacker influence before the application they intended to run has even started doing useful work.

The new security assumption should therefore be:

Loading an AI artifact is increasingly an execution decision, not merely a data decision.

And that fundamentally changes where the software supply chain begins.

We Built Supply-Chain Security Around the Wrong Boundary

Traditional software supply-chain security has a relatively understandable architecture.

An organization obtains source code and dependencies.

Those components enter a build system.

The build system produces an artifact.

The artifact is deployed.

The application executes.

The simplified chain looks like this:

Package → Build → Application → Runtime

Security controls accumulated around that sequence.

Software composition analysis examines dependencies.

Repository security protects source.

CI/CD controls protect builds.

Artifact signing protects releases.

Container scanning protects images.

Runtime security protects execution.

The entire architecture implicitly assumes that execution occurs near the end of the chain.

AI systems complicate that assumption.

Modern AI environments introduce at least two additional supply chains:

Model supply chain

Model → Loader → Inference Runtime

and:

Agent supply chain

Repository → Configuration → Skill → Agent → Tool

The dangerous part is not merely that these chains exist.

It is that they increasingly intersect.

A repository can instruct an agent.

The agent can install dependencies.

A Skill can invoke a script.

The script can load a model.

The model loader can contain a vulnerability.

The resulting process can inherit developer credentials.

The developer environment may have access to CI/CD.

CI/CD may have cloud identities.

The cloud identity may reach production.

What initially looked like:

“Download an AI artifact.”

can therefore become:

Artifact → Interpreter → Execution → Identity → Infrastructure

That is no longer an AI governance problem.

It is an initial-access problem.

The Model File Is Not Necessarily a File

Machine-learning engineers naturally think of models as data.

Weights.

Parameters.

Tensors.

Architecture definitions.

Metadata.

From a mathematical perspective, that description makes sense.

From a security perspective, it can be dangerously incomplete.

The model has to be loaded.

And the loader is software.

That means the security boundary is not:

Can this model contain malware?

The more useful question is:

What happens when our infrastructure interprets this artifact?

CVE-2026-24747 provides an unusually clean illustration.

The vulnerability affected PyTorch versions before 2.10.0. According to the NVD description, an attacker could construct a malicious .pth checkpoint capable of corrupting memory and potentially achieving arbitrary code execution when loaded using torch.load(..., weights_only=True). (⁠NVD)

That detail matters because weights_only exists precisely in the conceptual territory where engineers expect reduced risk.

The artifact is supposedly being treated as weights.

Yet the boundary between model data and execution is ultimately implemented by software — and software parsers themselves have attack surfaces.

The vulnerability is categorized under both deserialization of untrusted data and improper control of code generation, and the published CVSS 3.1 score is 8.8. (⁠NVD)

This is not merely another PyTorch vulnerability.

It exposes the larger architectural issue.

Organizations increasingly download artifacts from model repositories and then allow highly privileged infrastructure to interpret them.

That infrastructure may include:

GPU clusters.

Inference servers.

MLOps platforms.

developer workstations.

training environments.

cloud workloads.

model evaluation pipelines.

automated deployment systems.

The question for a CISO should therefore not stop at:

Where did the model come from?

It must continue:

What interprets it, and what authority does that interpreter possess?

The Model Hub Is Becoming a Package Repository

There is a useful historical analogy here.

Twenty years ago, many organizations underestimated software package repositories.

A developer needed a library.

They downloaded it.

They imported it.

Eventually the industry understood that dependency ecosystems were not simply developer conveniences.

They were distribution infrastructure for executable trust.

That realization produced an entire security discipline around software supply chains.

Model ecosystems are moving through a similar transition.

A model hub looks like a repository of mathematical artifacts.

Operationally, however, organizations increasingly treat it as an input into automated infrastructure.

Models are:

discovered,

downloaded,

cached,

converted,

loaded,

evaluated,

fine-tuned,

deployed,

and sometimes dynamically replaced.

The supply chain therefore increasingly resembles:

Publisher
↓
Model Registry
↓
Artifact
↓
Loader
↓
Conversion / Evaluation Pipeline
↓
Inference Runtime
↓
Enterprise Data and Infrastructure

The model artifact may be malicious.

The metadata may be manipulated.

The loader may be vulnerable.

The conversion tooling may execute unexpected code.

Dependencies may be compromised.

The runtime may have excessive privileges.

And automation may make the entire chain occur without meaningful human review.

This is why provenance alone cannot solve the problem.

A cryptographic signature can tell you:

This is the artifact the publisher released.

It cannot tell you:

This artifact is safe to interpret inside your environment.

Those are fundamentally different security properties.

ModelShield and the Emergence of AI Artifact Inspection

The growing interest in model-scanning systems such as ModelShield reflects recognition of this problem.

The underlying idea is strategically important even beyond any particular implementation.

Organizations already inspect:

packages,

containers,

binaries,

documents,

dependencies,

and infrastructure templates

before allowing them into trusted environments.

AI artifacts increasingly require the same treatment.

But model security creates an additional difficulty.

There may be multiple layers of interpretation.

A model can be compressed.

Serialized.

Wrapped in an archive.

Converted between formats.

Bundled with code.

Accompanied by configuration.

Referenced by a repository.

Loaded through framework-specific logic.

Security inspection therefore has to answer more than:

Does this file contain known malicious code?

It needs to understand the entire loading path.

That suggests a more useful model:

Artifact Risk = Content Risk × Interpreter Risk × Runtime Authority

A benign artifact processed by a vulnerable interpreter can be dangerous.

A malicious artifact processed by a secure but overly permissive runtime can be dangerous.

A vulnerable loader running inside an isolated sandbox may have limited impact.

The risk emerges from the composition.

Again, the attack surface is becoming the system.

But Models Are Only One AI Supply Chain

This is where the DEF CON 34 findings become particularly important.

The emerging AI supply chain is not simply:

“software supply chain, but with models.”

Agents introduce something different.

They distribute behavior.

Consider a Skill.

A Skill may contain natural-language instructions telling an agent:

• when it should activate,
• what resources it should access,
• which tools it should use,
• which scripts it should execute,
• how it should interpret results,
• and what actions it should take next.

That means a Skill occupies an uncomfortable space between:

• documentation,
• configuration,
• software,
• and policy.

Research published in 2026 has already shown how serious this ecosystem can become. One large-scale empirical study behaviorally examined 98,380 third-party agent skills and confirmed 157 malicious skills containing 632 vulnerabilities. The researchers describe two broad attacker archetypes: skills designed to steal data and skills designed to hijack agent behavior. (⁠arXiv)

Separate research has demonstrated supply-chain poisoning in coding-agent skill ecosystems where malicious behavior is embedded in code examples and configuration templates that agents subsequently reuse during otherwise legitimate work. (⁠arXiv)

That changes the meaning of an instruction file.

It is no longer necessarily documentation for the human.

It may be operational input for the machine.

DEF CON’s MalSkills Demonstration Makes the Problem Concrete

One DEF CON 34 Demo Lab made this conceptual shift unusually visible.

The MalSkills demonstration explored malicious natural-language instructions planted inside AI agent Skill systems.

One attack hid an instruction inside an otherwise legitimate Skill that caused .env files to be exfiltrated when the Skill was executed.

Another chained five individually benign Skills into an emergent exfiltration path.

A third demonstrated persistence by causing malicious behavior to propagate into agent memory, allowing it to survive deletion of the original Skill and session restarts. (⁠defcon.outel.org)

The second scenario is particularly important for this series.

Five components can each appear acceptable.

Yet their composition creates the attack.

That is almost a perfect illustration of the DEF CON 34 thesis:

The malicious property may not exist inside a component. It may exist only inside the relationship between components.

Traditional supply-chain security is not well designed for that.

A scanner asks:

• Is package A malicious?
• Is package B malicious?
• Is package C malicious?

But an agentic system may require another question:

What behavior emerges when A causes B to invoke C while operating under identity D?

That is a fundamentally different analytical problem.

Natural Language Has Entered the Supply Chain

This may ultimately be the most consequential shift.

Software supply-chain security historically dealt with artifacts whose behavior was relatively explicit.

Source code has syntax.

Packages contain executable logic.

Build scripts contain commands.

Binaries contain machine instructions.

Agent systems introduce something much less deterministic:

natural-language operational instructions.

A sentence can influence tool selection.

A README can alter reasoning.

A Skill description can affect capability discovery.

Repository instructions can change coding-agent behavior.

Documentation can become a payload carrier.

Research into semantic supply-chain attacks against Skill registries has demonstrated that SKILL.md metadata can influence discovery, selection and governance processes — meaning text that superficially resembles documentation can affect which capabilities an agent finds, trusts and loads. (⁠Hugging Face)

This creates a category of supply-chain risk that conventional application security does not naturally detect.

There may be no suspicious binary.

• No vulnerable dependency.
• No obfuscated JavaScript.
• No PowerShell.
• No shellcode.

The malicious artifact may consist largely of English.

That is an extraordinary transition.

Three Supply Chains Are Now Colliding

CISOs should therefore stop treating AI supply-chain security as a single discipline.

There are at least three interconnected chains.

1. The Software Supply Chain

Package → Build → Application

The traditional domain.

Controls include:

SCA,

SBOM,

repository security,

artifact signing,

CI/CD protection,

dependency management,

and runtime security.

2. The Model Supply Chain

Model → Loader → Inference Runtime

Controls need to include:

model provenance,

artifact inspection,

safe serialization formats,

loader hardening,

framework patching,

sandboxed evaluation,

runtime isolation,

and model registry governance.

3. The Agent Supply Chain

Repository → Configuration → Skill → Agent → Tool

Controls need to include:

Skill provenance,

instruction inspection,

capability declarations,

tool restrictions,

repository trust,

context isolation,

runtime behavioral monitoring,

and execution policy.

The problem is that enterprises will rarely operate these chains independently.

Instead:

Repository
↓
Coding Agent
↓
Skill
↓
Package Installation
↓
Model Download
↓
Model Loader
↓
Cloud Runtime
↓
Production Deployment

A compromise at almost any point can traverse into another supply chain.

The resulting attack graph becomes much larger than the original artifact.

Repository Trust Is Becoming Execution Trust

This becomes especially dangerous in developer environments.

Historically, cloning a repository was primarily understood as acquiring source code.

The risky moment came later:

when the developer built it,

installed its dependencies,

or executed it.

Coding agents can collapse those stages.

A developer clones a repository.

The agent enters the workspace.

The agent discovers project-level instructions.

Those instructions influence its behavior.

The agent activates a Skill.

The Skill invokes a tool.

The tool accesses the filesystem.

The coding agent inherits the developer’s environment.

The security boundary has moved.

Clone may now precede interpretation, and interpretation may precede explicit execution.

This means repository content itself increasingly deserves to be treated as potentially executable influence.

The distinction is subtle but critical.

A human developer reading malicious instructions can decide to ignore them.

An agent reading operational instructions may interpret them as part of its task environment.

That makes repository-level agent configuration a new class of supply-chain artifact.

The SBOM Is No Longer Enough

None of this makes the Software Bill of Materials obsolete.

It makes it incomplete.

An SBOM can tell us that an application contains:

library A,

package B,

framework C,

and dependency D.

But consider an enterprise AI agent.

We may also need to know:

Which model was loaded?

From which registry?

Which checkpoint?

Through which loader?

Which Skills were installed?

Which version of each Skill?

Which repository instructions were active?

Which MCP servers were available?

Which tools could the agent invoke?

Which identity did those tools inherit?

Which remote resources could those tools reach?

Which memory influenced the agent?

Which external context entered the reasoning process?

That starts to look less like a Software Bill of Materials.

It looks like an:

AI Execution Bill of Materials

An AEBOM would describe not merely what software exists, but what can influence execution.

That distinction is important.

For traditional applications, composition largely means code dependencies.

For agentic systems, composition can include:

code,

models,

instructions,

tools,

identities,

memory,

data sources,

and remote services.

All of them can affect behavior.

Provenance Must Expand Beyond Code

The obvious response is provenance.

That is necessary.

But provenance itself must expand.

Organizations should eventually be able to answer:

• Who created this model?
• Who signed it?
• Where was it obtained?
• Has it changed?
• Which loader interprets it?
• Who created this Skill?
• Which version is installed?
• Which scripts does it contain?
• Which capabilities does it request?
• Which repositories may activate it?
• Which tools can it invoke?
• Which network destinations can those tools reach?

OWASP’s emerging Agentic Skills guidance already points toward controls such as provenance tracking, signatures covering Skill instructions and associated resources, and transparency logs for registry operations. (⁠OWASP)

Those are useful beginnings.

But enterprises should go further.

Provenance needs to follow the authority chain.

Because knowing who supplied an artifact tells us where it came from.

It does not tell us what it can cause.

The Most Important Control Is Runtime Authority

There is a temptation to solve this problem entirely through scanning.

• Scan the model.
• Scan the Skill.
• Scan the repository.
• Scan the package.
• Scan the prompt.

That will be necessary.

It will not be sufficient.

Agent ecosystems are particularly difficult because behavior can emerge dynamically from combinations of individually legitimate components.

DEF CON’s multi-Skill attack illustrates precisely that problem. (⁠defcon.outel.org)

The strongest security boundary therefore sits further downstream.

At execution.

The system should ask:

What operation is about to occur?

Which artifact influenced it?

Which identity will execute it?

Which resource will be affected?

Is this combination permitted?

That moves AI supply-chain defense from artifact-only inspection toward:

artifact inspection + capability containment + runtime enforcement.

A malicious Skill that cannot access secrets has limited value.

A malicious model loader isolated from production credentials has limited blast radius.

A poisoned repository instruction unable to invoke network-capable tools has fewer exploitation paths.

The objective cannot be perfect identification of malicious intent.

The objective must also be limiting what malicious intent can accomplish.

A CISO Control Model for AI Supply Chains

The enterprise response should therefore operate across the entire artifact-to-authority chain.

Gate the artifact

Treat models, Skills, agent configurations and repository instructions as governed supply-chain inputs.

Unknown origin should mean unknown trust.

Inspect before interpretation

Do not allow production infrastructure to be the first environment that loads an external AI artifact.

Models and agent extensions should enter controlled evaluation environments first.

Patch the interpreter

Frameworks, loaders, converters and inference runtimes are part of the attack surface.

CVE-2026-24747 is an important reminder that even supposedly restricted model-loading mechanisms remain software security boundaries. (⁠NVD)

Declare capabilities

A Skill should not simply say what it does.

The platform should independently know what it is allowed to do.

Filesystem access.

Shell execution.

Credential access.

Network communication.

MCP invocation.

Cloud operations.

Those capabilities should be explicit and enforceable.

Separate evaluation from production

The system inspecting an artifact should not automatically possess the credentials required to deploy that artifact into production.

This is ordinary least privilege applied to AI infrastructure.

Restrict egress

Many supply-chain attacks ultimately require communication with attacker-controlled infrastructure.

Agent and model evaluation environments should therefore have controlled outbound connectivity rather than unrestricted Internet access.

Preserve lineage

Organizations need traceability from:

Artifact → Interpreter → Agent → Tool → Identity → Action

Without that lineage, incident responders may know that something happened without understanding which supply-chain component caused it.

The Incident-Response Question Changes Too

Imagine that an organization discovers a malicious model or Skill.

The traditional response might be:

Remove the artifact.

Rotate exposed credentials.

Rebuild the affected host.

That may no longer be sufficient.

A malicious Skill may have altered memory.

It may have modified repository configuration.

It may have installed another package.

It may have changed an MCP configuration.

It may have generated code that was committed.

It may have influenced a CI/CD pipeline.

It may have caused credentials to be issued elsewhere.

It may have created cloud resources.

It may have changed another agent’s context.

The correct incident-response question therefore becomes:

What downstream state did this artifact influence?

That is substantially harder than deleting a malicious file.

It requires reconstructing the execution graph.

From Software Composition to Behavioral Composition

The security industry spent the last decade learning to understand software composition.

Which libraries are inside the application?

Which dependencies are vulnerable?

Which packages are trustworthy?

AI systems add another dimension:

behavioral composition.

• What happens when this model is interpreted by this loader?
• What happens when this Skill is selected by this agent?
• What happens when this repository instruction meets this developer identity?
• What happens when this agent invokes this tool?
• What happens when that tool inherits these credentials?

The attack may not reside in any one element.

It may exist only when they are assembled.

That is why AI supply-chain security cannot simply become another scanning category inside DevSecOps.

It requires a model of composable authority.

The CISO Question

The traditional software-supply-chain question is:

What code are we importing into the enterprise?

The AI-era version is broader:

What artifacts are we allowing to influence systems that possess authority?

That includes code.

But it increasingly also includes:

models,

weights,

serialized checkpoints,

Skills,

repository instructions,

configuration,

memory,

tool descriptions,

and natural-language operational context.

Once those artifacts can influence a system capable of taking action, the old distinction between passive and executable content becomes less useful.

The better distinction is:

Can this artifact influence an authority-bearing execution path?

If the answer is yes, it belongs inside the security boundary.

The Strategic Lesson from DEF CON 34

DEF CON has always been valuable because it demonstrates what happens when assumptions meet adversarial creativity.

The assumption being challenged here is one of the oldest in computing:

We know when we are executing something.

In increasingly agentic environments, that may no longer be true.

Execution can begin when a model is loaded.

When a repository is opened.

When a Skill is discovered.

When an instruction is interpreted.

When an agent decides which tool to call.

The application itself may not yet have started.

But the trust chain already has.

And an attacker may already be inside it.

That is why AI supply-chain security needs to move upstream — from securing applications to securing everything capable of influencing their execution.

Because in the emerging architecture:

AI Artifact ≠ Passive Data

and:

Loading → Interpretation → Authority → Execution

The supply chain is no longer merely delivering software.

It is increasingly delivering behavior.

And once behavior arrives carrying the authority of the developer, the agent, the inference runtime or the cloud workload, the supply chain has already crossed the execution boundary.

Loading an AI artifact is increasingly an execution decision, not merely a data decision.

Publication Note & Disclaimer
This article provides security and governance analysis, not legal advice. Regulatory obligations must be assessed against the facts, jurisdictions, data types, and roles of the organizations involved.

This article reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.

For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.