An AI agent is not a monolithic system. It is a composition of tools, skills, plugins, APIs, and data sources. The agent calls external services to accomplish its goals. It downloads tools from package repositories. It integrates with third-party APIs. Each dependency is a potential attack surface.
Software supply chain attacks have historically targeted package repositories like npm and PyPI. Attackers publish malicious packages that appear legitimate. Developers inadvertently install the packages. The malicious code executes with the developer's privileges. The attack succeeds because the supply chain is not validated.
The same threat exists for AI agents. As agent ecosystems mature, skill marketplaces and plugin repositories will emerge. Attackers will poison these repositories with backdoored skills. Agents will unknowingly use the poisoned skills. The harm can be severe because agents have real system access and execute with autonomy.
This is the supply chain security problem for AI agents. The solution requires trust mechanisms that validate skills and their provenance, similar to how code signing and Software Bill of Materials (SBOM) work for traditional software.
AI Agent Ecosystem and Dependencies
Modern AI agents are composed of multiple layers. At the top is the LLM core, which reasons and makes decisions. Below that are skills, which are discrete units of functionality. A skill might be "send an email" or "query a database" or "call a payment API". An agent may have dozens of skills.
Skills are typically sourced from multiple places. Some are built in-house and maintained by the organization. Others are imported from public skill repositories. Others are licensed from commercial providers. Each source introduces risk.
When an agent uses a skill, the agent is delegating part of its execution to that skill. If the skill is malicious or compromised, the agent's action can be subverted. The malicious skill can perform unauthorized actions, exfiltrate data, or corrupt results.
Beyond skills, agents depend on APIs. An agent might call a database API, a payment processing API, or a third-party analytics API. If the API is compromised or returns poisoned data, the agent's decisions may be based on false information.
The broader ecosystem includes embeddings and vectors. An agent might use semantic search to find relevant documents. The embeddings are sourced from a model, and the vectors are stored in a vector database. If the embeddings are poisoned, semantic search returns incorrect results and misleads the agent.
AI Agent Supply Chain Attack Vectors
Supply chain attacks on AI agents can take several forms.
Malicious skill injection: A skill is published to a public repository with malicious functionality. An agent developer imports the skill thinking it does one thing, but the skill does something else. For example, a "format text" skill might also exfiltrate data to an attacker's server.
Compromised API endpoints: A legitimate API endpoint is compromised, either through account takeover or infrastructure breach. The attacker modifies the API to return poisoned responses. Agents calling the API receive malicious data and make incorrect decisions.
Poisoned embeddings: A model that generates embeddings is attacked, or a pretrained embedding model is replaced with a poisoned version. The embeddings are crafted to cause agents to retrieve misleading information. For example, a poisoned embedding for "medical treatment" might consistently rank harmful treatments as relevant.
Backdoored plugins: A plugin or extension is published with hidden functionality. When loaded by an agent, the plugin establishes a covert channel or creates persistence. The attacker can then control the agent remotely.
Dependency chain attacks: A skill depends on other open-source packages. An attacker compromises a transitive dependency (a package used by a package that is used by the skill). The attacker injects malicious code into the dependency. The malicious code is now part of the skill's supply chain.
License hijacking: An attacker takes over the account of a skill author on the public repository. The attacker publishes a new version of the skill with malicious code. Agents that auto-update to the latest version now run the malicious code.
Historical Parallels: npm and PyPI
The software world has experienced supply chain attacks on package repositories. The npm ecosystem, which serves JavaScript packages, has seen numerous incidents. In one case, a package with a typosquatting name (similar to a popular package) was published with malicious code that targeted users of a specific cryptocurrency wallet. The malicious package was installed thousands of times before being removed.
In another incident, an attacker compromised the account of a maintainer of a popular npm package. The attacker published a new version with backdoored code. For a period, any system that installed the latest version of the package was compromised. The attack went undetected for some time because the package was widely used and the malicious version appeared to function normally.
PyPI, which serves Python packages, has experienced similar attacks. Attackers have published packages with names similar to popular packages, hoping developers would install them by mistake. Some packages contained scrapers that stole API credentials from developer machines.
The lessons from these incidents apply directly to AI agent ecosystems. Supply chain attacks are effective and difficult to detect. Repositories with minimal vetting are vulnerable. The attack surface is large because many agents may depend on the same compromised skill.
The Skill Publication Binding (S9 Security Property)
ExecLayer's response is Skill Publication Binding, the S9 security property. The principle is that every skill carries cryptographic proof of its published properties and capabilities. The proof is verifiable and binding.
When a skill is published, the publisher creates a skill manifest. The manifest lists what the skill does, what resources it accesses, what APIs it calls, and what data it processes. The manifest is human-readable and specifies the skill's interface and behavior.
The manifest is signed by the skill publisher's private key. The signature is cryptographic proof that the publisher created the manifest. The manifest and signature together form the Skill Publication Binding.
When an agent attempts to load and use a skill, the agent verifies the binding. It checks the manifest against the skill's actual code. Does the skill actually do what the manifest claims? Does it access only the resources listed in the manifest? Does it call only the APIs declared in the manifest?
If the skill violates the manifest (for example, it tries to access a database that is not declared in the manifest), the agent rejects the skill. The skill is not loaded. The violation prevents the malicious code from executing.
Skill Manifest {
name: "database_query",
version: "1.0.0",
publisher: "org-acme",
description: "Execute read-only queries on the analytics database",
capabilities: {
databases: ["analytics"],
operations: ["SELECT"],
max_rows: 10000
},
dependencies: ["database_client_v2"],
api_calls: ["analytics.query"],
data_accessed: ["aggregate_stats"],
signature: "0x3f2d1a5c...",
publisher_pubkey: "0x7f3d2a1c..."
}The manifest specifies that this skill accesses the analytics database, performs SELECT operations, and returns at most 10000 rows. If the skill tries to write to the database or access a different database, it violates the manifest and is blocked.
Scope Declaration and Runtime Enforcement
Skill Publication Binding works with scope declarations. Each skill declares its scope: what it is permitted to do. The scope is enforced at runtime by the agent framework.
When a skill is invoked, the agent framework intercepts calls made by the skill. For example, if the skill calls a database API, the framework checks: Is this API call declared in the skill's scope? If yes, the call is allowed. If no, the call is blocked.
This prevents malicious skills from making unexpected calls. A skill that tries to exfiltrate data by calling a network API is blocked if the network API is not in the skill's scope. A skill that tries to delete data is blocked if delete operations are not in the skill's scope.
The runtime enforcement is strict. It is not trust-based. The skill is not assumed to be trustworthy. Every call is verified against the scope. Violations are logged and the skill execution is terminated.
The Agent Clawbrary: Governed Skill Ecosystem
ExecLayer provides the Agent Clawbrary, a curated repository of skills for agent use. The Clawbrary is not a free-for-all like npm or PyPI. Skills are vetted before publication. The vetting process includes: source code review, security scanning, testing on a sandbox agent, and verification that the skill's actual behavior matches its manifest.
Skills in the Clawbrary are signed by ExecLayer. Organizations that trust ExecLayer's vetting process can directly use Clawbrary skills without additional verification. Skills from other sources require more scrutiny.
Organizations can also create private skill repositories. Skills are developed internally and signed by the organization's key. Agents in the organization trust these internally-signed skills. External skills are verified but not automatically trusted.
This tiered approach balances convenience and security. Trusted skills are easy to use. Untrusted skills are possible to use but require explicit verification and approval.
Supply Chain Verification Workflow
When an agent needs a skill, the verification workflow is as follows.
Step 1: Locate the skill. The agent framework queries the skill repository (Clawbrary, internal repository, or external source) for a skill matching the request.
Step 2: Retrieve the skill manifest and signature. The framework obtains the skill's manifest and the publisher's signature.
Step 3: Verify the signature. The framework uses the publisher's public key to verify the signature. If the signature is invalid, the skill is rejected immediately. The signature proves that the publisher created the manifest and takes responsibility for the skill's properties.
Step 4: Analyze the manifest. The framework reads the manifest and determines what the skill declares it will do. The manifest specifies resources, APIs, and operations.
Step 5: Sandbox execution. The skill is loaded and executed in a sandbox. The sandbox is isolated and monitors all system calls, network activity, and resource access. The actual behavior is compared against the manifest.
Step 6: Verify conformance. If the skill behaves exactly as the manifest declares, it passes verification. If the skill attempts to access resources not in the manifest or call APIs not declared, the verification fails.
Step 7: Load or reject. If verification passes, the skill is loaded for use. If verification fails, the skill is rejected and the agent is notified.
This workflow is more rigorous than typical dependency management, but the security benefit justifies the additional checks. Supply chain attacks are prevented.
Transitive Dependencies and Dependency Resolution
Skills may depend on other packages or services. The manifest declares these dependencies. When a skill is verified, its dependencies must also be verified.
If a skill depends on a database client library, that library must be verified before the skill is loaded. The library is checked against its own manifest. The verification is recursive: each dependency's dependencies must also be verified.
This prevents the transitive dependency attack vector. An attacker cannot compromise a deep dependency and expect the compromise to be undetected. Every dependency in the chain is verified.
Key Management and Publisher Trust
The Skill Publication Binding relies on public key infrastructure. Each skill publisher has a key pair. The private key signs manifests. The public key verifies signatures.
Key management is critical. If a publisher's private key is compromised, an attacker can sign malicious manifests. The attacker can publish false manifests claiming the skill does something benign when it actually does something harmful.
Organizations must maintain a trusted set of publisher keys. For internal skills, the organization generates and secures its own keys. For Clawbrary skills, the organization trusts ExecLayer's key. For external skills, the organization must decide whether to trust the external publisher's key.
If a key is compromised, it should be revoked immediately. A key revocation list (KRL) is published, and all verifications with the revoked key fail. Skills signed with the compromised key are rejected.
Supply Chain Transparency and Auditability
The Skill Publication Binding provides auditability. Each skill carries a cryptographic binding to its manifest. The binding is proof of what the skill was declared to do.
Organizations can audit: What skills is each agent using? What are the manifests for these skills? Have the manifests changed? When were they signed? By whom?
This transparency is valuable for compliance. An auditor can verify that agents are using only approved skills. The auditor can review the manifests to understand the supply chain risk. The auditor can verify that skill updates went through the approval process.
Integration With ExecLayer Governance
Skill Publication Binding is part of the larger ExecLayer governance architecture. When an agent attempts to use a skill, the skill is first verified against its manifest. Then the skill's operations are evaluated against the runtime policy engine. Then high-risk operations require approval.
For example, a skill might be verified to access the analytics database, but the policy engine might add constraints: limit results to 1000 rows, and mask sensitive columns. The skill is allowed, but its operations are constrained by policy.
The Merkle audit ledger records all skill usage. If a skill behaves unexpectedly or is used in an unusual way, the record is in the ledger and can be investigated.
For more on the broader governance architecture, see the pages on runtime policy enforcement and the AI control plane.
Emerging Threats and Future Defense
As AI agent ecosystems grow, supply chain attacks will become more sophisticated. Attackers may craft skills that pass initial verification but have subtle backdoors that activate under specific conditions. Attackers may create variations of popular skills with slight differences designed to trick agents into using the malicious version.
ExecLayer's approach evolves with threats. Behavioral analysis can flag skills that deviate from their manifest over multiple uses. Machine learning can identify suspicious patterns in skill publications (for example, a sudden spike of similar skills from unknown publishers). Threat intelligence can inform the community about compromised publishers.
The fundamental principle remains: supply chain risk for AI agents is real, verification is necessary, and cryptographic binding of skills to their properties is an effective defense.
Ready to secure your AI agent supply chain?
Request Early Access