AI-agent supply-chain risk is broader than vulnerable dependencies. Packages, agent skills, MCP servers, plugins, configuration, instruction files, and remote dependencies can each cross a different trust boundary. Static inspection can reduce artifact risk. Runtime policy can constrain supported actions after an artifact is loaded or installed. HOL Guard does not replace SCA, dependency vulnerability databases, registry security, or every harness-native control.
Does a catalog or plugin scan mean the supply chain is safe?
No. A scan is not a safety guarantee. The current public catalog scanner is registry-broker-fallback static scoring, not a live exploit test. About 205 catalog plugins are not Registry Broker agent counts.
Does HOL Guard cover the whole AI supply chain?
Partially. HOL Guard is local-first runtime control on the developer machine for shell, secrets/file reads, MCP server change, and plugin/skill install. Scanner coverage is not runtime coverage. Runtime benchmark fixtures are modeled, not live attack measurements. Guard does not replace SCA, mcp-scan, or a complete supply-chain security program.
Is this a complete supply-chain security program?
No. This hub explains package, skill, MCP, plugin, config, instruction-file, and remote-dependency trust boundaries. It is not a complete supply-chain security program and does not certify that an artifact is safe.
Direct answer
What belongs in an AI agent supply chain?
AI-agent supply-chain risk is broader than vulnerable dependencies. Packages, agent skills, MCP servers, plugins, configuration, instruction files, and remote dependencies can each cross a different trust boundary. Static inspection can reduce artifact risk, while runtime policy can constrain supported actions that occur after an artifact is loaded or installed.
HOL Guard does not claim to replace SCA, dependency vulnerability databases, registry security, or every harness-native security control. Scanner and runtime coverage are separate and bounded.
Copied text includes the canonical source and review date.
Reviewed Reviewer: HOL Guard EngineeringReview cadence: 30 days
Seven artifact classes, seven trust boundaries
Treating every supply-chain problem as a package vulnerability hides agent-specific paths such as instruction files and tool descriptions. The classes below are separated so coverage and remediation can be stated precisely.
Package
Trust boundary
Registry publication and dependency resolution
Common risk
Malicious or compromised releases, install scripts, dependency confusion, or typosquatting.
Agent skill
Trust boundary
Skill source, metadata, and bundled instructions
Common risk
Hidden instructions, overbroad permissions, or remote-content indirection.
MCP server
Trust boundary
Tool descriptions, server identity, transport, and returned content
Common risk
Tool poisoning, rug pulls, permission drift, or hostile tool results.
Plugin or extension
Trust boundary
Extension install/update and runtime permissions
Common risk
Publisher compromise, malicious updates, or excessive workspace/tool access.
Configuration
Trust boundary
Local/project configuration interpreted by tools or agents
Common risk
Silent policy changes, added servers, redirected endpoints, or privilege expansion.
Instruction file
Trust boundary
Repository-controlled natural-language guidance
Common risk
Indirect prompt injection or persistent instruction poisoning.
Remote dependency
Trust boundary
Fetched scripts, git dependencies, URLs, and remote assets
Dates below are source publication/observation dates, not claims that a campaign remains active today. Ecosystem context is taken from the cited source.
GitHub summarized recent supply-chain attack patterns and 2026 platform changes intended to disrupt maintainer compromise, malicious publishing, install-time execution, and credential propagation.
Why it matters here: Primary ecosystem source for current npm and GitHub Actions mitigations; it is defensive platform context rather than a single campaign attribution.
PyPI described how an npm-focused credential-exfiltration campaign exposed some PyPI tokens while stating that PyPI itself was not exploited through that campaign.
Why it matters here: Cross-ecosystem credential exposure example that should not be misrepresented as a PyPI package compromise.
Scanner coverage is not runtime coverage
Artifact
Scanner role
Runtime role
Explicit boundary
package
Inspect package/artifact metadata and known suspicious characteristics before or around installation.
Evaluate eligible package-manager intent and consequential actions at supported runtime boundaries.
Guard is not a replacement for SCA/dependency vulnerability databases and does not see unsupported installation paths.
skill
Inspect skill/plugin artifacts and instruction-bearing content when available to the scanner.
Evaluate supported tool/file/command actions influenced by loaded skill content.
Scanning an artifact does not prove all later model behavior is safe.
mcp server
Inspect configuration and static metadata that can be reviewed before connection.
Evaluate managed/observable MCP calls and related supported action surfaces.
Direct or unsupported MCP transports can fall outside the current contract.
plugin
Inspect installable artifact metadata/content where supported.
Evaluate observable actions exposed through the harness integration.
Inline or extension-internal behavior without a Guard-visible tool/action may be outside the runtime contract.
config
Detect risky or changed configuration when the artifact is part of the supported inspection path.
Apply policy to resulting supported actions, not every configuration parser side effect.
A configuration change can affect behavior before a Guard-visible action exists.
instruction file
Inspect instruction-bearing text for suspicious content in supported scan flows.
Constrain consequential actions that follow from influenced model reasoning.
No universal model-level prompt-injection filter is claimed.
remote dependency
Inspect pinned/downloaded material when content is available to the supported scanner.
Evaluate supported fetch/install/execute actions when they pass through a Guard-visible boundary.
Mutable remote content and out-of-band fetches can change or bypass a prior static review.
Coverage boundary
What this control can cover
Separate artifact inspection from supported runtime action policy.
Explain package-manager intent, skill/plugin artifacts, MCP configuration, instruction-bearing content, and selected remote-dependency paths without pretending they are one control.
Preserve explicit harness and event-surface limitations from the current support manifest.
What it does not prove or prevent
A replacement for package registries, SCA/dependency vulnerability databases, or publisher-account security.
A guarantee that mutable remote content stays identical after it was reviewed.
Execution paths that bypass Guard-visible scanner or runtime integration surfaces.
Safe scan and remediation flow
Step 1
Inventory
Identify the exact package, skill, MCP server, plugin, configuration, instruction file, or remote dependency and pin its source/version when possible.
Step 2
Inspect before trust
Use the supported scanner or review path before executing install hooks, remote scripts, or newly added tools.
Step 3
Test in isolation
Prefer an isolated fixture, disposable workspace, or Docker Lab over a credential-bearing production environment.
Step 4
Constrain runtime actions
Keep pre-action policy/approval active for the supported harness surfaces reached after installation or loading.
Step 5
Remediate
Remove or pin the unsafe artifact, rotate credentials if exposure is plausible, and update policy when the root cause is broader than one artifact.
Step 6
Rescan and preserve safe evidence
Repeat the safe check and retain only version, source, decision, and redacted evidence needed to demonstrate the corrected state.
Policy pattern
Quarantine unknown install-time execution
Do not let a newly discovered package, remote script, plugin, or tool gain execution authority merely because a dependency resolver selected it.
Use when: An install, update, bootstrap, or tool-registration flow introduces new executable or instruction-bearing material.
Decision pattern
Identify and pin the exact artifact source/version.
Inspect or sandbox before allowing install-time execution when the supported path permits it.
Require review when a new or changed artifact reaches a sensitive action boundary.
After remediation, rescan and record only redacted/versioned evidence.
Limitations
This pattern does not replace registry provenance, SCA, code review, or publisher protections.
Out-of-band installers and unsupported harness/tool paths may bypass this control.
If you suspect prompt injection
Step 1
Stop installs and propagation
Pause affected automated installs, updates, and publishing until the artifact/version and trust boundary are known.
Preserve: Artifact name, version, source, digest, and redacted decision identifiers.
Step 2
Rotate potentially exposed credentials
If install-time code or a malicious tool could read credentials, revoke or rotate them rather than assuming scanning contained the incident.
Preserve: Rotation/revocation completion state without secret values.
Step 3
Remove or pin the artifact
Move to a known-good version or remove the dependency/tool, then verify the lock/configuration state.
Preserve: Corrected version/source plus dependency/configuration diff.
Step 4
Re-run safe checks
Repeat supported scan/runtime tests in an isolated environment and preserve the result with its limitations.
Preserve: Redacted scan result, policy decision, and environment/version metadata.
For the safe educational environment, use the Guard security labs rather than substituting live credentials or destructive payloads.
Dependency scanning vs agent runtime controls
This comparison uses the same criteria for both approaches and does not rank vendors. Traditional dependency/SCA tooling and HOL Guard solve overlapping but different jobs; the recommendation depends on the risk boundary.
Neutral comparison of dependency scanners and HOL Guard
Criterion
Dependency / SCA scanners
HOL Guard
Known dependency vulnerabilities
Primary strength: package inventory, advisory databases, version matching, and remediation guidance.
Not a replacement for SCA or vulnerability databases; may complement them with artifact and runtime action context.
Malicious or compromised package behavior
May detect known malware, provenance/reputation problems, suspicious files, or policy violations depending on the product.
Supported scanner paths can inspect selected artifacts; runtime policy can constrain supported install/tool/command actions after selection.
Instruction-bearing skills and repository files
Usually outside traditional dependency/CVE scope unless a product explicitly analyzes these artifact types.
Can model instruction-bearing artifacts separately and constrain supported downstream actions; no universal prompt filter is claimed.
MCP/tool behavior
Not a core dependency-scanner responsibility unless the product has a dedicated MCP/tool-security feature.
Supported MCP configuration/tool-action surfaces can be reviewed or policy-controlled, with unsupported transports kept visible as gaps.
Action-time policy
Typically informs build/remediation decisions rather than intercepting an agent action at execution time.
Core role on supported harness event surfaces: allow, observe, ask, block, or report unsupported behavior according to the current contract.
Best fit
Use when the job is dependency inventory, CVE/advisory matching, license/composition analysis, or established package remediation.
Use when the job also includes agent-specific artifacts and supported runtime action boundaries. In many environments both approaches belong together.