Yes, in one specific way. An assistant acts with the access of the person who runs it, so a mistake, a tricked prompt or a bad actor can use that access at machine speed. Treat each assistant as a new insider: give it its own narrow identity, log what it does and require approval for risky actions.
What is an insider, in this context?
CISA defines an insider as anyone with authorized access to or knowledge of an organization's resources, and insider threat as the potential for that person to use the access to cause harm, intentionally or unintentionally. The second half matters here. Most assistant incidents will be unintentional: a pasted secret, a document summarized to the wrong place, a tool call nobody meant to make.
Where does the risk actually come from?
Three places, each tied to an entry in the OWASP Top 10 for LLM applications.
Disclosure. Sensitive information disclosure is LLM02. Anything a person pastes into an assistant, or any file it can read, can show up somewhere unintended.
Over-permission. Excessive agency is LLM06. An assistant connected to email, tickets and code with broad write access can do much more than its task needs.
Instruction hijack. Prompt injection is LLM01. OWASP says a model can read instructions hidden in content it processes, such as web pages or files, and that severity depends on how much agency the model has.
What does a good control set look like?
OWASP's mitigation list for prompt injection translates directly to insider controls: constrain the model's role, enforce least privilege with the application's own tokens, require human approval for high risk actions, and mark external content as untrusted. Add the usual insider program steps CISA lists: define what counts, detect, assess and manage.
What to do
- Inventory every assistant in use, including browser extensions and personal accounts used for work. Ask people, do not guess.
- Give each assistant its own identity and token, not a person's session.
- Reduce each token to read only where possible. Grant write access per task, with an expiry.
- Decide which actions need a person to click approve: sending external email, deleting data, changing permissions, pushing code.
- Log prompts, tool calls and results to a place the assistant cannot edit, and say how long you keep them.
- Write a short rule on what may be pasted: no credentials, no customer data, no unreleased source unless the tool is approved for it.
- Put an unusual-activity alert on large exports and on tool calls at odd hours.
- Review the list quarterly and remove assistants nobody uses.
Is this about distrusting employees?
No. It is the same logic as separating duties and issuing badges. A control that limits what a tool can do protects the person using it, because the log shows the tool did it and who approved it.
How does Safeguard fit in?
Safeguard's MCP server lets assistants query it, and tenant admins can switch off any client type, including MCP clients, ChatGPT, Claude, desktop, mobile, CLI and IDE. That gives you a switch for the assistants that touch Safeguard. It does not govern assistants outside it.
Quick check
What is the first thing to fix?
Shared credentials. If an assistant runs on a person's token, you cannot separate their actions from its actions.
Do we need to block assistants entirely?
Not usually. Scope them, log them, and gate the risky actions.
Sources
- CISA, Insider Threat Mitigation
- OWASP Top 10 for LLM Applications
- OWASP, LLM01:2025 Prompt Injection
Last reviewed: 18 October 2026.
