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

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.

Why This Matters for Security Teams

When employees can create and share custom AI assistants without a controlled approval path, access stops behaving like a static entitlement and starts behaving like a distributed execution layer. That matters because an assistant can inherit the creator’s permissions, act on uploaded files, call connected SaaS tools, and move sensitive data into contexts that were never reviewed as a formal business requirement. The result is shadow access, not just shadow IT.

Security teams often miss this because the assistant looks benign at creation time, while the risk emerges later when the same agent is reused across teams or data domains. The control problem is not only who can sign in, but what the assistant can do after it is granted tool access. NHI Management Group’s research on the DeepSeek breach shows how quickly exposed AI-related secrets and data can widen blast radius once they are reachable in the wild. Current guidance from the NIST Cybersecurity Framework 2.0 still applies, but it must be interpreted through the lens of autonomous and semi-autonomous assistants rather than human-only workflows.

In practice, many security teams encounter overexposure only after an assistant has already been shared into the wrong workspace or connected to the wrong data source, rather than through intentional access review.

How It Works in Practice

Freely shared assistants break the normal assumptions behind IAM because the identity of the person who created the assistant is not the same as the identity of the assistant while it is acting. The assistant may retain tokens, inherit delegated scopes, or operate through connected apps long after the creator intended. That is why modern guidance increasingly treats the assistant as a workload identity problem, not just a user permissions problem. In NHI terms, the assistant needs its own lifecycle, its own authorization boundaries, and its own revocation path.

Practically, teams should separate three layers:

• Creator access, which governs who can build or publish the assistant.

• Assistant execution access, which governs what the assistant can do at runtime.

• Data and tool access, which governs which sources the assistant may touch.

That separation is where controls such as just-in-time permissions, short-lived secrets, and policy evaluation at request time become important. The better pattern is to issue narrow, ephemeral access for a specific task, then revoke it when the task completes. This aligns with emerging agentic guidance in LLMjacking: How Attackers Hijack AI Using Compromised NHIs, which shows how quickly compromised AI-related credentials can be abused once they are exposed. For implementation direction, the SPIFFE project is useful because it frames workload identity as cryptographic proof of what a workload is, not merely a shared secret.

Teams also need real-time authorization logic because pre-approved role lists do not account for an assistant chaining actions across multiple tools in a single session. Current best practice is evolving toward policy-as-code and context-aware decisioning rather than static RBAC alone. These controls tend to break down when assistants are allowed to publish copies of themselves into unmanaged workspaces because the control plane cannot reliably track every inherited permission path.

Common Variations and Edge Cases

Tighter assistant governance often increases friction for users, requiring organisations to balance speed of adoption against the cost of review, revocation, and exception handling. That tradeoff is real, especially where business teams want experimentation but security teams need traceability. There is no universal standard for this yet, so organisations should label their stance clearly: what can be shared, what must stay private, and what requires security review before reuse.

One common edge case is the “personal productivity” assistant that begins as a single-user aid and later becomes a de facto team tool. Another is the assistant embedded in a collaboration suite, where permissions are inherited from the creator but the outputs are visible to a broader audience. A third is data leakage through uploaded files or generated summaries, which can persist even after the original source is removed. The The State of Secrets in AppSec research is relevant here because secret sprawl and slow remediation amplify the impact of assistant reuse across multiple systems. The NIST Cybersecurity Framework 2.0 remains a useful baseline, but it should be paired with runtime policies for assistants, not only periodic access reviews.

Best practice is evolving toward treating shared assistants as governed software artifacts with owners, scopes, and expiry dates. That approach is especially important when assistants are connected to sensitive systems because a copy can outlive the original review and continue operating with stale trust.

Related resources from NHI Mgmt Group

• What breaks when AI assistants are allowed shell access on unmanaged devices?
• What breaks when AI tools are allowed broad write access to internal systems?
• When is it crucial to implement least-privilege access for AI agents?
• What is the difference between managed identities and hardcoded secrets for AI agents?