Hidden custom GPT security risks are really NHI governance gaps

At a glance

What this is: This analysis shows that custom GPTs become security risks when their knowledge, sharing settings, and custom actions are treated as convenience features rather than governed identity and access paths.

Why it matters: IAM, NHI, and human identity teams need to treat each GPT as an identity-bearing workload because overbroad sharing or credentials can expose data and actions beyond the intended user boundary.

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.

👉 Read Token Security's analysis of hidden custom GPT security risks

Context

Custom GPTs blur the line between a conversational interface and an identity-bearing workload. Once a GPT can call external systems with API keys or OAuth tokens, its security posture depends on credential scope, sharing rules, and the data it is allowed to expose.

That makes this an NHI governance problem as much as an AI usability problem. If a GPT can read files, query databases, or trigger third-party actions on behalf of a broader service identity, then inventory, ownership, least privilege, and offboarding all become mandatory controls rather than optional hygiene.

Key questions

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. Inventory the GPT, restrict its sharing, scope its actions to the minimum necessary API surface, and revoke it when the business need ends. If the GPT can perform real work, it needs identity governance, not just content review.

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. It can expose data, trigger downstream systems, and inherit overbroad permissions from the credential behind the action. That makes the GPT a governed identity with real blast radius.

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. Anyone with access to the GPT may be able to use its connected credentials, see its knowledge, or trigger actions that exceed their own role. The result is privilege amplification hidden behind a simple sharing link.

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.

Technical breakdown

Custom GPT knowledge stores and data exfiltration

A custom GPT can be configured with uploaded files, instructions, and other knowledge artifacts that become available to anyone interacting with it under the allowed access model. If those artifacts contain sensitive content, the risk is not theoretical prompt leakage alone. A user may be able to coerce the GPT into revealing mounted files or other accessible knowledge through legitimate interfaces and tool support. The control issue is that the knowledge layer behaves like shared content with identity-like exposure, not like a private notebook.

Practical implication: classify GPT knowledge artifacts as shared data assets and block sensitive uploads unless ownership, access, and retention are explicit.

Custom actions turn GPTs into non-human identities

Custom actions connect a GPT to external systems using API keys, OAuth tokens, or service credentials. That means the GPT does not merely generate text, it executes requests with the authority of the identity behind those credentials. If the schema is broad or the token is over-privileged, every user with access to the GPT can inherit capabilities far beyond their own role. In practice, the GPT becomes a non-human identity whose behavior is bounded by the weakest combination of schema design and credential scope.

Practical implication: scope every action to the narrowest API surface and issue unique credentials that can be revoked without breaking other workflows.

Sharing settings extend privilege beyond the original builder

GPT sharing controls determine not just who can chat, but who can view configuration, duplicate the GPT, or edit its settings. That is an identity governance issue because the sharing model can move a GPT from controlled internal use to broad workspace or public access without changing the underlying permissions on the connected systems. The governance failure is often not the action itself, but the mismatch between who can use the GPT and what the GPT can do once invoked.

Practical implication: review GPT sharing tiers as access entitlements and require explicit approval before any GPT with real system access is shared widely.

Threat narrative

Attacker objective: The attacker objective is to use the GPT as an identity proxy to access data or execute actions that the initiating user should not be able to perform directly.

1. Entry occurs when a user or external actor gains access to a shared custom GPT that has uploaded knowledge or custom actions attached to it. The initial foothold is the GPT itself, not the downstream system.
2. Escalation happens when the GPT executes an action with over-privileged API keys, OAuth tokens, or service credentials that grant broader access than the user should have. The actor inherits the identity’s authority through the GPT configuration.
3. Impact follows when the GPT reads sensitive files, queries protected data, or triggers privileged operations on connected systems, with audit logs pointing to the credential owner rather than the actual user behind the request.

Breaches seen in the wild

• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Shared GPTs create an identity blast radius that most access models do not account for. A single GPT can expose uploaded knowledge, custom actions, and inherited credentials to every user who can reach it, which breaks the assumption that access to the interface equals limited access to the underlying systems. Identity blast radius: the spread between who can invoke a GPT and what the GPT can do once invoked. Practitioners should measure that spread before broad sharing is allowed.

Least privilege fails at the action schema when the schema is broader than the task. In custom GPT setups, the dangerous control plane is not only the token, but the permitted API surface attached to that token. If the GPT can write when the task only requires read, or reach multiple databases when it only needs one table, the resulting exposure is structural. Practitioners should align schema scope to task scope, not just credential type.

Prompt injection is a governance failure when the GPT is already authorised to do too much. The attack succeeds because the model can be induced to use real credentials against real systems, which turns content processing into an execution path. That is why AI content safety and NHI governance cannot be separated in custom GPT programmes. Practitioners should treat action-bearing GPTs as privileged workloads with hostile-input exposure.

Lifecycle governance for custom GPTs is where most programmes will be weakest. GPTs can outlive the project, the owner, or the original business need, while their credentials, sharing links, and stored knowledge remain active. That is the same lifecycle failure pattern seen in service-account sprawl, just hidden behind a conversational interface. Practitioners should connect GPT governance to the same joiner-mover-leaver discipline used for other non-human identities.

From our research:

• 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.
• For a broader control baseline, see NIST Cybersecurity Framework 2.0 alongside the identity-specific controls in your GPT governance model.

What this signals

Custom GPT governance will increasingly sit inside NHI programmes, not beside them. The practical question is no longer whether AI can be embedded in workflows, but whether the GPTs doing that work have clear owners, limited scopes, and revocation paths. Programmes that already struggle with service-account sprawl should expect the same pattern to reappear with AI-driven interfaces unless they extend their lifecycle controls to GPTs.

The fastest way to reduce risk is to separate conversational access from execution authority. A GPT can be widely visible while its action layer remains tightly constrained, but that only works if teams catalogue each integration, each credential, and each sharing tier as a distinct entitlement. The programme signal to watch is whether the GPT inventory can be reconciled back to owners and revocation records without manual forensics.

Identity blast radius is the right concept for custom GPT review. It describes the gap between who can invoke a GPT and what that GPT can do through connected systems, and that gap tends to widen when knowledge files, custom actions, and sharing links are managed separately. Teams should use the term to drive cross-functional review between IAM, security engineering, and AI platform owners.

For practitioners

• 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. Treat any GPT without an identified owner as an unmanaged identity and remove its access until governance is assigned.
• Constrain knowledge uploads Allow only files and instructions that are safe for every user who can access the GPT. Prohibit sensitive company data, PII, and operational secrets unless the GPT is restricted to a tightly controlled audience with explicit review.
• Issue unique least-privilege credentials Create one credential per custom action and scope it to the minimum API methods, tables, or repositories required. Avoid reusing the same token across multiple GPTs because shared credentials widen blast radius and complicate revocation.
• Review sharing as an access control decision Require approval before moving a GPT from invite-only to workspace-wide or public access. If the GPT can perform real actions, the sharing tier is effectively an entitlement change and must be reviewed like any other privilege increase.
• Monitor for anomalous GPT activity Log each action request, the invoking user, the credential used, and the target system, then alert on spikes, unusual destinations, or requests that exceed the GPT’s original use case. Tie those alerts back to the identity that owns the credential, not just the person who clicked chat.

Key takeaways

• Custom GPTs are identity-bearing workloads once they can read files or call external systems, which means they need governance as much as any other non-human identity.
• The biggest failure mode is privilege amplification through broad sharing, over-privileged actions, and retained knowledge artifacts that outlive the original use case.
• Teams should inventory GPTs, scope credentials tightly, restrict sharing deliberately, and connect GPT lifecycle management to existing identity processes.

Key terms

• Custom GPT: A custom GPT is a configured GPT instance that can use uploaded knowledge and external actions to perform tasks for a specific purpose. In security terms, it is not just a prompt wrapper. It can expose data, call services, and inherit the permissions of the credentials tied to it.
• Custom Action: A custom action is an integration that lets a GPT send requests to an external system using API keys, OAuth tokens, or similar credentials. The action defines what the GPT can do, so its schema and credential scope become the real security boundary for the identity behind it.
• Identity Blast Radius: Identity blast radius is the spread between the access a user thinks they have and the access a GPT can exercise on their behalf. It grows when sharing is broad, actions are over-privileged, or a single credential powers multiple integrations. The concept helps teams measure hidden privilege amplification.
• Prompt Injection: Prompt injection is the use of malicious instructions inside content that an AI system reads, causing it to behave in ways the operator did not intend. For GPTs with real system access, the risk is not only bad output. It is unintended execution through trusted credentials.

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.

👉 Token Security's full post covers GPT knowledge leakage, action abuse, and sharing controls in more detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.