TL;DR: Custom GPTs can expose knowledge files, over-privileged API keys, and OAuth-backed custom actions to anyone with access, turning the GPT into an ungoverned non-human identity, according to Token Security. The real failure is assuming a shared GPT is just a chat surface when its permissions, data access, and audit trail can outlive the user who triggers them.
NHIMG editorial — based on content published by Token Security: Hidden Custom GPT Security Risks & How to Find Them
By the numbers:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
Questions worth separating out
Q: How should security teams govern custom GPTs that can call external systems?
A: Treat each custom GPT as a non-human identity with an owner, a narrow purpose, and a bounded set of credentials.
Q: Why do custom GPTs create more risk than a normal chatbot?
A: A custom GPT can hold knowledge artifacts and execute actions using API keys or OAuth tokens, so the risk is not just what it says.
Q: What breaks when a custom GPT is shared too broadly?
A: Broad sharing breaks the assumption that only a limited set of users can exercise privileged behavior.
Practitioner guidance
- Inventory every action-bearing GPT Build a register of all custom GPTs that can call external systems, including owner, purpose, connected apps, sharing level, and credential type.
- Constrain knowledge uploads Allow only files and instructions that are safe for every user who can access the GPT.
- Issue unique least-privilege credentials Create one credential per custom action and scope it to the minimum API methods, tables, or repositories required.
What's in the full article
Token Security's full blog covers the operational detail this post intentionally leaves for the source:
- A walkthrough of how custom GPT knowledge files can be extracted through the chat and why that matters for sensitive document handling.
- Practical examples of over-privileged custom action schemas using GitHub and Snowflake, including how broad credentials change the risk profile.
- The Token Security GCI tool details, including what it inventories in an enterprise OpenAI environment and how it supports GPT discovery.
- Sharing-mode examples that show how invite-only, workspace, and public access affect who can use or modify a GPT.
👉 Read Token Security's analysis of hidden custom GPT security risks →
Custom GPTs and NHI risk: are your controls keeping up?
Explore further
Custom GPTs are non-human identities in governance terms, even when teams still describe them as chat experiences. The moment a GPT can authenticate to Salesforce, Snowflake, GitHub, or internal APIs, it becomes an executable identity with real permissions and audit impact. That means ownership, scope, and offboarding matter as much here as they do for service accounts. Practitioners should stop treating GPTs as UI features and govern them as identities.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure, according to The 2025 State of NHIs and Secrets in Cybersecurity.
A question worth separating out:
Q: Who is accountable when a custom GPT performs an unintended action?
A: Accountability should sit with the team that owns the GPT, its configuration, and the credential it uses. Audit logs often show the token owner or service identity, not the person who typed the prompt, so governance must include ownership, logging, and revocation paths. Otherwise, responsibility becomes ambiguous after the fact.
👉 Read our full editorial: Hidden custom GPT security risks are really NHI governance gaps