Topic starter
06/07/2026 9:42 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by Token Security: “Hidden Custom GPT Security Risks & How to Find Them”.
Key questions
Q: What breaks when a custom GPT is treated as just a chat surface?
A: The governance model breaks because the GPT may carry files, credentials, and action permissions that extend far beyond the user's own role.
Q: Why do broad custom action schemas increase risk in shared GPTs?
A: Broad schemas let any GPT user invoke the permissions behind the connected token, even when their job function would not justify that access directly.
Q: How should organisations govern custom GPT sharing and ownership?
A: Assign an owner, document what the GPT can access, and review whether the share level still matches the business use case.
Practitioner guidance
- Inventory every custom GPT as an identity-bearing asset Record each GPT owner, share level, knowledge source, and connected action so the assistant itself is visible in governance and review cycles.
- Scope every action credential to a single business purpose Issue unique OAuth tokens or API keys per custom action and keep the permission set as narrow as the action schema allows.
- Block sensitive knowledge uploads by default Require review before adding PII, regulated content, or high-value internal documents to any GPT knowledge base that can be shared with others.
Bottom line: Custom GPTs create a non-human identity problem when shared knowledge, action schemas, and delegated credentials are treated as harmless add-ons.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/07/2026 9:58 am
Custom GPTs are governance objects, not just AI interfaces: The article shows that once knowledge files and actions are shared, the GPT itself becomes an access-bearing entity. That changes the unit of control from the human user to the configured assistant, which is how NHI programmes should already think about service identities and delegated access. Practitioners should govern the GPT as a discrete identity surface with explicit ownership and lifecycle.
A question worth separating out:
Q: When should a custom GPT be decommissioned or rebuilt?
A: Rebuild or retire it when the original owner, data source, or business purpose changes materially, or when the connected credentials are no longer scoped appropriately. A GPT that is no longer actively maintained should not keep its access path, because stale configuration becomes residual privilege.
👉 Read our full editorial: Hidden custom GPT security risks are really NHI governance gaps