2.8 Signing and packaging
How to prefer signed, centrally versioned, and managed packages over hand-deployed binaries or ad hoc local extensions.
Last reviewed: August 18, 2026
Signing and packaging: what security teams need to know
Packaging turns local extension sprawl into a manageable release object. A package can contain the manifest, server configuration, skills, hooks, and supporting files that a reviewer needs to inspect.
Signing and version pinning add evidence. They help the organization prove what was approved, what was installed, and whether a later update changed behavior.
Common signing and packaging security failures
Users install unpackaged local extensions from shared folders.
A package version is approved, then the source branch changes.
No one can tell which users have which extension version.
A signed package is trusted forever without update review.
Package review misses scripts or hooks inside the bundle.
Signing and packaging security controls checklist
Prefer signed, versioned packages over hand-deployed files.
Require manifest review and source review before publication.
Pin versions for production groups.
Distribute packages through a managed marketplace or admin channel.
Record package hash, version, owner, source repository, and review date.
Anthropic
Overview
For MCPB and desktop extension packaging, the main Anthropic surfaces are Claude Desktop and Claude Code. MCPB is the MCP Bundle format: a desktop extension is a .mcpb archive (formerly .dxt) that contains a local MCP server and a manifest.json describing the server and its capabilities. Desktop extensions package local MCP servers for Desktop and Claude Code; remote connectors and custom remote MCP servers are available across Claude surfaces and should be reviewed as connector grants rather than local desktop packages.
Review the package manifest, bundled server, credentials, update path, extension directory or custom upload path, and enterprise policy controls. Also review Claude Code plugins when the package bundles skills, hooks, commands, agents, or MCP servers for coding workflows.
Anthropic documentation
Applicable Harmonic guides for Anthropic
OpenAI
Overview
OpenAI does not use Claude-style MCPB desktop extensions for ChatGPT. Comparable packaging decisions show up as custom MCP apps, Apps SDK apps, plugins from the Plugin Directory, and direct Codex MCP server configuration. ChatGPT Desktop (Work / Codex) combines Work and Codex, but the package types still keep separate install, authorization, update, and audit paths.
Review both the desktop and web Plugin Directory and the Codex CLI or IDE plugin browsers. Also review plugin-provided MCP servers, app integrations that require ChatGPT authorization, direct MCP server configuration shared by desktop Codex, CLI, and IDE extension, and managed configuration for organization policy.
OpenAI documentation
Applicable Harmonic guides for OpenAI
Frequently asked questions about signing and packaging
What is an MCPB file?
MCPB is the MCP Bundle format used for Claude desktop extensions: a .mcpb archive (formerly .dxt) containing a local MCP server plus a manifest.json describing the server and its capabilities. It makes local MCP servers installable in one click, which is exactly why the package, not just the server inside it, needs review before distribution.
Why does signing matter for AI extension packages?
Signing proves origin and integrity: the organization can show what was approved, what was installed, and whether a later update changed the contents. It does not replace code and permission review; a signed malicious package is still malicious, just attributable.
Should users install local extension folders?
Not in production groups. Hand-deployed folders leave no version, hash, or install inventory, so nobody can answer "who is running what" during an incident. Managed packages distributed through an admin channel or marketplace keep review, versioning, and rollback in one path.
What should be version pinned?
Pin anything with code execution or data access: plugins, MCP servers, packaged skills, and desktop extensions. Pinning turns updates into review events instead of silent behavior changes, which is the core defense against the benign-at-review, malicious-at-update supply-chain pattern.
What packaging evidence should be kept?
Source repository, version, hash, signature status, reviewer, owner, install population, and review date for every package in production. The working test: for any given user, you can name the exact package versions they run and who approved each one.
Applicable regulations and frameworks
G.1 Map your controls to NIST AI RMF and CSF 2.0
This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes.
G.3 DORA and AI resilience in financial services
Conditional: for a DORA-regulated workflow, this supports ICT asset, dependency, and third-party risk management.
G.5 SANS Critical AI Security Guidelines mapping
This article implements relevant SANS Deployment Strategies, Inference Security, and GRC guidance.
G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.
Related handbook guidance
Was this helpful?