Yes. CISA defines an insider threat as harm from someone with authorized access, including unintentional acts. AI assistants add two paths: staff placing sensitive data into prompts, and assistants acting with a person's access when they should not. Limit what data goes in, what the assistant can do, and how much it can do alone.
What counts as an insider, and where do assistants fit?
CISA describes an insider as any person who has or had authorized access to or knowledge of an organization's resources, and insider threat as the potential for that person to harm the organization, intentionally or unintentionally. The harm can touch integrity, confidentiality and availability.
The unintentional part is the useful one here. Most assistant-related exposure will not be malice. It will be a well-meaning employee pasting a customer contract into a chat window to get a summary, or an assistant that was given a broad connection and used it.
An assistant also behaves like a second identity acting for the first. It holds access, it makes requests, and it can be steered by the text it reads. That is why OWASP's lists are the right reference.
How does data leave through a prompt?
OWASP's LLM02 entry on sensitive information disclosure names the kinds of data at stake: personal information, financial details, health records, confidential business data, security credentials and legal documents. It says users need to understand the risk of unintentionally providing sensitive data that may later be disclosed in a model's output, and recommends transparency on data retention, use and deletion, plus the option to opt out of training.
For a company deploying an assistant, the practical controls it lists include sanitizing data before it reaches training, input validation, restricting data sources, and tokenization or redaction that detects confidential patterns before processing. It also warns that instructions in the system prompt limiting what the model returns may not always be honored and can be bypassed. Do not rely on a prompt as your only barrier.
How does an assistant act beyond what you intended?
OWASP's LLM06 entry on excessive agency traces the root cause to excessive functionality, excessive permissions or excessive autonomy. Its examples are concrete:
- an extension meant to read documents that can also modify and delete them;
- a read-only integration connected with an identity that can also update and delete;
- an extension that acts for one user but connects with a generic privileged account that can see everyone's files;
- an action such as deleting documents that runs with no confirmation.
OWASP's mitigations map directly to an insider program: limit the extensions an agent can call, limit what each does, avoid open-ended ones such as run any shell command, and keep permissions to the minimum on downstream systems. For high-impact actions, require approval.
Note the cause list also includes hallucination. An assistant does not need an attacker to take a wrong action. A confident mistake is enough.
What does a sensible policy look like?
Write it for people first, then enforce with controls.
- Approved tools. Name the assistants staff may use for work, and say what data classes may go in. Staff who have no approved option will use an unapproved one.
- Plain data rules. Three tiers are easier to follow than ten: fine to share, internal only, never in a prompt.
- Identity per user. Where an assistant acts for a person, it should act with that person's rights, not a shared service account.
- Least privilege for connections. Read where read is enough, and scope to the narrowest data set.
- Confirmation for destructive actions. Deleting, sending externally and changing access all need a human yes.
- Logging. Record prompts and tool calls where law and policy allow, so you can answer "what did the assistant do?"
- Offboarding. Revoke assistant connections and tokens when a person leaves, as you would any account.
What to do
- List every assistant and agent in use, approved or not, and the systems each connects to.
- Classify the data staff are most likely to paste, and publish a three-tier rule.
- Replace shared service accounts on connections with per-user or narrowly scoped identities.
- Strip any tool that is not needed, especially open-ended ones.
- Require confirmation for deletion, external sending and permission changes.
- Turn on logging for tool calls and review a sample monthly.
- Add assistants to your joiner, mover and leaver checklist.
- Train staff with real examples from your own workflows, and repeat yearly.
Quick check
Is a system prompt rule enough to stop an assistant leaking data?
No. OWASP notes such restrictions may not always be honored and can be bypassed. Combine them with data sanitization, access controls and output checks.
What is the quickest risk reduction?
Narrow the assistant's connections. Read-only access to a limited data set removes whole classes of damage, whatever caused the mistake.
Sources
- CISA, Insider Threat Mitigation
- OWASP Gen AI Security Project, LLM02:2025 Sensitive Information Disclosure
- OWASP Gen AI Security Project, LLM06:2025 Excessive Agency
Last reviewed: 18 October 2026.
