OpenCoreGovernance

Enterprise Integrations

View as Markdown

Enterprise integrations are conditional capabilities. Configure an integration only when the current deployment exposes it, the service owner has approved it, and its authentication and data scope are understood.

Integration map

Integration typePurposeAvailability boundary
Service AccountsAuthenticate an approved connector or service without using an individual’s account.Requires the relevant integration and deployment configuration.
Enterprise chat botsMake an approved OpenCore experience available in an enterprise chat service.Requires the specific bot integration and its service-side setup.
Hook extensionsExtend an approved workflow with Hook behavior.Available only when Hooks are enabled and configured for the deployment.

Service Accounts

Use a Service Account only for the approved integration and the smallest source scope it needs. Keep its credentials in the approved secret store, document the account owner and purpose, and rotate or revoke access when the integration changes.

An integration using a Service Account does not bypass source permissions, deployment access controls, or Administrator review.

Enterprise chat bots

Configure an enterprise chat bot only after the deployment and chat-service administrators have approved its audience, data flow, and authorization model.

Chat serviceVerification focus
企业微信Confirm the bot is available only to the approved audience and follows the configured authorization flow.
飞书Confirm the bot’s permissions, intended audience, and representative conversation flow.
钉钉Confirm the bot’s access scope and the authorized user experience.
MattermostConfirm the integration configuration, channel scope, and authorized interaction flow.

Hook extensions

Hooks are conditional extensions, not a capability guaranteed in every deployment. When Hooks are available, configure only an approved extension, define its authorization and data boundary, and test its behavior with representative non-sensitive input.

If Hooks are absent or disabled, review deployment configuration and administrator settings instead of assuming that an extension can be enabled by a user or Curator.

Authentication and secret handling

Use the service’s approved authentication method and store credentials only in the deployment’s approved secret-management location. Never place tokens, passwords, private keys, or client secrets in chat messages, Agent instructions, source control, screenshots, or shared documents.

Grant the minimum required scope, use distinct credentials for distinct integrations where possible, and revoke or rotate credentials when ownership, scope, or service configuration changes.

Verify an integration

Before sharing an integration, test it with an approved account and representative request. Confirm that authentication succeeds, only the intended audience can use it, it reaches only the approved service scope, and errors reveal no secret values.