Internal AI Assistant

Internal AI assistants are employee-facing artificial intelligence systems embedded into workplace environments to retrieve information, answer questions, summarize content, generate work product, or perform actions across internal systems. They may connect to knowledge bases, mailboxes, document stores, chat platforms, ticketing systems, calendars, customer relationship management systems, and source code repositories.

 

This deployment pattern creates an elevated exposure condition because the synthetic subject operates inside the organization’s trust boundary with standing access to internal data and tools. Service identities, delegated permissions, or broad connectors may allow it to retrieve information across many users, teams, channels, or repositories, giving it broader practical reach than any single human subject should normally possess.

 

The main risk is the combination of trusted internal access and untrusted or weakly trusted content. A malicious instruction may be planted in an email, shared document, calendar invite, wiki page, support ticket, chat message, or code comment, then influence the assistant when that content is later retrieved during a legitimate employee request. This is commonly described as indirect prompt injection.

 

Investigative Relevance

Internal AI assistants are high-trust synthetic insider patterns because they operate inside normal employee workflows. They may be treated as productivity tools, but their access, retrieval behavior, and ability to act across systems can make them significant investigative subjects.

Subsections (4)

ID Name Description
DR002.003Collaboration Suite Assistant

A collaboration suite assistant is an artificial intelligence system embedded into workplace tools such as email, chat, documents, meetings, calendars, and shared drives. It may summarize content, draft replies, search documents, identify actions, or perform tasks across an employee’s workspace.

 

This deployment pattern creates an elevated exposure condition because the assistant processes both trusted internal content and untrusted inbound material. Emails, calendar invites, shared documents, chat messages, and meeting notes may originate from external parties, compromised identities, or low-trust sources before entering the assistant’s context.

 

The primary risk is zero-click or low-interaction indirect prompt injection. A malicious instruction may be hidden in an inbound message, document, meeting invite, or chat thread and remain dormant until the assistant summarizes, searches, drafts, or acts on that content.

 

A related risk is excessive tenant reach. If broad connector permissions, service identities, shared indexes, or weak query-time access checks allow retrieval across the wider tenant, one mailbox, thread, document, or meeting record may expose information beyond the employee’s entitlement.

 

Investigators should review the assistant’s directive, tenant permissions, connectors, retrieval scope, logs, tool calls, rendered links, external content handling, and source provenance. Particular attention should be given to embedded instructions, retrieval outside the employee’s entitlement, and outputs that transmit, summarize, or link to sensitive material.

 

Investigative Relevance

Collaboration suite assistants are relevant to SITM because they sit inside ordinary organizational workflows and process the communications employees rely on every day. Their retrieval, summarization, and action capability may exceed what the employee expects or is authorized to access.

DR002.002Developer Coding Assistant

A developer coding assistant is an artificial intelligence system embedded in, or connected to, the software development environment. This may include an integrated development environment (IDE) extension, repository-aware coding assistant, code completion tool, terminal-capable agent, or automated refactoring assistant.

 

This deployment pattern creates an elevated exposure condition because the assistant operates close to the software supply chain. Its output may become source code, configuration, tests, build logic, documentation, or command execution inside a project. Vulnerable logic, unsafe dependency changes, insecure configuration, or hidden backdoor functionality may then be reviewed as ordinary developer work.

 

The primary risk is that the synthetic subject can introduce insecure or malicious code that is later attributed to the human developer who accepted, edited, or committed it. This risk is heightened where suggestions are accepted under time pressure, generated code is difficult to review, or automated tests confirm functionality without detecting security impact.

 

A related risk is context poisoning. Developer coding assistants commonly use project files, comments, dependency manifests, configuration files, issue text, documentation, or local rule files as generation context. If a low-trust contributor, compromised dependency, external issue, or malicious insider places instructions into that context, the assistant may treat them as project guidance.

 

Investigators should review the assistant’s directive, development environment configuration, repository context sources, local instruction files, generated diffs, accepted completions, command history, dependency changes, and commit timeline. Particular attention should be given to suspicious generated code, embedded instructions in repository context, and logs that preserve both the human developer action and the synthetic subject’s contribution.

 

Investigative Relevance

Developer coding assistants are relevant to SITM because they can influence software that later runs in production, security tooling, customer environments, or internal infrastructure. The synthetic subject may not deploy the code directly, but it can shape the implementation a human developer reviews and commits.

DR002.001Internal Knowledge Assistant

An internal knowledge assistant is an employee-facing artificial intelligence system that answers questions using internal documents, wikis, file stores, tickets, policies, procedures, and other indexed sources. It is commonly implemented using Retrieval-Augmented Generation (RAG), where relevant source material is retrieved before an answer is generated.

 

This deployment pattern creates an elevated exposure condition because the retrieval index becomes part of the synthetic subject’s instruction surface. Any indexed document, ticket, page, comment, or shared file may later enter the assistant’s context. If that content contains malicious or misleading instructions, the assistant may treat them as relevant during an ordinary employee query.

 

The primary risk is that a planted or low-trust document can influence answers drawn from higher-trust material. A malicious outsider or low-trust insider may not need direct access to sensitive repositories if they can place content somewhere the assistant indexes.

 

A related risk is permission and access-boundary failure. The assistant may retrieve, summarize, or infer information from documents the human requestor is not entitled to view. This can occur through a shared service identity, broad retrieval index, cached embeddings, inherited connector permissions, or weak query-time access controls.

 

Investigators should review the assistant’s directive, retrieval configuration, indexed sources, ingestion process, access controls, source ranking, logs, and retrieved source records. Particular attention should be given to retrieval outside the employee’s entitlement, embedded instructions in indexed material, and answers that are not grounded in approved sources.

 

Investigative Relevance

Internal knowledge assistants are relevant to the SITM because they convert internal document stores into conversational answers at workforce scale. Their retrieval process may combine content across repositories, trust levels, and access boundaries in ways that employees cannot easily observe.

DR002.004Mailbox Agent with Send Authority

A mailbox agent with send authority is an internal artificial intelligence assistant that can read, draft, reply, forward, schedule, route, or send messages on behalf of an employee. Unlike a read-only mailbox assistant, it can act through the employee’s communication identity.

 

This creates an elevated exposure condition because the assistant combines mailbox access with outbound action. A malicious instruction hidden in an email, attachment, calendar invite, or message thread may cause the synthetic subject to disclose information, forward sensitive content, send unauthorized replies, or route messages externally.

 

The primary risk is that write and send capability collapses the gap between data exposure and action. A single indirect prompt injection may retrieve sensitive information and transmit it outward. Because messages may be sent under the employee’s identity, the activity can appear authorized, making attribution and containment harder.

 

A related risk is attributed communication. If the assistant sends or drafts from a named employee’s mailbox, a manipulated response may appear to be that individual’s deliberate statement. This can expose the organization to disputes, claims, regulatory scrutiny, or reputational harm where the response includes an inaccurate commitment, disclosure, approval, or inappropriate language.

 

Investigators should review the assistant’s directive, mailbox permissions, send authority, forwarding rules, delegated access, logs, retrieved message context, outbound messages, attachments, recipients, and calendar actions. Particular attention should be given to external messages, unusual forwarding, sensitive content in replies, and outbound actions caused by retrieved or embedded instructions.

 

Investigative Relevance

Mailbox agents with send authority are relevant because they allow a synthetic subject to act through a trusted communication channel. The assistant may expose information, communicate, approve, schedule, or route activity under the apparent authority of an employee.