10 Open-Source Projects for Securing AI Agent Skills
A practical map of scanners, supply-chain controls, sandboxes, and runtime governance.
In July, Hugging Face disclosed an intrusion driven end to end by an autonomous AI agent, starting with a malicious dataset and reaching credential harvesting and lateral movement across internal clusters. SkillScan researchers analyzed 31,132 public skills and flagged potentially dangerous patterns in 26.1%, while 5.2% showed high-severity patterns strongly suggesting malicious intent. Days later, NVIDIA and founding members launched the Open Secure AI Alliance to build and share open technologies for safeguarding software and agents; here are ten open-source projects already working across that emerging stack.
The emerging skill-security stack
If you only want the shortlist rather than the full walkthrough, here are the ten projects:
NVIDIA SkillSpector: Scans skills before installation with deterministic checks, dependency analysis, and optional semantic review.
Cisco AI Defense Skill Scanner: Performs multi-engine static analysis with rules, YARA, AST, taint tracking, and policy gates.
SkillWard: Escalates suspicious skills from static scanning to semantic review and sandboxed execution.
Agent Audit: Scans full agent repositories for risky data flows, secrets, MCP configuration, and excessive privileges.
AgentShield: Audits active agent configuration, hooks, permissions, secrets, and runtime policy.
Microsoft Agent Package Manager: Controls installation of agent assets through manifests, policy, lockfiles, integrity checks, and SBOMs.
NVIDIA Verified Agent Skills: Offers evaluated and signed skills with provenance, verification evidence, and tamper detection.
NVIDIA OpenShell: Runs agents in policy-controlled sandboxes that restrict files, processes, network access, and inference.
Kubernetes Agent Sandbox: Provides Kubernetes APIs and controllers for isolated, stateful agent workspaces.
Microsoft Agent Governance Toolkit: Adds deterministic policy, approvals, and audit logging around consequential agent actions.
The map shows each project’s primary control point. Each project section below explains what it does, how it works, who it is for, and where its boundary ends.
1. NVIDIA SkillSpector: a pre-install scanner for skills
SkillSpector answers the first question most users have when they find a new skill: is this safe enough to install?
What it does. It scans a local file or directory, Git repository, URL, or ZIP and returns a risk score from 0 to 100, severity, recommendation, and findings. Its MCP wrapper also returns a safe_to_install signal. Reports can be written for humans or automation, including JSON, Markdown, and SARIF.
How it works. A source loader inventories the artifact, then deterministic checks inspect 68 patterns across 17 categories. Dependency findings use live OSV data when reachable and fall back to bundled data when it is not. An optional LLM pass adds semantic review before the findings are merged into an install recommendation. skillspector scan ./my-skill --no-llm needs no model key, although dependency coordinates may still be sent to OSV.
Best for. Individual developers, catalog maintainers, and CI pipelines that want a quick admission check with a clear decision at the end.
Boundary. SkillSpector does not execute the skill. Static and semantic inspection can identify suspicious intent and known patterns, but it cannot prove what a skill will do in a live environment.
2. Cisco AI Defense Skill Scanner: deeper multi-engine static analysis
Cisco AI Defense Skill Scanner is also a pre-install scanner, but it emphasizes a collection of specialized analysis engines and configurable security policy.
What it does. It scans a skill directory for malicious instructions, suspicious code, vulnerable execution paths, and behavioral risks, then produces console, JSON, Markdown, HTML, table, or SARIF output. A strict, balanced, or permissive scan policy tunes detection, while a separate severity threshold turns the result into a CI decision.
How it works. The default core combines YAML signatures and YARA rules, Python bytecode integrity checks, and shell-pipeline taint analysis. Optional local analyzers add Python AST and dataflow, trigger checks, and OSV lookups. Optional model and service analyzers add LLM review, meta-analysis, VirusTotal, or Cisco AI Defense. A strict high-severity CI gate is skill-scanner scan ./skill --policy strict --fail-on-severity high.
Best for. AppSec and platform teams that want explainable, CI-oriented checks and more language-aware analysis than a simple pattern scan.
Boundary. The core path is static: it inspects what could happen but does not run the skill. Some optional enrichments use external services and therefore do not belong in a strictly offline setup.
3. SkillWard: escalate suspicious skills into a sandbox
SkillWard treats skill analysis as an escalation pipeline. Cheap checks run first; uncertain cases can progress all the way to controlled execution.
What it does. It produces a behavioral verdict and evidence for a skill, including actions that are only visible when the skill is actually invoked.
How it works. Stage A uses YARA, regular expressions, and static inspection. Stage B asks a model to classify intent and escalates uncertain cases. Stage C launches the skill with an in-container agent inside Docker. A guard inspects tool calls and file content for evidence such as network access, sensitive writes, credential access, and exfiltration, while decoys make malicious behavior easier to expose. The semantic stage can use a locally hosted model.
Best for. Security researchers, reviewers, and higher-assurance catalogs investigating a suspicious or ambiguous skill after static scanning.
Boundary. Dynamic evidence is stronger, but it is also slower and depends on the test scenario reaching the malicious branch. “Nothing happened in this run” is not proof of safety.
4. Agent Audit: scan the whole agent repository
Agent Audit broadens the target beyond a packaged skill. It looks for security problems across the surrounding agent application.]
What it does. It finds dangerous operations, untrusted-data flows into sensitive tools, exposed secrets, risky MCP configuration, skill and package risks, and excessive privileges. Its deepest AST and taint analysis is for Python, while the current scanner also covers TypeScript and JavaScript, Go, Solidity, SKILL.md, and configuration files. Results can fail a build and can be exported as SARIF.
How it works. Repository discovery feeds several analyzers: a Python AST scanner, intra-procedural source-to-sink taint tracker, tool-boundary analyzer, three-stage secret scanner, MCP configuration scanner, privilege scanner, and a shared rule engine. The current project documents 72 rules. A typical static gate is agent-audit scan . --fail-on high; an optional dynamic mode can connect to MCP servers for read-only inspection.
Best for. Developers and AppSec teams reviewing an agent as an application, especially Python-based projects with tools and MCP servers.
Boundary. The default scan is static and does not run the agent application. Optional MCP inspection expands discovery, but the project is not a runtime monitor or execution sandbox.
5. AgentShield: audit what is active on a developer machine
AgentShield shifts the target again, from a single downloaded artifact to the agent configuration already present in a project or user environment.
What it does. Its default mode discovers agent-related files and checks secrets, permissions, hooks, MCP configuration, and agent settings against 102 static rules in five categories. It can also execute hooks in a controlled temporary directory, run active injection tests, watch configuration changes, and install a PreToolUse policy hook.
How it works. The default invocation selects one root: a local .claude directory, otherwise the home .claude directory, otherwise the current directory. Discovery classifies findings by runtimeConfidence, separating active runtime and project-local material from examples, documentation, plugins, and hooks. npx ecc-agentshield scan runs the static checks; optional modes add model review, hook execution, continuous watch, or runtime allow and block decisions.
Best for. Developers, endpoint-security teams, and CI jobs that need to understand the effective agent attack surface of an environment.
Boundary. The default scan is a posture snapshot. Its optional watch and PreToolUse modes expand the boundary, but the hook sandbox is a host child process with a temporary working directory, not a hard operating-system or network boundary.
6. Microsoft Agent Package Manager: govern what gets installed
Microsoft Agent Package Manager, or APM, treats prompts, skills, MCP servers, and other agent assets as a dependency graph rather than files copied by hand.
What it does. It resolves declared agent dependencies, applies installation policy, deploys approved assets to a target harness, records exact versions and integrity data, and can export a CycloneDX or SPDX SBOM from the lockfile.
How it works. apm.yml declares the package graph and apm-policy.yml defines admission rules. During apm install, the resolver fetches dependencies into a cache, scans for hidden Unicode, requires explicit trust for transitive MCP server declarations, checks policy and integrity, deploys approved assets, and writes apm.lock.yaml. Later, apm audit verifies the declared, locked, and deployed state and replays a scratch install to detect drift. apm lock export produces the SBOM separately.
Best for. Platform teams that want repeatable, reviewable distribution of agent assets across developers and CI environments.
Boundary. APM governs what gets installed. It does not execute downloaded package code by default, but explicit lifecycle scripts and experimental canvas extensions are execution exceptions. The agent harness still governs what runs, so installation control must be paired with runtime policy or isolation.
7. NVIDIA Verified Agent Skills: signed provenance plus evaluation evidence
NVIDIA’s verified agent-skills catalog is less a scanner than a trust and distribution pattern for published skills.
What it does. It gives consumers a curated catalog in which each accepted skill carries a skill specification, skill card, evaluation evidence, security review, and a detached signature that can be verified before installation.
How it works. An upstream release pipeline evaluates the skill, runs SkillSpector review, resolves findings, and signs the approved artifact. The catalog’s hourly mirror checks required artifacts, signature state, and source or signature drift; it does not rerun the evaluation, and BENCHMARK.md is commonly published rather than required by the catalog gate. Consumers separately verify the directory against NVIDIA’s root certificate, then install it.
Best for. Skill publishers, catalog operators, and organizations that need provenance and tamper detection, not just a point-in-time vulnerability scan.
Boundary. A valid signature proves origin and integrity, not harmlessness. The catalog’s review raises confidence, but runtime controls are still needed after a verified skill starts acting.
8. NVIDIA OpenShell: contain the running agent
NVIDIA OpenShell moves the control point from artifact inspection to execution. It assumes agent code and skills may be untrusted and gives them a constrained place to run.
What it does. It isolates an agent in a sandbox and enforces policy over filesystem access, processes, network connections, and model inference. Denied operations are stopped at the boundary rather than merely reported afterward.
How it works. The OpenShell Gateway stores desired state and asks a compute driver to provision the sandbox. Inside that sandbox, a Supervisor launches the restricted process. Filesystem and process controls are enforced locally, ordinary egress passes through a local policy proxy and OPA, and model traffic passes through an inference router. Docker and Podman are local options, the VM path is experimental, and Kubernetes is the cluster driver. On Kubernetes, that driver creates a Sandbox resource for the separate Agent Sandbox controller to reconcile into a Pod. The commands openshell sandbox create -- claude and openshell policy set demo --policy policy.yaml --wait are valid, but only network and inference policy are hot reloadable.
Best for. Platform and infrastructure teams running coding agents or other tool-using agents that need OS-level containment.
Boundary. OpenShell limits the blast radius of execution; it does not certify that the skill source is safe or decide whether the business intent of an allowed action is appropriate.
9. Kubernetes Agent Sandbox: provision isolated agent workspaces on Kubernetes
Kubernetes Agent Sandbox is the project that is easy to confuse with OpenShell. It is developed under Kubernetes SIG Apps rather than being a separate CNCF-hosted project. Kubernetes itself is a CNCF graduated project.
What it does. It provides a standardized Kubernetes API for isolated, stateful, singleton workloads, the shape needed by long-running coding agents and other autonomous runtimes. A sandbox can keep a stable identity and persistent storage, then be suspended, resumed, or replaced without treating it like a replicated web service.
How it works. The core Sandbox CRD and controller reconcile a Pod and its lifecycle, with a conditional headless Service and optional PVCs. Extension CRDs add reusable SandboxTemplate definitions, SandboxWarmPool capacity, and SandboxClaim allocation. A claim can request a warm pool, the pool references a template, and the controllers allocate or adopt a Sandbox. A template can add a managed NetworkPolicy and select a stronger RuntimeClass, including gVisor or Kata Containers. The Kubernetes introduction explains the broader model.
Google Cloud has also introduced Agent Substrate, an adjacent open-source project that pairs sandbox and snapshot capabilities with a specialized control plane for denser agent execution on Kubernetes. It maps many stateful actors onto fewer ready worker Pods, then suspends, resumes, and routes them on demand. The repository is still early and not production ready, and its threat model says security hardening is minimal, so treat it as a scalability substrate rather than an additional security control.
Best for. Platform teams building a multi-tenant Kubernetes substrate for agent runtimes, especially when they need stable workspaces, warm starts, persistent state, and a common API that several agent platforms can consume.
Boundary. Agent Sandbox provisions and manages the workload boundary; it is not an agent-aware security policy engine. The actual strength of isolation depends on the selected runtime, network policy, credentials, and cluster configuration. OpenShell can sit above it to add filesystem, process, egress, inference, and credential policy.
10. Microsoft Agent Governance Toolkit: policy-gate every action
Microsoft Agent Governance Toolkit, or AGT, focuses on the semantic action an agent is about to take: send an email, query data, call a tool, or delegate to another agent.
What it does. It wraps selected callables and configured framework intervention points, evaluates deterministic policy, can require human approval, and records an audit decision. A denied wrapped call never reaches the underlying tool.
How it works. A developer wraps a function with govern(my_tool, policy="policy.yaml"), which returns a GovernedCallable. Each wrapped invocation builds governance context, runs the YAML PolicyEngine with deny-overrides behavior, optionally requests approval, and writes to a Merkle-chained audit log. The broader toolkit separately offers Agent Control Specification support, OPA and Cedar backends, identity and trust, framework adapters, sandboxing, MCP security, compliance, and SRE modules.
Best for. Application, security, and compliance teams that need explainable authorization for every consequential agent action.
Boundary. The basic middleware and the agent share a process boundary, and the default audit log is in memory unless an external sink is configured. Microsoft’s own guidance recommends container isolation for stronger protection; the policy gate should not be mistaken for the operating-system boundary provided by OpenShell.
Where the projects overlap and where they do not
The first five projects all find risk, but their inspection targets are different. SkillSpector and Cisco Skill Scanner focus most directly on a skill artifact. SkillWard adds controlled execution. Agent Audit follows dangerous flows through the wider agent codebase. AgentShield inventories the configuration that is active in an environment.
APM and NVIDIA Verified Agent Skills operate on the software-supply-chain problem. APM makes installation deterministic and policy-controlled; NVIDIA’s catalog adds publication requirements, evaluation evidence, and signed provenance. Neither replaces source analysis or runtime containment.
The final three control points intervene while an agent is operating, but at different boundaries. AGT authorizes the agent’s intended action. OpenShell constrains what the process can actually do at the operating-system and network boundary. Kubernetes Agent Sandbox provisions and manages the underlying stateful workload when that process runs on Kubernetes.
That produces a useful three-line mental model:
Intent: Is this requested action allowed for this agent? AGT answers that question.
Capability: Can this process reach the resource at all? OpenShell enforces that boundary.
Substrate: Where does the isolated stateful workload run? Agent Sandbox provides that lifecycle.
Comparison at a glance
The table condenses the primary target, mechanism, effect, and GitHub stars for all ten projects.
For an organization adopting third-party skills, I would start with four layers:
Scan before trust. Run SkillSpector or Cisco Skill Scanner on every incoming skill; escalate ambiguous, high-risk artifacts to SkillWard.
Control distribution. Use APM-style manifests, policies, lockfiles, and SBOMs; verify signatures when a curated catalog provides them.
Authorize actions. Put deterministic policy and audit around consequential tool calls with AGT or an equivalent middleware gate.
Contain execution. Run the agent inside an OpenShell-style sandbox, and use Agent Sandbox as the Kubernetes substrate when the workload needs cluster-native lifecycle and isolation.
No single project spans the entire lifecycle yet. That is not a weakness in the ecosystem; it is the shape of defense in depth. The important step is to stop treating a skill as “just a Markdown file.” It is a supply-chain artifact that can steer a privileged, autonomous runtime.