Shadow AI governance.
Keep work moving.

Shadow AI governance is the ongoing process of discovering unapproved AI use, setting rules for data and access, giving employees sanctioned tools, and reviewing adoption and risk. It combines people, an AI usage policy, and technical controls; buying a gateway alone is not a complete governance program.

Start with employee interviews, approved-software inventories, procurement and expense records, and permitted endpoint or network signals. Record the tools, owners, accounts, and data involved. OpenWork shows usage routed through its gateway; it is not a network-wide tool for detecting personal accounts or unsanctioned AI tools outside that path.

Name approved AI tools and providers, allowed and prohibited data, access owners, review requirements for AI output, retention expectations, an exception process, and an incident reporting route. Explain how employees get sanctioned access and review the policy as tools and obligations change.

Unreviewed AI tools can send company data to providers with unsuitable retention or processing terms. Personal accounts and keys can also leave gaps in access control, offboarding, spend ownership, and audit records. The level of risk depends on the data, tool configuration, and provider terms.

Shadow AI is employees using AI tools at work without their company's approval or oversight. It can include personal chatbot accounts, unsanctioned AI coding tools, and agents connected to company files with personal API keys. The issue is not that people use AI; it is that IT cannot consistently govern access, providers, or usage.

Give employees an approved path that works with their day-to-day tools. Agree on permitted models and providers, use company SSO, assign permissions, and review usage. OpenWork combines an AI gateway for model traffic with support for multiple agents, so governance does not depend on everyone adopting one coding tool.

For model traffic routed through OpenWork, the AI gateway gives IT one controlled path with company sign-in, permissions, provider choice, and usage visibility. It is not a network-wide discovery tool and does not automatically intercept unsanctioned AI tools or personal accounts outside that path.

OpenWork supports centrally provisioned providers such as AWS Bedrock. OpenWork and OpenCode with the opencode-openwork plugin can use your organization's AI gateway models. Claude Code, Codex, and Cursor can use shared skills and connections through the MCP gateway; AI gateway model integration for those clients is in progress. Adding MCP alone does not route a client's model traffic through the AI gateway.

In the local desktop model-gateway setup, files and the workspace stay on the user's PC. Workspace processing sends SSO configuration and model traffic, not a copy of the workspace. Model traffic includes prompts, responses, and any file content the agent includes as context, so local-first does not mean that a remote model never sees company data. Product analytics, diagnostics, update checks, optional cloud workers, and connected services have separate data flows.

An AI gateway is one part of shadow AI governance, not a replacement for company policy. Document approved tools and data handling, configure supported clients to use the gateway, train employees, and review access and usage. Use endpoint and network controls where you need to address tools that bypass the approved path.