Black Hat USA 2026 — Part 3

Models, skills, prompts and runtimes are becoming executable dependencies

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

For decades, software supply-chain security has been built around a relatively stable assumption:

We know what software is.

• A package contains code.
• A library contains code.
• A container contains code.
• A binary contains code.
• A dependency eventually becomes machine instructions.

Security therefore developed an extensive ecosystem around protecting those artifacts:

SBOMs.

Package signing.

Dependency scanning.

Container scanning.

SAST.

SCA.

Artifact repositories.

Build provenance.

Code signing.

CI/CD controls.

All of these remain necessary.

But Black Hat USA 2026 exposed a problem that should concern every CISO responsible for enterprise AI.

The definition of an executable dependency is expanding.

An AI system may change its behavior because it loads a model.

• Because it retrieves a document.
• Because it discovers an MCP server.
• Because it reads a SKILL.md file.
• Because a repository contains instructions.
• Because a tool description tells the agent when that tool should be used.
• Because an inference runtime interprets an artifact differently.
• Or simply because natural-language content entered the agent’s context.

None of those things necessarily looks like traditional executable software.

Yet each can influence execution.

That gives us a new security category:

Executable context.

And it changes the meaning of software supply-chain security.

The Supply Chain No Longer Ends at Code

Consider the traditional software supply chain:

Source Code
→ Dependencies
→ Build
→ Artifact
→ Deployment
→ Execution

Security teams have spent years placing controls along that chain.

Now consider an enterprise agent:

Model
→ System Prompt
→ Agent Framework
→ Skills
→ MCP Servers
→ Tools
→ Retrieval Sources
→ Memory
→ Runtime
→ Enterprise Systems

Which of those are dependencies?

The uncomfortable answer is:

potentially all of them.

Black Hat’s own 2026 AI security program reflected precisely this expansion. Its agent-security training described prompt injection, insecure RAG pipelines, memory poisoning and MCP-specific supply-chain vulnerabilities as parts of the same emerging attack surface. Another Black Hat course explicitly covered attacks across the AI supply chain from foundational models through RAG and agents to production deployments. (⁠Black Hat)

The security boundary is no longer confined to what gets compiled.

It extends to everything capable of influencing what an autonomous system decides to execute.

Black Hat’s Most Important Supply-Chain Signal

One of the most revealing Black Hat USA 2026 briefings had a deliberately provocative title:

Promptware EOD: Skillful Agent Detonation.

The research treated the AI agent supply chain as a malware ecosystem.

The researchers described malicious behavior hiding in:

skill markdown files,
rug-pulled MCP servers,
misaligned models,
and weaponized online content.

More importantly, they argued that conventional build-time scanning was becoming insufficient because agents can retrieve, create and execute components dynamically at runtime.

Their response was strikingly familiar.

They brought back an old malware-security idea:

detonation.

Instead of merely asking whether an AI artifact looks malicious, they placed agents inside a controlled environment and observed what actually happened.

Tens of thousands of public skills were detonated.

Hundreds of malicious skills were reportedly discovered.

Some included cryptominers and infostealers that had evaded static approaches.

The crucial comparison was not between two AI models.

It was between:

what the agent believed it had done

and

what the operating-system kernel observed it doing.

That distinction may become fundamental to AI security. (⁠Michael Bargury)

Because an LLM’s interpretation of behavior is not evidence of behavior.

Telemetry is.

A Markdown File Can Now Be a Supply-Chain Artifact

This is where the conceptual shift becomes uncomfortable.

Consider a file named:

SKILL.md

To most traditional security tooling, it looks harmless.

It is Markdown.

Text.

Documentation.

No executable bit.

No PE header.

No ELF binary.

No JavaScript.

No shellcode.

Possibly no conventional source code at all.

And yet an agent may interpret that file as instructions describing:

what capability exists,

when to use it,

which resources to access,

which commands to execute,

which tools to invoke,

and how to process the result.

Agent Skills are explicitly designed around this principle: a skill can contain a SKILL.md with metadata and instructions and may additionally bundle scripts, references, templates and other resources. (⁠GitHub)

Security research in 2026 has gone further.

Studies of semantic supply-chain attacks have demonstrated that SKILL.md content can influence discovery, selection and governance decisions without requiring conventional malicious code. In other words, natural-language metadata itself can affect which capability an agent discovers and chooses. (⁠arXiv)

That means:

Documentation can become behavior.

Or, more precisely:

Documentation interpreted by an autonomous system can become operational control.

That is a very different threat model.

From Executable Code to Executable Meaning

Traditional software security distinguishes sharply between data and code.

Code executes.

Data is processed.

That distinction has underpinned operating systems, application architectures and security controls for decades.

Agentic computing weakens it.

A document can influence reasoning.

Reasoning can select a tool.

The tool can execute code.

The code can carry an identity.

The identity can change an enterprise system.

The original document never executed anything in the conventional CPU sense.

But removing that document might have prevented the entire action.

From the perspective of security consequence, that distinction begins to matter less.

The chain looks like this:

Untrusted Content
→ Interpretation
→ Decision
→ Tool Selection
→ Authorization
→ Execution

The content has become part of the execution path.

That is what I mean by:

Executable meaning.

The New Dependency Graph

CISOs should therefore reconsider what belongs inside the enterprise dependency graph.

Historically we might have inventoried:

• libraries,
• packages,
• containers,
• binaries,
• APIs,
• operating systems.

The AI dependency graph increasingly includes:

• foundation models,
• fine-tuned models,
• checkpoints,
• adapters,
• system prompts,
• prompt libraries,
• Agent Skills,
• SKILL.md files,
• AGENTS.md and similar repository instructions,
• MCP servers,
• MCP tool definitions,
• agent frameworks,
• plugins,
• connectors,
• model loaders,
• inference runtimes,
• RAG pipelines,
• embedding models,
• vector stores,
• AI gateways,
• external retrieval sources.

This is not merely a longer SBOM.

It is a different kind of dependency graph.

Because the dependencies do not all execute in the same way.

Some execute as machine code.

Some provide authority.

Some provide data.

Some provide instructions.

Some determine context.

Some determine which other dependency will execute next.

That makes the graph behavioral.

Models Are Dependencies

Enterprises increasingly consume models much as they once consumed libraries.

A development team may download a model.

A platform team may deploy a model from a catalog.

A data-science team may fine-tune one.

An application may switch between models dynamically.

An AI gateway may route workloads across several providers.

From an architectural perspective, each model becomes a dependency.

But models create different supply-chain questions from conventional packages.

Where did the model originate?

Who trained it?

Which version are we using?

Has it changed?

What data influenced it?

Was it fine-tuned?

Which adapters are attached?

Which runtime loads it?

What capabilities emerge when it is connected to tools?

Can we revoke it?

Can we reproduce the exact version used during an incident?

These are provenance questions.

They should sound familiar.

But our current SBOM practices rarely answer them.

Skills Are Dependencies

Skills create an even more interesting problem.

They may combine:

natural-language instructions

with

scripts

with

references

with

external resources.

That makes them hybrid artifacts.

Part documentation.

Part configuration.

Part software.

Part behavioral policy.

And potentially part malware.

Black Hat’s Promptware EOD research is important precisely because it challenges the assumption that static inspection is sufficient.

A malicious skill does not necessarily need to look like malicious software.

It needs to cause the agent to behave maliciously.

That is a fundamentally different detection problem. (⁠Michael Bargury)

Prompts Are Dependencies

Enterprise security still often treats prompts as application content.

That may no longer be sufficient.

A system prompt can determine:

which instructions have priority,

which tools may be selected,

how information is classified,

how approvals are interpreted,

what the agent considers trustworthy,

and when the agent should act.

Change the prompt and you may change the security behavior of the system without changing a single line of application code.

That means production prompts require properties we normally associate with software artifacts:

ownership

version control

change management

testing

approval

rollback

integrity

provenance

A prompt used to govern a production agent should not be an invisible string buried inside an application.

It is part of the system’s behavioral architecture.

Tool Descriptions Are Dependencies

The same applies to tool descriptions.

Suppose an agent discovers a tool described as:

Use this tool whenever you need to resolve a customer account issue.

That description influences tool selection.

Now imagine the description changes.

The API has not changed.

The credentials have not changed.

The backend has not changed.

The tool’s code has not changed.

But the circumstances under which the agent invokes it may have changed significantly.

That is a supply-chain event.

This is why semantic attacks are so important.

An attacker does not necessarily need to compromise executable code.

They may only need to influence the description of what the executable component means to the agent.

MCP Servers Are Dependencies

Part 2 of this series argued that MCP is becoming enterprise infrastructure.

The supply-chain perspective adds another dimension.

An MCP server can expose capabilities today and different capabilities tomorrow.

Its implementation can change.

Its tool descriptions can change.

Its dependencies can change.

Its ownership can change.

Its backend can change.

Or the server itself can be replaced.

A trusted MCP endpoint therefore represents a continuing supply-chain relationship.

Black Hat’s broader 2026 discussion already described the agentic ecosystem as interconnected agents, MCP servers, skills, plugins, hooks and connectors. (⁠Black Hat)

That is effectively an emerging AI component ecosystem.

And ecosystems create supply chains.

RAG Turns Information Sources Into Dependencies

Retrieval-Augmented Generation creates another uncomfortable extension.

If retrieved information influences reasoning, then the source of that information participates in system behavior.

A knowledge base.

A SharePoint site.

A vector database.

A web page.

A ticket.

A PDF.

An email.

A GitHub issue.

A log entry.

All may become inputs to autonomous decision-making.

This does not mean every document should be treated like a binary.

It means the architecture must recognize a new trust transition:

Data
→ Context
→ Instruction-like Influence
→ Action

Black Hat’s AI security training explicitly included insecure RAG pipelines and poisoning alongside agent and MCP risks. (⁠Black Hat)

That is important because RAG security is often framed primarily as a data-quality problem.

For autonomous agents it may become an execution-integrity problem.

Runtime Is Part of the Supply Chain

Traditional supply-chain controls concentrate heavily on what happens before deployment.

Acquire.

Build.

Scan.

Sign.

Deploy.

Agentic systems complicate this model because dependencies may be discovered and interpreted at runtime.

An agent can encounter a new document.

Discover a new tool.

Load a skill.

Call an MCP server.

Retrieve external information.

Generate code.

Execute that code.

Then use the result to decide what happens next.

The runtime therefore becomes part of supply-chain security.

That explains why the Promptware EOD researchers moved toward detonation.

Build-time assurance cannot fully determine the behavior of a system whose effective execution environment is assembled dynamically. (⁠Michael Bargury)

The control model must become:

Build-Time Assurance
+
Runtime Verification

Static Scanning Has a Semantic Blind Spot

This creates a difficult problem for security tooling.

Traditional scanners are good at identifying known structural properties:

a vulnerable library,

a dangerous function,

a suspicious binary,

a hard-coded credential,

a malicious domain,

an exploitable code pattern.

But how does a scanner determine that a natural-language instruction will become dangerous only when:

Agent A reads it,

while possessing Tool B,

under Identity C,

in Environment D,

after retrieving Context E?

The malicious property may not exist inside the artifact alone.

It emerges through composition.

That means static scanning faces a semantic blind spot.

This does not make static analysis obsolete.

It means static analysis is only one layer.

AI artifacts increasingly require behavioral testing.

The Agent Detonation Chamber

The detonation concept presented at Black Hat deserves more attention from CISOs because it points toward a broader architecture.

Traditional malware sandboxes ask:

What happens if this binary executes?

An agent detonation environment asks:

What happens if an autonomous system interprets and uses this artifact?

That distinction is subtle but profound.

The test subject is no longer merely the artifact.

It is:

Artifact × Agent × Tools × Identity × Environment.

This could eventually become a standard component of enterprise AI accreditation.

Before approving a new skill, MCP server, agent framework or other behavioral artifact, the organization could execute it in an isolated environment and observe:

filesystem changes,

process creation,

network connections,

credential access,

API calls,

tool invocations,

data movement,

privilege transitions,

and persistence attempts.

The evidence should come from infrastructure telemetry.

Not from asking the model whether it behaved safely.

We Need an AI-BOM

The obvious response is to extend the concept of the SBOM.

But simply adding models to an SBOM is not enough.

Enterprises increasingly need something closer to an:

AI Bill of Materials

or perhaps more accurately:

Agentic Dependency Graph.

For each production AI system, the enterprise should be able to identify:

Model
Which model and version?

Prompt
Which system instructions?

Skills
Which behavioral extensions?

MCP
Which servers and versions?

Tools
Which capabilities?

Identity
Which authority?

Data Sources
Which retrieval environments?

Runtime
Which framework and inference stack?

Dependencies
Which libraries and containers?

External Services
Which providers?

Control Plane
Which authorization and monitoring systems?

But even that inventory is insufficient.

The organization also needs the relationships.

Because risk exists in the edges.

Provenance Must Extend Beyond Code

Software supply-chain security increasingly relies on provenance.

Where did this artifact come from?

Who built it?

Was it modified?

Can we verify its integrity?

The same questions must now extend to behavioral artifacts.

For models:

Model provenance.

For skills:

Skill provenance.

For prompts:

Prompt provenance.

For tools:

Tool provenance.

For MCP:

Server and tool-definition provenance.

For retrieval:

Information provenance.

And eventually:

Decision provenance.

That final category may be the most important.

If an agent takes a consequential action, can we reconstruct which dependencies influenced that decision?

That is the agentic equivalent of tracing a compromised software package through the traditional supply chain.

Version Pinning Becomes a Security Control

One of the simplest controls may also become one of the most important.

Pin versions.

A production agent should not silently inherit arbitrary changes from:

a model,

a skill,

an MCP server,

a prompt,

a plugin,

or an agent framework.

Automatic updates are operationally convenient.

They are also changes to the trust graph.

Enterprises should know when a behavioral dependency changes.

That may require:

approved versions,

cryptographic integrity where technically applicable,

controlled update channels,

change notification,

rollback capability,

and emergency revocation.

The principle is straightforward:

If changing an artifact can change autonomous behavior, changing that artifact is a security-relevant event.

Revocation Is as Important as Approval

Traditional software governance concentrates heavily on approval.

Can we deploy this?

Agentic supply-chain governance needs an equally strong second question:

Can we remove it immediately?

Suppose an MCP server is compromised.

A model provider reports a serious issue.

A skill marketplace contains malicious content.

A prompt template is found to create unsafe tool behavior.

An agent framework has a critical vulnerability.

Can the organization determine:

which agents depend on it,

which business processes use those agents,

which identities they possess,

and how to revoke the dependency without disabling the entire AI platform?

That is supply-chain resilience.

The CISO Control Model

A mature AI supply-chain program will therefore need several control layers working together.

Inventory

Know every significant AI dependency.

Provenance

Know where it came from.

Accreditation

Assess it before production use.

Version Control

Know exactly what is running.

Integrity

Detect unauthorized changes.

Behavioral Testing

Observe what it actually causes.

Runtime Monitoring

Detect unexpected behavior.

Dependency Mapping

Understand what depends on what.

Revocation

Remove trust quickly.

Incident Reconstruction

Determine which artifact influenced which action.

This is much closer to modern software supply-chain security than conventional AI governance.

But it extends beyond software.

The Organizational Problem

There is also an ownership challenge.

Who governs this supply chain?

Application Security?

AI Governance?

Enterprise Architecture?

IAM?

Platform Engineering?

DevSecOps?

Data Governance?

The answer cannot simply be:

the AI team.

Because the dependencies cross existing control domains.

A model may belong to AI governance.

A container belongs to DevSecOps.

An MCP identity belongs to IAM.

A vector database belongs to Data Engineering.

A tool belongs to an application owner.

An agent runtime belongs to the AI platform.

A prompt may belong to a business team.

The resulting authority chain belongs to nobody unless the CISO deliberately creates a governance model around it.

This is another reason AI security cannot remain a specialized subdiscipline isolated from enterprise security architecture.

The Larger Lesson

Software supply-chain security was built around a world where software arrived as software.

Agentic computing changes that assumption.

Behavior may now arrive as:

a model,

a prompt,

a Markdown file,

a tool description,

a retrieved document,

an MCP server,

a plugin,

a memory,

or a runtime dependency.

Some of these contain executable code.

Others contain something potentially just as consequential:

instructions interpreted by a system that already possesses authority.

That means the fundamental security question changes.

We can no longer ask only:

What code are we executing?

We also have to ask:

What are we allowing to influence execution?

That is a much larger supply chain.

The CISO Takeaway

Black Hat USA 2026 makes one conclusion increasingly difficult to avoid:

The enterprise AI supply chain cannot be secured merely by extending traditional dependency scanning to a few new file types.

The architecture itself has changed.

CISOs should begin treating every artifact capable of materially influencing autonomous behavior as a security-relevant dependency.

That includes conventional software.

But it also includes:

Models.
Prompts.
Skills.
MCP servers.
Tool definitions.
Agent frameworks.
Retrieval sources.
Memory.
Inference runtimes.

They require inventory.

They require provenance.

They require ownership.

They require controlled versions.

They require accreditation.

They require runtime observation.

And they require revocation.

Most importantly, enterprises need to recognize that the distinction between data and execution is becoming less reliable as a security boundary.

An artifact does not need to contain machine code to become part of an attack path.

It only needs to influence a system capable of acting.

That gives us the central lesson of Part 3:

The AI supply chain contains both executable code and executable meaning.

And that leads to an even more important architectural principle:

If an autonomous system can read it, interpret it and use it to exercise authority, it belongs inside the threat model.

The supply chain is no longer merely delivering software.

It is delivering behavior.

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.