> 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.7-the-supply-chain-review-workflow.md). # 2.7 The supply-chain review workflow A repeatable intake process covering allowlist, owner, scopes, credential handling, runtime permissions, update path, and review date for every AI extension. *Last reviewed: August 18, 2026* {% hint style="info" %} AI extensions need an intake path. If a tool can read data, write to a system, run code, or alter agent behavior, it needs an owner and a review date. {% endhint %} ## What security teams need to know about the supply-chain review workflow Supply-chain review is the operating system for AI extensibility. The same intake form should handle connectors, MCP servers, skills, plugins, hooks, prompt templates, model gateways, and hosted-agent packages. The goal is not to slow every experiment. The goal is to separate low-risk exploration from production access, then make production approvals repeatable. ## Common the supply-chain review workflow security failures * Each AI surface has a different approval process. * The review checks source code but misses OAuth scopes or data classes. * The owner leaves and the extension stays enabled. * Updates are treated as routine even when scopes or behavior change. * No register exists for approved AI extensions. ## The supply-chain review workflow security controls checklist * Create one intake form for all AI extension types. * Record owner, source, version, data class, scopes, write actions, credentials, logs, and review date. * Separate sandbox approval from production approval. * Trigger review on scope change, owner change, new write action, new dependency, or vendor update. * Keep a central register that maps extensions to handbook controls. ## Minimum agent bill of materials Keep one record for every approved agent or AI workflow. At minimum, record: | Field | Required detail | | ------------------------ | ----------------------------------------------------------------------------------------------------------- | | Component | Model, SDK, connector, MCP server, skill, plugin, hook, package, image, template, knowledge source, or tool | | Source and owner | Publisher, repository or marketplace, internal owner, and support contact | | Identity and permissions | Credentials, OAuth scopes, service accounts, data classes, actions, and destinations | | Version and provenance | Version, hash or signature where available, build source, and approved distribution channel | | Runtime | Local, browser, desktop, hosted, API, or low-code execution path | | Review state | Reviewer, decision, evidence, review date, exception, and expiry | | Change trigger | Update channel, permission change, owner change, new dependency, incident, or new data class | Reconcile the register against what is installed and enabled. A complete intake record that no longer matches production is not evidence. ## Anthropic ### Overview For Anthropic, the supply-chain intake should track the surface first: Claude connectors, Cowork remote or local execution, desktop extensions, Claude Code customizations, Claude API tool use, Agent Skills, Office add-ins, and Claude Managed Agents. A connector approval is not the same object as a Claude Code plugin, a local MCP server, or a Managed Agent definition. The intake register should record connector or MCP owner, surface, transport, source, version, OAuth scopes or vault credentials, tool allowlist, write actions, skill or plugin contents, environment type, beta headers, logging path, and review cadence. For Managed Agents, include the agent definition, environment, session pattern, MCP servers, skills, credentials, and whether multi-agent delegation is enabled. For Claude Tag, add the Slack workspace and channel scope, dedicated service accounts, Access bundles, allowed domains, repository grants, channel instructions or plugins, and routines. ### 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) * [Tool use with Claude](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview) * [MCP connector](https://platform.claude.com/docs/en/agents-and-tools/mcp-connector) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Skills for enterprise](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/enterprise) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Claude Code plugins](https://code.claude.com/docs/en/plugins) * [Claude Code hooks](https://code.claude.com/docs/en/hooks) * [Claude Code monitoring](https://code.claude.com/docs/en/monitoring-usage) * [Use Claude Cowork on web, desktop, and mobile](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile) * [How Claude Tag agent identity works](https://claude.com/docs/claude-tag/concepts/agent-identity) * [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) ### 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 For OpenAI, the intake workflow should distinguish ChatGPT Work, apps, plugins, Sites, and Workspace Agents from Codex extensions and API-hosted agent frameworks. Work is a user-owned agent surface; plugins package workflow instructions and app dependencies; apps remain the data and action integrations. Direct Codex MCP configuration, hooks, skills, and sandbox policy need their own review. API-built agents add Agents SDK packages, tool definitions, MCP servers, evals, tracing, credentials, and deployment gates. Include surface, owner, app or plugin source, package or workflow version, connected data class, write actions, action-control mode, workspace role, tool list, MCP server URL, sandbox or cloud mode, eval requirement, audit export path, and re-review trigger. For legacy Agent Builder workflows, record the November 30, 2026 shutdown date and migration owner. ### OpenAI documentation * [RBAC](https://help.openai.com/en/articles/11750701-rbac) * [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) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256) * [Workspace Agents](https://developers.openai.com/workspace-agents) * [Agent Builder](https://developers.openai.com/api/docs/guides/agent-builder) * [Safety in building agents](https://developers.openai.com/api/docs/guides/agent-builder-safety) * [Agents SDK](https://developers.openai.com/api/docs/guides/agents) * [Using tools](https://developers.openai.com/api/docs/guides/tools) * [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256) * [Codex hooks](https://developers.openai.com/codex/hooks) * [Codex skills](https://developers.openai.com/codex/skills) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Codex governance](https://developers.openai.com/codex/enterprise/governance) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about the supply-chain review workflow ### What belongs in an AI supply-chain review? Anything that can read data, write to a system, run code, or alter agent behavior: connectors and apps, MCP servers, skills, plugins, hooks, prompt templates, desktop extensions, hosted-agent packages, and model gateways. One intake form should cover all of them, because the same questions about owner, scopes, write actions, and evidence apply regardless of the label. ### Who should approve AI extensions? Shared approval works best: the business owner confirms the need, the app or data owner validates what the extension can reach, security approves scopes and actions against the access standard, and the platform team confirms the control is enforceable. Security should hold the veto and own the exception register so approvals stay consistent across surfaces. ### What is the minimum intake record for an AI extension? Owner, purpose, source, version, surface (which product and mode it runs in), scopes and credentials, data class, write actions, logging path, approval date, and next review date. If you cannot fill in the owner and the revocation path, the extension is not ready for production. ### When should an AI extension be re-reviewed? On any scope change, new write action, ownership change, dependency or version update, vendor behavior change, or incident. Vendor changes count even when nothing local changed: a renamed setting or a new default can silently invalidate the original approval. ### How do pilots fit the review workflow? Pilots can use a lighter review, with sandbox scope, no production data, and a named sponsor, so experimentation stays fast. The gate is promotion: production access requires the full intake record, and the pilot's own telemetry becomes the evidence for that decision. ## 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.2 EU AI Act obligations for deployers | Conditional: for an in-scope high-risk system, this supports provider instructions, dependencies, changes, and approvals. | | 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.4 Colorado AI Act and the US state patchwork | Conditional: for covered Colorado ADMT, this supports developer documentation, system versions, material updates, and approved uses. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies, Inference Security, and GRC guidance. | | G.6 Write an AI Acceptable Use Policy that holds up | This article supplies a technical or process control used to enforce the acceptable-use policy. | | G.7 Ownership and RACI for AI security | This control depends on the ownership and evidence responsibilities defined in the RACI. | | G.8 ISO/IEC 42001 AI management system | This article supports ISO/IEC 42001 AIMS preparation through a repeatable workflow for third-party review, control selection, and change control. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA approved vendors, business-associate review, data paths, and tool authorization. | *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.4 Analyzing skills for risk](/handbook/2.-supply-chain-and-extensibility/2.4-analyzing-skills-for-risk.md) * [2.5 Plugins and marketplaces](/handbook/2.-supply-chain-and-extensibility/2.5-plugins-and-marketplaces.md) * [2.8 Signing and packaging](/handbook/2.-supply-chain-and-extensibility/2.8-signing-and-packaging.md) * [7.2 Pilot design and success metrics](/handbook/7.-rollout-and-operations/7.2-pilot-design-and-success-metrics.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.7-the-supply-chain-review-workflow.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.