Enforce a Data Classification Policy on Retrieval

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.

Enterprise retrieval access is the configuration of corpora, indexes, connectors, and Retrieval-Augmented Generation (RAG) pipelines that a synthetic subject can retrieve from. A corpus is a collection of documents, records, messages, files, or other source material made available for search or retrieval. RAG is a design pattern where relevant source material is retrieved before the synthetic subject generates an answer or takes action.

This configuration creates an elevated exposure condition because retrieval defines what internal information can enter the synthetic subject’s context. If retrieval spans mailboxes, documents, tickets, customer records, wikis, source code, or other enterprise stores, the synthetic subject may combine information across repositories, sensitivity levels, and access boundaries.

The primary risk is retrieval beyond entitlement. A synthetic subject may retrieve, summarize, or expose information that the human requester is not authorized to view. This may occur through shared indexes, broad connectors, cached embeddings, service identities, incomplete query-time access checks, or retrieval pipelines that do not enforce per-user permissions.

A related risk is untrusted content in retrieval context. Externally sourced documents, inbound emails, customer records, support tickets, uploaded files, or partner content may be indexed and later retrieved into the synthetic subject’s context. If that content contains malicious or misleading instructions, it may influence the synthetic subject during an otherwise legitimate request.

Investigators should review retrieval configuration, connected corpora, index membership, connector permissions, query logs, documents returned, requester identity, access-control decisions, prompt and response records, and output destinations. Particular attention should be given to cross-boundary retrieval, sensitive content in outputs, externally sourced documents, and cases where retrieved material exceeded the requester’s entitlement.

Investigative Relevance

Enterprise retrieval access is relevant because retrieval configuration determines what information a synthetic subject can see and use. Weak retrieval boundaries may turn an assistant or agent into a bridge between restricted information and an unauthorized requester.

This section is especially relevant where synthetic subjects retrieve from enterprise search indexes, RAG pipelines, mailboxes, file stores, collaboration platforms, ticketing systems, customer relationship management platforms, source repositories, or shared document corpora.

Data exfiltration occurs when a synthetic subject causes confidential, sensitive, regulated, proprietary, or otherwise protected information to leave its authorized boundary. The transfer may be direct or indirect, intentional or unintended, visible or hidden inside another output channel.

This adverse outcome creates organizational harm because the synthetic subject may expose data it was permitted to access but not permitted to disclose. The disclosure may involve customer records, employee data, source code, credentials, financial information, legal material, internal communications, business strategy, regulated records, or other protected information.

The primary harm is loss of control over protected data. The synthetic subject may disclose information through rendered content, connected tools, outbound communications, generated files, memory, retrieved context, cross-tenant workflows, or external services. The path may not resemble a conventional file export or human-initiated transfer.

A related harm is attribution and scoping difficulty. Data exfiltration by a synthetic subject may be distributed across prompts, retrieval events, tool calls, rendered output, browser fetches, application logs, and downstream systems. Investigators may need to reconstruct both what data was exposed and which synthetic subject action caused it to leave the authorized boundary.

Investigators should review prompt and response logs, retrieval records, tool-call logs, generated artifacts, outbound communications, web proxy records, Data Loss Prevention (DLP) events, browser or application rendering logs, memory reads, connector logs, and destination records. Particular attention should be given to sensitive data appearing in external requests, messages, files, tool arguments, generated output, memory disclosures, or cross-boundary records.

Investigative Relevance

Data exfiltration is relevant because it is one of the most direct adverse outcomes a synthetic subject can produce. The same synthetic subject may have legitimate access to protected information for one purpose while causing unauthorized disclosure through another channel.

This section is especially relevant where synthetic subjects can retrieve enterprise data, summarize documents, access mailboxes, call tools, send communications, generate files, render links or images, interact with external services, or operate across users, tenants, vendors, or organizations.

A public Q&A knowledge bot is a synthetic subject directed to answer open questions from a defined document set, knowledge base, website corpus, policy library, or other indexed source material. This may include public-sector guidance bots, legal information assistants, regulatory tools, policy question-and-answer services, and product documentation assistants.

This directive creates an elevated exposure condition because the synthetic subject may convert source material into authoritative-sounding guidance, even when the answer is incomplete, outdated, overgeneralized, or wrong. Retrieval-Augmented Generation (RAG) can improve grounding by retrieving source passages before generation, but it does not prevent unsupported conclusions, missed exceptions, or excessive certainty.

The primary adverse outcome is user reliance on incorrect or unlawful guidance. A public Q&A knowledge bot may state that a prohibited action is allowed, that an obligation does not apply, or that a policy permits conduct it does not. This is especially significant where the operator is a government body, regulated entity, legal service, healthcare provider, employer, or other trusted institution.

A secondary risk is exposure or manipulation of the document set. If the synthetic subject retrieves from internal documents, draft policy, sensitive records, or unapproved repositories, it may disclose material not intended for public release. If the indexed corpus can be influenced by external content, user submissions, or weak document governance, the retrieval channel may also become a poisoning path.

Investigators should review the synthetic subject’s directive, retrieval configuration, source corpus, grounding behavior, citation handling, ingestion process, access boundaries, transcript logs, and retrieval controls. Particular attention should be given to unsupported answers, contradictions with authoritative policy, exposure of out-of-scope material, and whether indexed content was current, authorized, and resistant to manipulation.

Investigative Relevance

Public Q&A knowledge bots are relevant because they can transform source documents into operational guidance at scale. The synthetic subject may not be authorized to create policy, interpret law, approve business conduct, or provide regulated advice, but users may treat its output as if it does.

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.

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.

Over-scoped agent access occurs when a synthetic subject is granted permissions beyond what is required for its approved function. This may include broad read access, write permissions, administrative scopes, cross-repository access, tenant-wide connectors, or access to data classes unrelated to the task.

This configuration creates an elevated exposure condition because any defective directive, manipulated invocation, compromised connector, or unsafe tool call may operate across a larger scope than necessary. The synthetic subject’s practical capability is defined by what its credentials allow, not by what its prompt says it should do.

The primary risk is excessive blast radius. A synthetic subject intended to summarize tickets, answer questions, or process records may be able to retrieve confidential documents, access customer data, modify systems, or transmit information outside its intended boundary.

Investigators should review assigned scopes, role grants, connector permissions, cloud roles, data access policies, tool permissions, and actual access patterns. Particular attention should be given to tenant-wide access, broad wildcard permissions, production write access, and access to sensitive repositories that are not required for the synthetic subject’s function.

Investigative Relevance

Over-scoped agent access is relevant because excessive permission turns routine AI behavior into high-impact operational risk. It is especially relevant where a low-risk assistant, embedded feature, or workflow agent has access normally reserved for privileged users or production services.

Cross-tenant content injection occurs when content authored in one tenant, organization, or external customer environment is processed by an embedded artificial intelligence feature in another. This may occur through shared Software as a Service (SaaS) platforms, customer relationship management records, support tickets, shared documents, partner portals, email threads, comments, or other collaborative surfaces.

This deployment pattern creates an elevated exposure condition because a malicious actor does not need direct access to the victim’s tenant or agent. They only need to place content into a shared surface that the embedded synthetic subject later reads, summarizes, classifies, routes, or acts upon.

The primary risk is cross-boundary instruction execution. A malicious instruction may travel as ordinary business content from one party to another, then execute when the receiving party’s embedded agent processes it. The resulting action may occur under the victim organization’s SaaS tenant, service identity, or employee workflow, even though the effective instruction originated externally.

A related risk is attribution failure. The malicious payload and the executing agent belong to different parties, while the shared SaaS provider may only see normal platform activity. Victim logs may show the agent processing a legitimate record, and vendor logs may show permitted tenant behavior, making origin, authorization, and responsibility difficult to establish.

A further risk is shared-service data exposure. Where the vendor uses a shared artificial intelligence service across multiple customers, confidential data submitted by one customer may be processed, indexed, retained, or reused in a way that affects another customer’s environment. This can expose proprietary information, customer data, regulated records, or privileged material through generated answers, shared context, model memory, retrieval results, telemetry, or vendor-managed integrations.

Investigators should review the shared SaaS surface, source tenant or external origin, record history, embedded content, agent processing logs, tenant audit records, vendor logs, downstream actions, and shared-service data handling. Particular attention should be given to externally authored fields, cross-tenant records, shared documents, support tickets, partner inputs, unexpected tenant-to-tenant data exposure, and actions triggered without direct authentication by the external originator.

Investigative Relevance

Cross-tenant content injection is relevant because it allows an external party to influence a synthetic subject through ordinary shared business content. Standard authentication may not prevent the attack because the injected instruction enters through a legitimate collaboration or customer channel.

This sub-section is especially relevant where embedded artificial intelligence features process records, tickets, documents, forms, comments, emails, or other content that crosses tenant, vendor, customer, partner, or organizational boundaries. It is also relevant where vendor-hosted artificial intelligence services process confidential data from multiple customers through shared infrastructure, shared retrieval systems, shared model services, or vendor-managed integrations.

Cross-boundary data disclosure occurs when a synthetic subject causes protected information to move outside its authorized user, tenant, customer, vendor, organizational, or trust boundary. The data may remain inside a platform or service, but still be exposed to a party, account, agent, tenant, workflow, or organization that is not authorized to receive it.

This adverse outcome creates organizational harm because boundary controls define who may access protected information. A synthetic subject may summarize, retrieve, infer, route, or disclose data across boundaries that would normally be separated by identity, tenant, role, customer, vendor, department, legal entity, or contractual control.

The primary harm is unauthorized cross-boundary exposure. Protected information belonging to one user, customer, tenant, team, or organization may appear in another user’s output, another customer’s record, another tenant’s workflow, a vendor-accessible context, or a shared agent environment.

A related harm is loss of data sovereignty and accountability. The disclosure may occur through shared indexes, cross-tenant SaaS workflows, vendor-hosted AI features, shared memory, collaboration records, support tickets, or agent-to-agent handoffs. Investigators may need to determine which boundary was crossed, what data moved, who received it, and whether the disclosure violated access policy, contractual terms, privacy obligations, or regulatory requirements.

Investigators should review tenant logs, user entitlements, retrieval records, shared indexes, connector access, vendor audit logs, support records, memory stores, agent handoff records, prompt and response logs, and downstream recipients. Particular attention should be given to data from one customer, tenant, user, or organization appearing in another boundary’s output, record, workflow, or agent context.

Investigative Relevance

Cross-boundary data disclosure is relevant because synthetic subjects may combine data across users, tenants, systems, and organizations in ways traditional access controls were not designed to observe. The harmful outcome is not only that data was disclosed externally, but that it crossed an authorization boundary.

This sub-section is especially relevant where synthetic subjects operate in shared-tenant platforms, vendor-hosted AI services, customer relationship management systems, support tools, shared memory stores, enterprise retrieval indexes, collaboration platforms, or agent-to-agent workflows.