Hidden custom GPT security risks are really NHI governance gaps

At a glance

What this is: Token Security argues that custom GPTs become NHI governance problems when shared knowledge, broad action schemas, and inherited credentials let any user trigger access beyond the original intent.

Why it matters: This matters because IAM and NHI programmes must govern the GPT itself as an identity-bearing surface, not just the human who invokes it or the app it connects to.

Context

Custom GPTs are user-configured AI assistants that can carry shared files, external integrations, and delegated credentials. The security problem is not the model alone, but the permissioned wrapper around it: once a GPT can read knowledge artifacts or call third-party systems, it behaves like a governed identity surface.

Token Security's analysis frames that surface as a non-human identity issue rather than a prompt-engineering issue. That framing matters because access scope, sharing settings, credential ownership, and audit attribution determine who can do what through the GPT, and those controls often outlive the person who created it.

The central governance gap is that organisations may review the human user while ignoring the GPT's own inherited permissions. In practice, that creates a shared access object with real operational reach, which is exactly the pattern identity programmes are meant to inventory, constrain, and retire.

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. If teams only review the human account, they miss the delegated access path that actually performs the work. That creates shared, identity-bearing access without a clear lifecycle owner.

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. The problem is not the model output alone. It is the inheritance of the credential's scope into a shared interface that can be triggered by many people.

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. If a GPT can be duplicated, edited, or broadly shared, those rights should be treated as part of the access model, not as convenience features.

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.

Technical breakdown

Why custom GPT knowledge files behave like exposed shared storage

Custom GPT knowledge uploads are not private to each user once the GPT is shared. Anyone with access to the GPT can potentially retrieve the embedded files, because the knowledge store becomes part of the GPT's operating context rather than a separately protected document repository. If sensitive material such as PII, internal notes, or regulated content is uploaded, the GPT becomes a distribution point for that data. This is not a model-inference problem alone; it is an access-control problem around who can reach the shared artefacts that the GPT can surface.

Practical implication: classify GPT knowledge uploads as shared data assets and block sensitive content unless the sharing boundary is fully intentional.

How custom actions turn a GPT into an identity-bearing executor

Custom actions let a GPT call external APIs, databases, and SaaS platforms using API keys or OAuth tokens tied to a service or user identity. The practical risk is schema overreach: if the action is broad, every GPT user can invoke the permissions behind that credential, even when their own role would not justify it. Audit logs then point to the token or service identity, not the human who triggered the action, which obscures accountability and makes misuse harder to detect. In NHI terms, the GPT inherits the identity posture of the credential it is handed.

Practical implication: treat every action credential as an NHI with bounded scope, owner, and log attribution before the GPT is shared.

Why sharing settings are a governance control, not a convenience toggle

Custom GPT sharing controls determine whether recipients can only chat, inspect settings, or edit the configuration. That distinction matters because view and edit access can expose prompts, connected actions, and the underlying security assumptions that made the GPT safe or unsafe in the first place. The article's key governance point is that sharing a GPT also shares its permissions and capabilities, so distribution choices become part of the identity model. Without clear ownership and offboarding, a GPT can remain active after the original business need has changed.

Practical implication: tie each GPT to an owner, review its share level, and retire it when the access model no longer matches its business purpose.

Threat narrative

Attacker objective: The objective is to use the GPT's delegated permissions to access data or perform actions beyond the user's legitimate scope.

1. Entry occurs when a user with access to a shared custom GPT opens a GPT that includes knowledge files or custom actions.
2. Credential use follows when the GPT invokes a custom action through API keys or OAuth tokens tied to a broader identity than the user expects.
3. Escalation occurs when the action schema is too broad, allowing the GPT to perform operations beyond the original intended scope.
4. Impact is data exposure, privileged action execution, or misleading audit attribution that hides which human initiated the activity.

Breaches seen in the wild

• Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

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 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.

Shared knowledge is an NHI-style disclosure boundary: The risk is not that a model is clever enough to leak data on its own, but that shared files become reachable by every entitled GPT user. That is structurally similar to overexposed machine-readable storage attached to a privileged workflow. The named concept here is shared GPT knowledge exposure: content intended for one use path becomes available through a broader access path than the owner assumed. Practitioners should treat uploaded artefacts as governed assets, not auxiliary context.

OAuth and API keys create privilege inheritance that outlives the chat session: The article's strongest operational warning is that any user can act through the GPT's credential scope. That is a classic least-privilege failure, but in this setting it is also a delegation problem because the audit trail follows the credential, not the human. Practitioners should re-evaluate whether their current ownership and logging model can distinguish the operator from the executor.

Sharing level is part of the security design, not post-setup administration: Invite-only, workspace, view, and edit controls are not cosmetic options. They define who can inspect, duplicate, or modify the GPT's behaviour and therefore who can amplify its effective privilege. The implication is that access reviews for custom GPTs must include configuration rights, not just usage rights, before the GPT is allowed into a production workflow.

NHI governance for custom GPTs must include retirement discipline: The article correctly points to decommissioning GPTs that are no longer actively maintained. That is important because stale assistants can retain sensitive files, integrations, and permissions after the original owner has moved on. The discipline is the same as service account offboarding: if the business purpose ends, the identity surface should not remain live by default.

What this signals

Shared GPT knowledge exposure: Custom GPTs collapse content distribution and assistant behaviour into one access surface, which means uploaded knowledge should be treated like governed data rather than convenience storage. If the organisation cannot explain who may see the artefact, who may duplicate the GPT, and who can modify its configuration, the assistant is already outside acceptable identity control. Inline governance needs to follow the share boundary, not the chat interface.

The more a custom GPT can act on behalf of a credential, the more it resembles an NHI that must be owned, scoped, reviewed, and retired. That is the programme-level shift: identity teams should stop asking whether the model is safe in the abstract and start asking whether the delegated permissions are narrow, attributable, and still needed. The same lifecycle discipline used for service accounts applies here.

Custom GPTs also expose a familiar control gap: audit trails often prove which credential acted, not which person initiated the action. That means detection and recertification have to include configuration-level evidence, not just user activity. Organisations that do not inventory GPTs and their action scopes will struggle to explain access after the fact.

For practitioners

• 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.
• Review sharing and edit rights as part of access governance Check who can chat, view settings, duplicate, or edit each GPT, because those permissions change both reach and control of the underlying integrations.
• Retire stale GPTs and revoke their credentials Remove GPTs that are no longer actively maintained and revoke the tokens or API keys they depend on so dormant access does not persist.

Key takeaways

• Custom GPTs create a non-human identity problem when shared knowledge, action schemas, and delegated credentials are treated as harmless add-ons.
• The main risk is not the model itself but the access path behind it, especially when broad tokens and workspace sharing let many users operate through one credential.
• Governance has to cover ownership, share level, credential scope, and retirement, or the GPT will outlive the control assumptions behind it.

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.
• Knowledge Artifact: A knowledge artifact is a file or document uploaded into a custom GPT so the assistant can use it during responses. If the GPT is shared, that material may be retrievable by more people than the original uploader intended, which makes the artefact part of the access model.
• Delegated Credential: A token, key, or other secret that allows one system to act on behalf of another identity. For agentic environments, delegated credentials matter because they extend trust into runtime, where the agent can use them to reach tools, data, or services without a fresh human approval.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.