Topic starter
07/03/2026 9:50 pm
TL;DR: Custom GPTs, Gemini Gems, and Claude Projects are spreading across business teams, with Token Security seeing about one custom AI assistant for every three employees, while file exposure, shared credentials, and confusing sharing controls create hidden access risk. The governance problem is not the chatbot interface, but the identity and permission model underneath it.
Editorial analysis by NHI Mgmt Group, based on content published by Token Security: “Inside the Security Gaps of Custom AI Assistants”.
Key questions
Q: What breaks when a custom AI assistant is shared beyond its original creator?
A: The assistant stops behaving like a personal productivity tool and starts functioning as a shared access object.
Q: Why do AI assistants create new access risks for IAM and PAM programmes?
A: AI assistants can combine multiple permissions into one response, which means a user may see sensitive context without directly opening the source asset.
Q: How do you know if a custom AI assistant is exposing more than it should?
A: You know it is exposing too much when the assistant can reveal uploaded files, act with broad integration permissions, or be shared to audiences that exceed the sensitivity of the data it holds.
Practitioner guidance
- Inventory every custom assistant Discover GPTs, Gems, and Claude Projects that have been created by business users, then record their owner, connected services, uploaded files, and sharing scope.
- Separate creator access from user access Determine whether each assistant uses the creator's credentials, the end user's credentials, or inherited workspace permissions, then prohibit shared API keys where possible.
- Review assistant sharing as data exposure Test what a viewer or chat-only user can actually retrieve, including instructions, uploaded files, and duplicated configuration, before allowing wider sharing.
Bottom line: Custom AI assistants create a governance gap because they package files, instructions, and delegated access into objects that employees can build and share informally.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
06/10/2026 6:44 pm
Custom AI assistants are becoming shadow access objects, not just shadow IT. When sales, finance, HR, and operations staff can build them in minutes, the governance problem shifts from developer-managed AI to business-owned access sprawl. That means identity teams can no longer assume AI risk is confined to engineering-controlled agent platforms. The practitioner conclusion is that every assistant with files or integrations belongs in the access inventory.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How should organisations govern AI assistants that can run local commands?
A: They should govern them like privileged machine identities with bounded authority, not like ordinary productivity software. That means defining who can enable execution mode, which repositories are eligible for tool use, and what evidence is required before an assistant can touch local credentials or system commands.
👉 Read our full editorial: Custom AI assistants are creating a new identity governance gap