Custom AI assistants are creating a new identity governance gap

At a glance

What this is: This is an analysis of security gaps in custom AI assistants, showing that uploaded files, inherited credentials, and permissive sharing settings can expose sensitive data and broad access.

Why it matters: It matters because these assistants sit at the intersection of NHI, human access, and emerging agentic behaviour, so IAM teams need governance that follows the access they inherit and expose.

👉 Read Token Security's analysis of custom AI assistant security gaps

Context

Custom AI assistants are internal tools that let users upload files, connect external services, and share the resulting assistant with others. The security issue is that the assistant often inherits real permissions, while the people creating it may not understand the access they are extending into it. For identity teams, this is a governance problem before it is a chatbot problem.

The primary gap is visibility. These assistants spread outside formal IAM workflows, yet they still carry files, OAuth tokens, API keys, and organization-level sharing choices. That creates a shadow identity surface across human users, delegated access, and machine credentials, which is exactly where conventional review cycles lose coverage.

Key questions

Q: How should security teams govern custom AI assistants that connect to internal systems?

A: Security teams should govern custom AI assistants as access-bearing assets, not just chat tools. That means inventorying each assistant, identifying its owner, reviewing connected systems, and checking whether it uses shared secrets or user-level authentication. The access model underneath the assistant matters more than the interface, because that model determines who can see data and what actions the assistant can take.

Q: What breaks when employees can build and share custom AI assistants freely?

A: What breaks is the assumption that access only changes through formal IAM workflows. A user-built assistant can copy data, expose uploaded files, and extend credentials into new contexts without a normal approval chain. That creates shadow access paths that are hard to review after the fact, especially when permissions are inherited from the creator or the connected application.

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. The strongest signal is mismatch between the business purpose of the assistant and the privileges attached to its files, prompts, or connected accounts.

Q: Who is accountable when a shared AI assistant leaks files or credentials?

A: Accountability sits with the team that approved the assistant's ownership, access model, and connected credentials. In practice, that usually means the business owner, the identity team, and the security team all share responsibility for lifecycle control. Governance should require named ownership, periodic review, and removal of assistants that no longer have a clear business need.

Technical breakdown

Why uploaded files become an identity exposure problem

Custom assistants usually store instructions and knowledge files so the model can answer with local context. In many implementations, anyone who can use the assistant can also retrieve those files, either directly or by prompting the assistant to reveal them. That turns a convenience feature into an access boundary problem, because the assistant is now mediating data visibility rather than merely processing it. The important distinction is that the risk is not model intelligence, but the sharing model wrapped around the model.

Practical implication: classify uploaded assistant content as governed data and restrict it as tightly as any shared repository.

How integrations inherit real credentials and permissions

When a custom assistant connects to Salesforce, Drive, Slack, GitHub, or similar services, it may use a creator's API key, a shared OAuth token, or each user's own login. That choice determines whether the assistant acts with pooled access or user-scoped access. The security failure usually appears when people assume the assistant is separate from the account behind it, when in fact it is executing through that account's privileges. In NHI terms, the assistant becomes an access wrapper around existing entitlements.

Practical implication: require per-user authentication where possible and ban shared credentials for assistant integrations.

Why sharing settings behave like hidden privilege grants

Sharing a custom assistant is not the same as sharing a chat window. Depending on the platform, users with view, can chat, or workspace-level access may inherit the ability to inspect instructions, access uploaded files, or duplicate the assistant configuration. In practice, that means the sharing control is also a privilege control. For identity governance, this is a lifecycle issue because the assistant's effective access must be reviewed, recertified, and removed like any other governed asset.

Practical implication: inventory assistants by owner, audience, connected systems, and review each permission state as a distinct access object.

NHI Mgmt Group analysis

Custom AI assistants create an access surface, not just a productivity layer. The material risk is not that employees are experimenting with new tools, but that those tools carry files, credentials, and sharing permissions outside the normal security review path. That makes the assistant itself a governed identity object, even when the platform presents it as a simple workspace feature. Practitioners should treat the assistant inventory as part of the access estate, not as an optional AI add-on.

Shared assistant access collapses the distinction between collaboration and entitlement. A user who can chat with an assistant may also be able to extract uploaded content or benefit from the permissions of the account that configured the integration. That means the apparent sharing model can overstate the actual restriction model. The practical conclusion is that approval workflows for assistant sharing need to be tied to data sensitivity and downstream permissions, not just team convenience.

Identity governance for custom assistants must follow the credentials underneath the interface. If an assistant uses a creator's API key, the key is the real control point; if it uses user-level OAuth, the connected application permissions are the real control point. That is the named concept here: assistant privilege inheritance: access exposure that occurs when an AI assistant reuses the permissions of the human or service account that created it. Practitioners should anchor governance on the inherited access path, not the chat experience.

The visibility problem is bigger than shadow IT because the artefact is executable access. These assistants are not just documents or scripts. They are interactive containers for data, prompts, and live integrations, which means they can expand the blast radius of existing entitlements without a formal deployment event. Security teams should assume that unmanaged assistant sprawl will outpace manual discovery unless it is folded into identity and access inventory.

Lifecycle controls now need to cover assistant creation, sharing, and retirement. The same governance discipline used for service accounts and access certifications applies here, but the object being governed is a user-built assistant with embedded files and integrations. If ownership changes, the assistant can outlive the original business need and keep exposing the same access paths. Practitioners should recertify these objects on the same cadence as other high-risk entitlements.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Assistant sprawl becomes easier to govern when you pair that visibility problem with the control patterns in Guide to the Secret Sprawl Challenge.

What this signals

Assistant privilege inheritance: the real governance issue is not whether employees use custom AI assistants, but whether those assistants inherit data access that the security team never reviewed. As adoption grows, identity teams need a way to classify assistants by the permissions they consume and the content they can expose, not just by the platform that hosts them. That framing aligns well with the control boundaries in the Guide to the Secret Sprawl Challenge.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, according to The State of Non-Human Identity Security, the market is clearly moving toward governance of machine-held access as a first-class discipline. The next step for practitioners is to extend that governance to user-built AI assistants before they become untracked access wrappers.

Assistant sprawl is likely to surface the same failure pattern seen in broader OAuth exposure, where hidden connections matter more than the headline platform. That is why visibility into connected services, sharing scope, and credential ownership has to become part of the operating model rather than a one-off discovery exercise.

For practitioners

• Inventory every custom assistant in scope Build a register of all Custom GPTs, Gems, Claude Projects, and similar assistants, including owner, audience, uploaded files, and connected services. Use that inventory to identify where sensitive data or privileged integrations are hiding outside formal review.
• Eliminate shared API keys from assistant integrations Move integrations to per-user OAuth or equivalent user-scoped authentication wherever the platform supports it. If an assistant must use a shared secret, treat that secret as high-risk NHI and place it under strict rotation and access control.
• Review sharing states as access objects Map each permission mode, such as can chat, can use, or can edit, to the data and configuration exposure it actually creates. Re-certify assistant sharing the same way you would re-certify a privileged application or repository.
• Restrict uploaded content by sensitivity Do not upload material to an assistant unless you are willing for every authorised user to potentially retrieve it through the chat or project interface. Apply the same rule to prompts, instructions, and knowledge files as you would to shared drive content.

Key takeaways

• Custom AI assistants create hidden access exposure because they can carry files, integrations, and permissions beyond normal IAM review paths.
• The evidence points to rapid sprawl, with roughly one custom AI assistant for every 3 employees in Token Security's customer environments.
• Teams should inventory assistant ownership, remove shared secrets, and recertify sharing states as governed access objects.

Key terms

• Custom AI Assistant: A custom AI assistant is a user-configured chatbot or agent-like interface that combines instructions, files, and external integrations for a specific work purpose. It becomes an identity governance issue when the assistant inherits real access to data or applications and can expose that access through sharing or interaction.
• Assistant Privilege Inheritance: Assistant privilege inheritance is the exposure that occurs when an AI assistant uses the permissions of the human or account that created it, rather than a tightly scoped identity of its own. The risk is that the assistant can act across systems or reveal data with more access than the user intended to delegate.
• Shadow AI: Shadow AI is the use of AI tools, assistants, or agents that security and identity teams have not formally discovered, approved, or governed. It often appears first as productivity tooling, but it becomes a control problem when it carries files, tokens, or application access outside established review processes.

What's in the full article

Token Security's full blog covers the operational detail this post intentionally leaves for the source:

• Platform-specific examples of how Custom GPTs, Gems, and Claude Projects expose uploaded files in practice
• Step-by-step explanation of how Actions, Apps, Connectors, and MCP change the credential model
• Detailed breakdowns of sharing permission states such as can chat, can use, and can edit
• The open-source GCI discovery tool and how it is used to find custom assistants in an environment

👉 The full Token Security post covers file extraction, integration credentials, and sharing controls in more depth.

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.