> 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.9-saas-agent-building-supply-chain.md). # 2.9 SaaS agent-building supply-chain How to govern the connectors, actions, triggers, and data sources that non-security staff wire together in Copilot Studio and similar low-code builders. *Last reviewed: August 18, 2026* {% hint style="info" %} Low-code agent builders move automation into the hands of business teams. Govern the building blocks before agents reach production users. {% endhint %} ## SaaS agent-building supply-chain: what security teams need to know Low-code builders let teams assemble agents from connectors, actions, triggers, prompts, and business rules. That shortens delivery time, but it also shifts integration risk outside traditional engineering review. The supply chain is the catalog. If anyone can choose any connector, any action, and any trigger, the agent-building surface becomes a shadow integration platform. ## Common SaaS agent-building supply-chain security failures * Users can publish agents without review. * Write actions are available to builders by default. * Triggers run on sensitive data without logging or owner approval. * Agents are shared broadly after a narrow pilot. * Connector scopes are inherited from the builder rather than a controlled service identity. ## SaaS agent-building supply-chain security controls checklist * Restrict who can create, test, publish, and share agents. * Use approved action and connector catalogs. * Require review for external write actions and unattended triggers. * Tag each agent with owner, data class, connected systems, and review date. * Monitor agent runs, failures, connector calls, and sharing changes. ## Anthropic ### Overview Anthropic-specific low-code and SaaS-style agent building appears in Claude connectors, Claude Cowork, Claude Desktop extensions, Agent Skills, Claude Tag, and Claude Managed Agents. In the Claude app surfaces, govern who can enable connectors, whether actions require approval, and whether desktop extensions are allowed. In Claude Tag, review the provisioned service accounts, Access bundles, channel instructions or plugins, repositories, and routines as one shared-agent release. In Managed Agents, review the agent definition, environment, tools, MCP servers, skills, credentials, sessions, and scheduled or multi-agent behavior. Do not collapse these into one approval. A Claude Cowork connector grant, a Claude Desktop extension, a custom Agent Skill, and a Managed Agent with vault credentials can all automate work, but they have different publishing and revocation controls. The agent catalog should identify the builder, publisher, connected systems, write actions, trigger or schedule, environment, and review owner. ### Anthropic documentation * [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) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Multi-agent sessions](https://platform.claude.com/docs/en/managed-agents/multi-agent) * [Scheduled deployments](https://platform.claude.com/docs/en/managed-agents/scheduled-deployments) * [Skills for enterprise](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/enterprise) * [Claude Code plugins](https://code.claude.com/docs/en/plugins) * [Claude Code skills](https://code.claude.com/docs/en/skills) * [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) ## OpenAI ### Overview OpenAI-specific low-code and SaaS agent building spans ChatGPT Work, plugins, apps, custom MCP apps, Workspace Agents, and the legacy Agent Builder surface. Work is a personal task agent, not a published reusable Workspace Agent, so inventory it through user access, scheduled tasks, plugins, and connected data rather than a publisher catalog. Workspace Agents remain the shared, publishable agents that can run on schedules or be triggered from external systems. Agent Builder is still relevant for existing workflows, but OpenAI documents it as legacy and scheduled to shut down on November 30, 2026. Treat any active Agent Builder workflow as a migration item. For Codex, plugin-based agent workflows are more developer-oriented, but the same catalog controls apply when a plugin exposes app actions, MCP servers, skills, or templates to users. ### 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) * [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) * [Developer mode and MCP apps in ChatGPT](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt) * [Apps SDK MCP](https://developers.openai.com/apps-sdk/concepts/mcp-server) * [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) * [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256) * [ChatGPT desktop app and Codex clients](https://learn.chatgpt.com/docs/features) ## Frequently asked questions about SaaS agent-building supply-chain ### What is a SaaS agent builder? A SaaS or low-code agent builder lets users assemble agents from prompts, connectors, actions, triggers, and business rules without writing much code; ChatGPT workspace agents and Claude Cowork are the mainstream examples alongside dedicated platforms. The supply chain is the catalog: whatever connectors and actions builders can pick become the organization's integration surface. ### Why is low-code agent building a supply-chain risk? Builders combine trusted and untrusted components, including connectors, prompts, triggers, and shared templates, into something that acts on business systems under real credentials. Because assembly happens outside engineering review, an over-scoped connector or misconfigured trigger can reach production without anyone reading a diff. ### Which controls matter first for agent builders? In order: who can publish and share agents (not just build them), which connectors and actions are in the approved catalog, which write actions require approval, whether agents run on the builder's credentials or a service identity, and how unattended triggers are reviewed. Publishing rights matter more than building rights; an unpublished experiment hurts less than a shared agent. ### Should business users build agents? Yes, in a sandbox with an approved catalog; that is where the productivity win is. Production publishing should require a review path, an accountable named owner, and credentials that survive the builder leaving. Agents that reach data through the publisher's personal authentication are the pattern to block before broad sharing. ### What should be logged for low-code agents? Builder, publisher, trigger, connector, action, target system, data class, run outcome, and sharing changes. Sharing events deserve alerts: a narrow pilot agent shared org-wide is the most common quiet escalation. ## 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.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.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.10 Hosted-agent framework dependencies](/handbook/2.-supply-chain-and-extensibility/2.10-hosted-agent-framework-dependencies.md) * [1.5 Agent and non-human identity](/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity.md) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths.md) * [5.7 Threat modeling AI systems](/handbook/5.-threats-and-adversarial/5.7-threat-modeling-ai-systems.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.9-saas-agent-building-supply-chain.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.