A marketing manager needs an internal research assistant. Instead of opening a development ticket, they create a custom GPT, add instructions, upload campaign documents, connect a service, and share it with coworkers. Because nothing was deployed through the normal application pipeline, security may never see a repository, architecture diagram, threat model, or release request.
A custom GPT does not automatically bypass every control. The problem is that it can start to look like shadow AI when its creation is treated as SaaS configuration rather than as application development.
Why the GPT Builder Interface Frames App Creation as a Configuration Task
OpenAI describes GPTs as versions of ChatGPT configured for a specific purpose. In managed workspaces where creation is enabled, a builder can define instructions, upload knowledge, enable capabilities, and connect apps or external APIs via actions.
That workflow removes much of the friction people associate with software development. There may be no codebase to review and no infrastructure changes to approve. A useful internal tool can be up and running after a few configuration steps.
Security processes, however, are usually triggered by recognizable engineering events. A new service gets a repository. An API integration creates a ticket. A production deployment passes through CI/CD. A custom GPT may not trigger any of those signals, even though it can hold internal knowledge or interact with another system.
This fits the broader citizen-development security problem: business users can create useful applications on approved platforms while bypassing the controls typically associated with software delivery.
How Custom GPTs Gain Access to Organizational Data Without IT Oversight
The main issue is not the GPT name or the prompt. It is the data and capabilities associated with it.
A custom GPT can use uploaded files as knowledge. Depending on the workspace configuration, it may also use connected apps or actions. Actions can call external APIs and support authentication through mechanisms such as API keys or OAuth. These features make the GPT more useful, but they also raise security questions that are very familiar to application security.
For example, an employee could upload pricing documents, internal procedures, customer support materials, or product roadmaps because the GPT needs them to answer questions. Another builder might connect an API to retrieve account information. If no one reviews the data scope, sharing model, or API permissions, the organization has created a new access path without treating it as such.
Research on custom GPT security also highlights risks around sensitive knowledge files, prompt manipulation, excessive API access, and weak governance.
When Does a Custom GPT Become Shadow AI?
Not every employee-built GPT is automatically shadow AI. If the workspace allows GPT creation, enforces sharing controls, restricts action domains, and has an approval process, the GPT may be fully governed. OpenAI provides workspace-level restrictions on actions, including controls over allowed domains.
The shadow AI problem appears when security cannot answer basic questions:
- Who created the GPT and who owns it now?
- What files or organizational data were added?
- Which apps, APIs, or actions can it use?
- Who can access or share it?
- Has its configuration changed since review?
Terminology can also cause confusion. Older policies may still refer to ChatGPT plugins, while current GPT integrations are built around apps and actions. A policy that only looks for plugins can miss the controls that matter today.
What Should Security Review Before Employees Share a Custom GPT?
A practical review does not need to turn every GPT into a six-week application-security project. Depth should follow risk.
A GPT that rewrites public marketing copy differs from one that accesses customer data or calls an internal billing API. Security should focus on ownership, data classification, sharing, authentication, connected services, and the permissions for each action. Higher-risk GPTs may also require prompt-injection testing and periodic configuration reviews.
The same issue arises with vibe coding security. When application creation becomes easier, security cannot rely solely on traditional development checkpoints. The control has to follow the asset, the data it touches, and what it can do.
Final Thoughts
Custom GPTs do not become low risk simply because they are built through a friendly interface. Once employees add internal knowledge, integrations, or reusable workflows, they have created something that deserves application-level visibility. The goal is not to block every custom GPT. It is to ensure that employee-built AI does not become invisible software.