Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Custom GPTs and NHI risk: are your controls keeping up?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 9439
Topic starter  

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:

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

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 8923
 

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:

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



   
ReplyQuote
Share: