> 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.1-connectors-and-apps-the-integration-backbone.md). # 2.1 Connectors and apps: the integration backbone Every connector is standing authenticated access to a real system — how to approve, scope, monitor, and review them. *Last reviewed: August 18, 2026* {% hint style="info" %} Connectors turn an AI tool into an authenticated user of other systems. Approve them like standing access, scope them like privileged integrations, and review them like SaaS apps. {% endhint %} ## Connectors and apps: what security teams need to know A connector is an access path, not a convenience toggle. Once connected, the AI tool can read from or act inside another system under a user, bot, or service account identity. The risk depends on the connected system, the granted scopes, the action types, and the way prompts or tool results can influence the agent. Read-only calendar access and the ability to send messages to a customer channel are different control decisions. Use "connector" as the security umbrella when writing controls. Vendor terms change, but the control questions stay stable: what system is connected, who authorized it, what data can it reach, what actions can it take, and where is the evidence? Review the integration by access path, not by product label alone. A built-in app, OAuth connector, MCP server, plugin, desktop extension, or custom integration can create the same governance problem if it gives an AI tool standing access to another system. ## Common connectors and apps security failures * A connector is approved because the brand is trusted, while the OAuth scopes are never reviewed. * Read and write actions are bundled into the same approval path. * A user can connect a personal app account to a managed AI workspace. * Connector grants survive team moves or vendor pilots. * Security reviews the AI platform but not the connected SaaS logs. ## Connectors and apps security controls checklist * Create an intake record for every connector, including owner, data class, scopes, action types, and review date. * Default to read-only where the workflow allows it. * Separate approval for write actions such as sending messages, creating tickets, changing records, or publishing files. * Block connectors that have no business owner or no revocation path. * Review OAuth grants and connected app logs alongside AI platform logs. ## Anthropic ### Overview Anthropic-specific implementation starts with Claude connectors across web, desktop, mobile, Cowork, and Claude Code. Review whether each connector is remote or local, who can add it, what it can read or write, and whether Team or Enterprise policy requires approval or blocks specific tools. Cowork remote sessions can use remote connectors on any supported surface, but local connectors still run through the Claude Desktop app and require that device to be online. For Claude Code, translate connector governance into MCP and extension governance: managed settings, permission rules, MCP configuration, hooks, plugins, skills, data handling, and monitoring. Use both the Claude connector docs and the Claude Code docs to verify which controls exist for the product surface in scope. Claude Tag introduces a shared connector model inside Slack. Channel sessions use organization-provisioned service accounts and Access bundles, while direct messages use the individual's Claude account and personal connectors. A channel connection is shared authority for everyone in the covered scope, so review it as an agent service account rather than a collection of user grants. ### Naming and access by surface * Claude web, Claude Desktop, Claude Mobile, and Claude Cowork call the user-facing integrations connectors. Users browse and manage them through the Connectors Directory or connector settings. * Remote connectors are the default for cloud services and work across Claude web, mobile, Cowork, Desktop, Claude Code, and the API via the MCP Connector. * Desktop extensions package local MCP servers and are specific to Claude Desktop and Claude Code. They are the right path for local files, localhost services, desktop apps, or OS-level access. * Claude Code usually exposes the same category of risk through MCP servers, managed settings, plugins, skills, and hooks. Organization connector permissions can apply to Claude Code, but locally run MCP servers still need Claude Code managed-settings control. ### 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) * [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 data usage](https://code.claude.com/docs/en/data-usage) * [API and data retention](https://platform.claude.com/docs/en/manage-claude/api-and-data-retention) * [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 OpenAI-specific implementation starts with apps, the integrations that connect ChatGPT to external data and actions. Since July 9, 2026, users discover workflow packages through the Plugin Directory; admins still govern the underlying integrations through app access, RBAC, action controls, approvals, sync controls, custom MCP app review, and source-system permissions. Plugins now span ChatGPT Work and Codex. They can package skills, apps, app templates, and MCP-backed capabilities; a visible or installed plugin does not grant data access unless the underlying app is enabled and the user has source-system permission. Also review Codex-specific sandboxing, MCP configuration, managed configuration, approvals, governance exports, API data controls, and workload identity when the workflow enters Codex. ### Naming and access by surface * ChatGPT now calls connectors apps. OpenAI renamed connectors to apps on December 17, 2025; the term includes interactive apps, search/file-search apps, deep research apps, synced apps, and apps with write actions. * Apps are governed through ChatGPT workspace settings and RBAC. Work can use approved plugins and apps on web, mobile, and desktop, subject to plan and workspace settings. * Custom ChatGPT apps are the successor to custom connectors. They are built on MCP, and OpenAI documents the full MCP developer-mode path for ChatGPT web on Business, Enterprise, and Edu. * The Plugin Directory is the discovery layer for Work and Codex. A plugin can include skills, apps, app templates, and MCP servers. If it depends on an app, the app's workspace settings still control access, actions, sync, domain restrictions, and approval behavior. * The ChatGPT desktop app combines Chat, Work, and Codex. Codex mode, CLI, and IDE workflows can also use direct MCP server configuration, so distinguish direct MCP configuration from app-backed plugins. ### 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 Work and Codex](https://help.openai.com/en/articles/20001275) * [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) * [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) * [Data controls in the OpenAI platform](https://developers.openai.com/api/docs/guides/your-data) * [Production best practices](https://developers.openai.com/api/docs/guides/production-best-practices) * [Workload identity federation](https://developers.openai.com/api/docs/guides/workload-identity-federation) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) ## Frequently asked questions about connectors and apps ### What makes AI connectors risky? A connector gives an AI tool such as Claude or ChatGPT standing, authenticated access to another system, so the risk is no longer limited to what a user types into a chat. Exposure depends on the OAuth scopes granted, whether the connector can take write actions like sending messages or changing records, the sensitivity of reachable data, and whether prompt injection can steer the tool into unintended calls. Treat each connector as a standing integration, not a chat feature. ### Should connector access be approved by security or the app owner? Both. The app owner understands what the data means and how the integration is used day to day; security owns the access standard, the risk classification, and the exception process. A workable split: the app owner sponsors and validates business need, security approves scopes and write actions, and both names go in the intake record. ### Are read-only connectors safe? Read-only is meaningfully safer than write-enabled access, but not safe by default. A read-only connector can still pull sensitive records into prompts, model outputs, logs, and shared artifacts, where the source system's access controls no longer apply. Classify read-only connectors by the data they can reach, and review them like any other data export path. ### How often should connector grants be reviewed? Review high-risk connectors, meaning anything with write actions or regulated data, quarterly and after major vendor changes such as OpenAI's December 2025 rename of ChatGPT connectors to apps, which moved where the settings live. Review low-risk read-only connectors at least twice a year. Re-review immediately when scopes change, the owner leaves, or the vendor adds new action types. ### What evidence should auditors expect for AI connectors? For each connector, an auditor should be able to see the named owner, granted scopes, approval date and approver, the users or groups with access, the data classification, the last review date, and the documented revocation path. Where the platform exposes connector or app activity in admin logs, sample it against the approval record to confirm reality matches the register. ## 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.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.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.2 MCP servers: securing the protocol](/handbook/2.-supply-chain-and-extensibility/2.2-mcp-servers-securing-the-protocol.md) * [2.3 MCP gateways and allowlisting](/handbook/2.-supply-chain-and-extensibility/2.3-mcp-gateways-and-allowlisting.md) * [1.6 API keys and service accounts governance](/handbook/1.-identity-and-access/1.6-api-keys-and-service-accounts-governance.md) * [5.2 Data exfiltration via tools and connectors](/handbook/5.-threats-and-adversarial/5.2-data-exfiltration-via-tools-and-connectors.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.1-connectors-and-apps-the-integration-backbone.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.