> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/2.-supply-chain-and-extensibility/2.8-signing-and-packaging.md). # 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* {% hint style="info" %} Packaged extensions are easier to review than scattered files. Require versioned, centrally distributed packages for anything that reaches production users. {% endhint %} ## 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 * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) * [Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities) * [When to use desktop and web connectors](https://support.claude.com/en/articles/11725091-when-to-use-desktop-and-web-connectors) * [Getting Started with Local MCP Servers on Claude Desktop](https://support.claude.com/en/articles/10949351-getting-started-with-local-mcp-servers-on-claude-desktop) * [Building Desktop Extensions with MCPB](https://github.com/modelcontextprotocol/mcpb) * [Build custom connectors via remote MCP servers](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Claude Code permissions](https://code.claude.com/docs/en/permissions) * [Claude Code security](https://code.claude.com/docs/en/security) * [Claude Code MCP](https://code.claude.com/docs/en/mcp) * [Claude Code hooks](https://code.claude.com/docs/en/hooks) * [Claude Code plugins](https://code.claude.com/docs/en/plugins) * [Claude Code skills](https://code.claude.com/docs/en/skills) * [Claude Code monitoring](https://code.claude.com/docs/en/monitoring-usage) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## 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 * [Apps in ChatGPT](https://help.openai.com/en/articles/11487775-apps-in-chatgpt) * [Admin Controls, Security, and Compliance in apps](https://help.openai.com/en/articles/11509118-admin-controls-security-and-compliance-in-apps-enterprise-edu-and-business) * [Developer mode and MCP apps in ChatGPT](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt) * [ChatGPT desktop app](https://learn.chatgpt.com/docs/app) * [Apps SDK MCP](https://developers.openai.com/apps-sdk/concepts/mcp-server) * [ChatGPT desktop app and Codex clients](https://learn.chatgpt.com/docs/features) * [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256) * [Plugins](https://learn.chatgpt.com/docs/plugins) * [Codex MCP](https://developers.openai.com/codex/mcp) * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security) * [Codex governance](https://developers.openai.com/codex/enterprise/governance) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## 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 | Governance page | Relationship to this article | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------- | | 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 * [2. Supply Chain & Extensibility](/handbook/2.-supply-chain-and-extensibility.md) * [2.7 The supply-chain review workflow](/handbook/2.-supply-chain-and-extensibility/2.7-the-supply-chain-review-workflow.md) * [2.4 Analyzing skills for risk](/handbook/2.-supply-chain-and-extensibility/2.4-analyzing-skills-for-risk.md) * [5.3 Supply chain attacks and notable CVEs](/handbook/5.-threats-and-adversarial/5.3-supply-chain-attacks-and-notable-cves.md) * [2.10 Hosted-agent framework dependencies](/handbook/2.-supply-chain-and-extensibility/2.10-hosted-agent-framework-dependencies.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://handbook.harmonic.security/handbook/2.-supply-chain-and-extensibility/2.8-signing-and-packaging.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.