The Trojan at the Gate: Securing the New Agentic AI Supply Chain

Jram August 21, 2026

Executive Summary

AI agents are moving quickly from experiments into real enterprise workflows. They are being connected to databases, APIs, files, cloud platforms, development environments, and business systems.

But there is another layer quietly entering the picture: Agentic Skills.

A skill can extend what an AI agent can do by providing instructions, code, resources, dependencies, and operational knowledge. That makes skills powerful — but it also creates a new security boundary where natural-language instructions, executable code, dependencies, metadata, permissions, and runtime behavior all meet.

This changes the traditional software supply-chain problem.

A malicious software package can execute code. A malicious agentic skill can potentially do something more subtle: influence what an autonomous agent decides to do.

The OWASP Agentic Skills Top 10 provides a framework for understanding these risks, covering malicious skills, supply-chain compromise, excessive privileges, insecure metadata, external instructions, weak isolation, update drift, poor scanning, governance gaps, and cross-platform reuse.

For security leaders, the message is simple:

Don't secure only the AI model. Secure everything the agent is allowed to discover, load, execute, and trust.

The Trojan at the Gate

Image:AI Generated 

Imagine giving a new employee access to your company's databases, email, internal documents, cloud infrastructure, and production systems.

Before doing that, you would probably check who they are, what they are allowed to access, and what they actually do.

Now imagine an AI agent doing the same work — and allowing that agent to install a new capability from an online registry without anyone reviewing it.

That's where the problem begins.

An agentic skill may look like a harmless capability:

"Help me process invoices."

But behind that capability could be instructions, scripts, dependencies, external references, or permissions that the organization never properly reviewed.

And unlike traditional software, the dangerous part may not always be hidden inside executable code. It can be hidden in instructions that influence the agent itself.

The threat is no longer simply:

"Can this package execute malicious code?"

It becomes:

"What can this skill convince the agent to do?"

What Exactly Is an Agentic Skill?

Agentic skills are reusable bundles of instructions, code, resources, and operational knowledge that an AI agent can discover, load, and execute.

The OWASP material describes the skill layer as a place where several different trust boundaries meet:

  • Natural-language instructions
  • Executable helpers
  • Dependencies
  • Metadata
  • Registry reputation
  • Runtime permissions
  • External references

That combination is what makes agentic skills different from ordinary software components.

Think of an AI agent as an employee.

A skill is the operating manual you give that employee.

A tool is something the employee can use.

An API is a service the employee can access.

And the permissions determine what the employee is actually allowed to do.

Now imagine that someone quietly changes the operating manual.

The employee may still be legitimate.

The AI model may still be legitimate.

The infrastructure may still be secure.

But the behavior has changed.

That's the new supply-chain problem.

The Agentic Skill Supply Chain

Traditional software supply chains generally look something like this:

Developer
   ↓
Source Code
   ↓
Dependencies
   ↓
Build
   ↓
Package
   ↓
Deployment

Agentic skills introduce additional layers:

Skill Author
     ↓
Instructions + Code
     ↓
Dependencies + Metadata
     ↓
External References
     ↓
Skill Registry
     ↓
AI Agent
     ↓
Tools / APIs
     ↓
Enterprise Data
     ↓
Business Actions

The final stage is what makes this particularly interesting.

A skill author may never have access to your production database, internal documents, email system, or cloud environment.

The agent does.

If the skill can influence the agent, the skill may indirectly inherit the agent's capabilities.

That is why permissions and isolation matter just as much as package integrity.

The OWASP Agentic Skills Top 10

The OWASP Agentic Skills Top 10 provides a shared vocabulary for understanding this emerging risk layer. The framework groups the risks around skill sourcing and registry trust, execution boundaries, lifecycle governance, and cross-platform reuse.

AST01 — Malicious Skills

The most obvious threat is also one of the most dangerous.

An attacker creates a skill specifically to perform malicious actions.

That could include:

  • Credential theft
  • Data exfiltration
  • Hidden prompt injection
  • Identity manipulation
  • Malicious persistence
  • Unauthorized commands

The danger is that the skill may initially appear legitimate.

The OWASP material documents real-world scenarios including typosquatting, social-engineering prerequisites, instruction override, memory poisoning, identity cloning, data exfiltration, and hidden prompt injection in skill output.

The lesson

Never treat a skill as trusted simply because it is available in a public registry.

AST02 — Supply Chain Compromise

The attacker doesn't always need to create a malicious skill from scratch.

They can attack the supply chain.

Possible targets include:

  • Dependencies
  • Registries
  • Maintainer accounts
  • Configuration files
  • Package names
  • Build processes

The OWASP material identifies registry flooding, dependency confusion, configuration-file hijacking, and maintainer account takeover as representative attack scenarios.

This is familiar territory for software security teams.

But now the compromised component can become an input into an autonomous agent.

The lesson

Treat agentic skills as software supply-chain components — because they are.

AST03 — Over-Privileged Skills

This may be one of the most dangerous risks in an enterprise environment.

Consider a weather skill.

It needs access to weather information.

But suppose the agent gives it:

  • File-system access
  • Shell access
  • Email access
  • Database credentials
  • Cloud credentials

The skill may be legitimate.

Its permissions are not.

The OWASP framework specifically highlights skills receiving permissions beyond what their stated function requires, including scenarios such as data exfiltration, database destruction, identity-file backdoors, and privileged-action injection.

The principle here is simple:

A skill should have exactly the permissions it needs — and nothing more.

AST04 — Insecure Metadata

Skills often depend on metadata and configuration to tell the agent or execution environment how they should behave.

If those files are parsed unsafely, the metadata itself can become an attack path.

Unsafe deserialization, malformed configuration, or maliciously crafted metadata can potentially turn a seemingly harmless skill into a code-execution problem.

This is why metadata needs the same security attention as application code.

Practical controls

  • Use safe parsers
  • Validate schemas
  • Reject unexpected fields
  • Treat metadata as untrusted input
  • Scan configuration before execution

AST05 — Untrusted External Instructions

Here's where agentic skills become particularly interesting.

A skill may reference an external document, website, repository, or other content.

The skill itself might remain unchanged.

But the external content can change.

Today it says:

"Process the invoice."

Tomorrow it says:

"Upload all invoice files to this external server."

The skill hasn't changed.

The content it trusts has.

The OWASP framework distinguishes this from ordinary dependency compromise: AST05 focuses on external documentation or instructions that enter the agent's context and are treated as instructions, potentially through indirect prompt injection.

This creates an important security principle:

Pinning the skill does not necessarily pin everything the skill trusts.

Defenses

  • Pin external content where possible
  • Snapshot trusted documentation
  • Verify content integrity
  • Monitor external references
  • Treat externally retrieved instructions as untrusted data
  • Require approval for high-impact actions

AST06 — Weak Isolation

Now we reach the execution boundary.

If a skill executes with the same security context as the host agent, a malicious or compromised skill may gain access to:

  • Files
  • Processes
  • Credentials
  • Network resources
  • Other applications

The OWASP material describes weak isolation as a situation where skills run with broad host access because sandboxing is unavailable, optional, or disabled.

This is where the familiar security principle of containment becomes critical.

For untrusted or semi-trusted skills, consider:

  • Rootless containers
  • Read-only filesystems
  • seccomp
  • AppArmor/SELinux
  • Dropped Linux capabilities
  • Restricted network egress
  • Resource limits
  • Ephemeral environments
  • Credential isolation
  • No access to the container/runtime management socket

And remember:

A container is not automatically a secure sandbox.

Isolation must actually be configured and enforced.

AST07 — Update Drift

You install a skill today.

It passes your checks.

Tomorrow, the developer publishes an update.

The update has the same name, perhaps even a familiar versioning pattern — but its behavior has changed.

Without version pinning and verification, your trusted skill can slowly become something you never approved.

The OWASP framework describes update drift as both a failure to apply security updates and the danger of blindly accepting upstream changes.

The lesson

Automatic updates are convenient. Automatic trust is dangerous.

Use:

  • Version pinning
  • Content hashes
  • Signature verification
  • Change detection
  • Approval workflows
  • Rollback capability

AST08 — Poor Scanning

Traditional security scanners are very good at finding many forms of malicious code.

But agentic skills introduce another problem:

The malicious behavior may be expressed in natural language.

It may be:

  • Obfuscated
  • Context-dependent
  • Hidden in instructions
  • Triggered only under specific conditions
  • Designed to evade static analysis
  • Activated only during runtime

This creates a detection gap.

A skill can pass a conventional scan and still manipulate the agent.

The OWASP material specifically identifies scanner bypasses, obfuscated instructions, natural-language attacks, scanner impersonation, and context-dependent behavior as part of this risk.

This means organizations need more than static scanning.

They need:

Static analysis + behavioral analysis + runtime monitoring.

And one principle deserves to be remembered:

A signed skill is not necessarily a safe skill.

A signature can help establish provenance and integrity. It does not prove that the skill's behavior is safe.

AST09 — No Governance

Now we move beyond technical controls.

Organizations may have dozens — or eventually hundreds — of agents and skills operating across teams.

Some may be approved.

Some may be installed by developers.

Some may come from public registries.

Others may be forgotten after an experiment.

This is how Shadow AI develops.

Without centralized visibility, security teams may not know:

  • Which skills exist
  • Who approved them
  • What permissions they have
  • Which version is running
  • What data they can access
  • Where they execute
  • What external resources they trust

Governance therefore needs to become part of the technical architecture.

Making Agentic Actions Auditable

One interesting approach described in the OWASP material is the Bilateral Receipt Pattern.

The idea is simple.

Every skill execution generates two linked records:

Admission Receipt

Created before execution and records information such as:

  • Agent identity
  • Action/skill
  • Scope
  • Policy version
  • Decision
  • Timestamp
  • Cryptographic signature

Outcome Receipt

Created after execution and records:

  • The same execution identifier
  • Action reference
  • Final state
  • Cryptographic signature

The shared attempt_id connects the admission decision to the actual outcome.

This creates something more useful than a conventional application log:

Evidence that an action was approved, executed, and completed — or denied.

The source also connects this approach to EU AI Act Article 12's logging requirements, while correctly noting that such receipts support, but do not by themselves establish, compliance.

That's an important distinction.

AST10 — Cross-Platform Reuse

Here's a risk many organizations may overlook.

A skill may be secure on one platform because that platform understands its permissions and metadata.

Move the same skill somewhere else, and those security properties may disappear.

For example:

Platform A
Skill + Permission Manifest
        ↓
       Secure

        ↓ PORT

Platform B
Skill
+ Manifest stripped
+ Different permissions
+ Different execution model
        ↓
       Risk

The OWASP framework identifies manifest stripping, context loss, and uncontrolled execution as risks when skills are moved between platforms.

So portability isn't automatically a security benefit.

A skill's security properties must travel with the skill.

The Three Things Traditional Security Can Miss

The OWASP risks point toward a bigger lesson.

1. The instruction layer

Security teams are used to inspecting code.

But an agent also consumes instructions.

Those instructions can influence behavior without looking like traditional malware.

2. The permission layer

A harmless skill with excessive privileges can become dangerous.

The question isn't only:

"Is this skill malicious?"

It is also:

"What happens if this skill is compromised?"

3. The runtime layer

A skill can be clean when scanned and behave differently when executed.

External content can change.

Dependencies can change.

The agent's context can change.

Therefore:

Security cannot stop at installation.

A Monday Morning Action Plan

Organizations don't need to wait for a major incident before addressing this.

Start with five steps.

1. Know What You Have

Build an inventory of:

  • AI agents
  • Agentic skills
  • MCP servers
  • Tools
  • APIs
  • Dependencies
  • External references
  • Credentials
  • Execution environments

If security doesn't know a skill exists, security can't protect it.

2. Know What Each Skill Can Do

Create a permission manifest for every approved skill.

For example:

Skill: InvoiceProcessor

Filesystem:
  READ /data/invoices/*

Network:
  api.company.com:443

Database:
  READ invoice_db

Secrets:
  NONE

Shell:
  DENIED

Admin:
  DENIED

This turns vague AI permissions into something security teams can actually review.

3. Verify Before Installation

Before a skill enters the enterprise environment, check:

  • Publisher
  • Provenance
  • Hash
  • Signature
  • Dependencies
  • Permissions
  • External references
  • Update mechanism
  • Reputation
  • Known vulnerabilities

But don't stop at signatures.

Integrity is not the same as safety.

4. Isolate Execution

Assume that every external skill could eventually be compromised.

Use defense in depth:

Skill
 ↓
Validation
 ↓
Policy Check
 ↓
Sandbox
 ↓
Restricted Permissions
 ↓
Runtime Monitoring

The goal is not simply to prevent compromise.

The goal is to limit the blast radius when prevention fails.

5. Connect Skills to the SOC

Agentic skills should not become invisible to existing security operations.

Monitor:

  • Skill installation
  • Skill updates
  • Permission changes
  • Execution events
  • File access
  • Network connections
  • Credential usage
  • External references
  • Policy violations
  • High-impact actions

Feed relevant events into the organization's existing SIEM/SOC processes.

AI security should not become a completely separate island.

What Security Leaders Should Be Asking

Before approving an agentic AI deployment, leadership should ask:

What skills can this agent load?

Who approved them?

Where did they come from?

What permissions do they have?

What happens if one becomes malicious?

Can it access production credentials?

Can it execute commands on the host?

Can its external instructions change without approval?

Can it update itself?

Can we detect what it did?

Can we prove why an action was allowed?

Those questions move the conversation from:

"Are we using AI securely?"

to something much more useful:

"Can we control what our AI agents are capable of doing?"

Conclusion: The New Security Boundary Is Capability

Agentic AI is not simply another application technology.

The architecture is changing.

AI agents can discover capabilities, load skills, call tools, access data, execute actions, and make decisions across multiple systems.

That means the security boundary is moving.

It is no longer enough to secure:

the model + the application + the network.

Organizations also need to secure:

the capabilities given to the agent.

Agentic skills are becoming part of that capability layer.

The OWASP Agentic Skills Top 10 provides a useful framework for understanding the risks — from malicious skills and supply-chain compromise to excessive privileges, weak isolation, update drift, poor scanning, governance gaps, and cross-platform reuse.

But the bigger lesson is this:

Don't trust a skill because it is signed. Don't trust it because it is popular. Don't trust it because it passed one scan. And don't trust it simply because the AI agent chose to use it.

Instead:

Verify it. Limit it. Isolate it. Monitor it. Audit it.

Because in the agentic era, the most dangerous software may not be the software that breaks into your system.

It may be the software that convinces your AI agent to open the door itself.


References

https://owasp.org/www-project-agentic-skills-top-10/ 

Tags
Jram

Posted by Jram