Untrusted Content Quarantine

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.

An embedded AI feature is an artificial intelligence capability built directly into an application workflow rather than presented as a standalone chat interface. It may generate, summarize, classify, recommend, prioritize, extract, or decide inside the host application.

This deployment pattern creates an elevated exposure condition because the synthetic subject may inherit the trust, data scope, identity, and permissions of the surrounding product surface. Its output may be treated as native application behavior rather than the action of a distinct synthetic subject.

The primary risk is low scrutiny. Because the feature appears to be “just part of the app,” its actions may not receive separate review, attribution, or logging. It may process documents, records, messages, form fields, uploaded files, or customer data, then produce outputs that are stored, routed, recommended, or acted upon by the host workflow.

A related risk is indirect manipulation. Any ingested content may carry hidden or adversarial instructions. An external party may never access the application directly, but may still influence the feature through an email, uploaded file, form submission, fetched page, support record, or other data later processed by a trusted employee.

Investigators should review the feature’s directive, host permissions, model identity, input sources, output handling, logs, downstream actions, and provenance records. Particular attention should be given to whether model-generated content is distinguishable from human or application-generated content, and whether harmful output can be traced to the input that caused it.

Investigative Relevance

Embedded AI features are relevant because they operate inside trusted workflows with limited user awareness. Their autonomy may be narrow, but their outputs can propagate through notifications, records, recommendations, approvals, summaries, or automated actions.

An event-triggered AI agent is a synthetic subject whose runs are started by a system event rather than a direct conversational request. This may include a frontend action, webhook, queue item, form submission, file drop, inbound email, application event, or record arriving in a data pipeline.

This deployment pattern creates an elevated exposure condition because the person or system that triggers the run may be different from the person who controls the input. The agent may run with a standing application identity and access to customer records, ticket queues, internal documents, communications, or pipeline data, while the event content may originate from an external or low-trust source.

The primary risk is event-driven indirect prompt injection. Form fields, payloads, queued rows, uploaded files, or inbound messages may contain instructions that the agent treats as task context. A malicious instruction can therefore be planted by a malicious individual and executed later when the workflow processes the item.

A related risk is unattended repetition. Event-triggered agents often process backlogs, queues, or recurring inputs without a human reviewing each run. A poisoned input or flawed directive may produce harmful outputs at machine speed while appearing to be normal workflow throughput.

Investigators should review the agent’s directive, trigger conditions, event payloads, queue records, service identity, workflow permissions, input sources, run history, tool calls, output destinations, and downstream actions. Particular attention should be given to externally controlled fields, repeated adverse outcomes across similar records, and logs that fail to show which input content caused the agent’s action.

Investigative Relevance

Event-triggered AI agents are relevant because they decouple human oversight from agent execution. The run may be authorized by the workflow, while the effective instruction is supplied through data controlled by an external party, customer, vendor, compromised account, or low-trust source.

This section is especially relevant where agents process public forms, inbound webhooks, emails, file uploads, watched folders, customer relationship management records, ticket queues, data pipelines, or application events without human review before action.

Indirect untrusted-content invocation occurs when attacker-controlled or low-trust content causes a synthetic subject to act. The effective instruction is embedded in data the synthetic subject retrieves, ingests, summarizes, renders, or processes, rather than being issued directly by the apparent operator.

This may include instructions hidden in email, webpages, documents, customer relationship management fields, support tickets, pull request comments, uploaded files, calendar invites, chat messages, tool outputs, or other content sources. The synthetic subject may treat the embedded instruction as part of the task context and execute it as if it were a legitimate command.

This invocation creates an elevated exposure condition because the person who triggers the synthetic subject may not be the person who supplied the effective instruction. An employee may ask an assistant to summarize a mailbox, review a document, process a lead, or inspect a pull request, while the actual behavioral instruction comes from external or attacker-controlled content previously placed in that source.

The primary risk is indirect prompt injection. A malicious instruction may cause the synthetic subject to retrieve private data, override constraints, call tools, generate outbound links, render images, transmit information, or combine internal data with an external communication path. This is especially significant where the same context contains private data, untrusted content, and outbound connectivity.

Investigators should review the ingested content, retrieval records, tool outputs, prompt and response logs, rendered links and images, external fetches, web proxy records, Data Loss Prevention (DLP) alerts, requester identity, and downstream tool calls. Particular attention should be given to instruction-like text in retrieved content, invisible or obfuscated payloads, auto-rendered markdown images, new or recently registered domains, character-by-character request patterns, and outputs that combine private data with an outbound channel.

Investigative Relevance

Indirect untrusted-content invocation is relevant because the apparent user request may be benign while the effective command is supplied by another party. The investigation must reconstruct not only who invoked the synthetic subject, but which retrieved or ingested content shaped the action.

Model Context Protocol (MCP) invocation occurs when a synthetic subject is caused to act, change behavior, select tools, or continue a workflow through MCP-supplied content. MCP is an integration pattern that allows a synthetic subject to discover and use external tools, data sources, and actions through a structured interface.

This invocation creates an elevated exposure condition because MCP servers can supply model-visible information before, during, and after tool use. Tool descriptions, server instructions, schemas, tool outputs, resource content, sampling requests, prompts, and connector metadata may all enter the synthetic subject’s context and influence its behavior.

The primary risk is protocol-mediated instruction flow. The synthetic subject may treat MCP-supplied text as trusted operational context even when it originates from a third-party server, compromised connector, unapproved tool, or attacker-influenced resource. This may cause the synthetic subject to call tools, disclose information, change reasoning, prefer malicious servers, or pass sensitive context across boundaries.

Investigators should review MCP server inventory, tool definitions, server instructions, schemas, tool-list responses, resource reads, sampling requests, prompt templates, tool outputs, connection history, version changes, and tool-call logs. Particular attention should be given to instruction-bearing metadata, changed tool descriptions, untrusted server output, cross-server influence, and behavior that begins when an MCP server connects or returns content.

Investigative Relevance

MCP invocation is relevant because MCP can introduce instructions into a synthetic subject through several protocol surfaces, not only through executed tool calls. A synthetic subject may be influenced when a server connects, when tools are listed, when resources are read, when prompts are supplied, or when tool output is returned.

This section is especially relevant where synthetic subjects connect to MCP servers, tool registries, marketplace connectors, local developer tools, SaaS integrations, filesystem tools, browser tools, or third-party agent tool platforms.

Source provenance obfuscation occurs when a synthetic subject’s output hides, omits, or misrepresents the true source of the data, instruction, or context that influenced its behavior. The visible output may cite an innocuous source, trusted record, private channel, or retrieved document while omitting the upstream content that actually caused the response or action.

This opacity condition frustrates investigation because the cited source may not be the causal source. A synthetic subject may produce an answer that appears grounded in approved material, while the operative instruction came from hidden text, an attacker-controlled message, a tool result, a retrieved comment, or another upstream source not shown to the user.

The primary risk is false source confidence. Investigators, users, or reviewers may inspect the visible citation and conclude that the response was properly grounded, while the actual source of influence remains outside the cited evidence chain. This can delay containment, misdirect review, and cause investigators to inspect the wrong document, channel, record, or tool output.

A related risk is missing upstream provenance. Retrieved or summarized content may be copied through multiple layers before reaching the synthetic subject. As content passes through summaries, citations, tool outputs, shared context, or generated records, the original source may become hidden or detached from the final answer.

Investigators should review cited sources, retrieved records, raw source content, upstream messages, hidden comments, tool outputs, prompt and response logs, provenance tags, source ranking, and generated citations. Particular attention should be given to citations that do not contain the asserted content, outputs shaped by uncited material, invisible markdown comments, zero-width Unicode, hidden instructions, and answers whose visible source trail begins after the true originating source.

Investigative Relevance

Source provenance obfuscation is relevant because a synthetic subject’s visible citation or grounding trail may not identify the content that caused its behavior. The investigator must reconstruct the full source chain, including upstream material that was retrieved, summarized, hidden, or omitted from the final output.

This section is distinct from data exfiltration and indirect prompt injection. The data leak belongs to Adverse Outcome, and the injected instruction belongs to Invocation. This Opacity section concerns the concealment or loss of source provenance that frustrates reconstruction.

This section is especially relevant where synthetic subjects generate citations, summarize retrieved content, process hidden comments, use Retrieval-Augmented Generation (RAG), consume tool outputs, or operate in collaboration platforms where content from one channel, record, or document can influence output attributed to another.

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 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.

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.

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.

An in-app text generation feature is an embedded artificial intelligence capability that generates, summarizes, drafts, rewrites, or explains content inside an existing application surface. It may read documents, messages, records, tickets, notes, or other user-accessible content, then render output inline as part of the product workflow.

This deployment pattern creates an elevated exposure condition because the content the feature must ingest to perform its task can also become the manipulation vector. A malicious instruction hidden in a message, uploaded file, record, comment, or document may influence the generated output during an ordinary summarize, draft, or generate action.

The primary risk is that manipulated output appears as trusted application content. If links, images, markdown, or generated text are rendered inline, the feature may mislead the employee, expose sensitive content, or create an outbound path without a distinct synthetic subject identity in the activity trail.

Investigators should review the feature’s directive, input sources, rendering behavior, output logs, external link handling, image loading, markdown support, and provenance records. Particular attention should be given to hidden instructions in ingested content, output that includes external destinations, and whether generated text is distinguishable from user- or application-authored content.

Investigative Relevance

In-app text generation is relevant because it embeds synthetic subject output directly into trusted product workflows. The feature may appear to be a normal application function, while its output is shaped by untrusted content processed during the task.

A customer-facing AI feature is an embedded artificial intelligence capability exposed to external users through a public product surface. It may generate content, answer questions, recommend actions, summarize information, classify inputs, or guide users inside a customer-facing application or service.

This deployment pattern creates an elevated exposure condition because untrusted input arrives directly from outside the organization. Any user of the product may attempt to manipulate the feature into producing harmful, inaccurate, non-compliant, offensive, or unauthorized output.

The primary risk is organizational attribution. Because the feature is embedded in the product, its output may be treated as the company’s own statement, recommendation, or commitment. This can create legal, contractual, regulatory, or reputational exposure where the feature gives prohibited advice, makes offer-like statements, misrepresents policy, or produces content users rely on.

Investigators should review the feature’s directive, public scope, input handling, response controls, output logs, product integration, user-facing disclaimers, and escalation paths. Particular attention should be given to manipulated prompts, unauthorized commitments, regulated-topic responses, and outputs that contradict approved product, policy, or compliance material.

Investigative Relevance

Customer-facing AI features are relevant because they combine public reach, product authority, and untrusted input. The synthetic subject may have limited access, but its output appears inside the organization’s product and may be relied upon by customers.

An unattended workflow agent is an autonomous AI agent wired into a workflow, connector, queue, or scheduled process that runs without a human reviewing each execution. It may process inbound items, act on a timer, monitor a source, or perform recurring tasks across connected systems.

This deployment pattern creates an elevated exposure condition because the agent may continue acting after its directive, inputs, or operating conditions drift. A poisoned input, compromised connector, malicious instruction, or flawed configuration may persist across repeated runs without immediate human observation.

The primary risk is continuous unattended harm. The synthetic subject may exfiltrate data, alter records, send messages, misroute items, or trigger downstream actions over many executions before anomaly detection, audit review, or an external report identifies the behavior.

Investigators should review the agent’s directive, schedule, trigger conditions, connectors, service identity, input sources, run history, tool-call logs, output destinations, and downstream actions. Particular attention should be given to recurring unusual actions, new external destinations, repeated processing of poisoned content, and behavior changes following configuration or source changes.

Investigative Relevance

Unattended workflow agents are relevant because they can operate repeatedly without direct human supervision. Their risk increases where they process untrusted inbound material or hold standing access to internal systems.

A browser or desktop agent is an autonomous AI agent that operates through a real browser, desktop environment, or graphical user interface. It may read rendered pages, screenshots, documents, forms, or application windows, then click, type, navigate, copy, paste, upload, download, or submit information on behalf of a user.

This deployment pattern creates an elevated exposure condition because the agent acts inside the user’s authenticated session. It may interact with applications using the user’s existing cookies, tokens, permissions, and access rights, making its actions appear as ordinary user activity.

The primary risk is untrusted interface content. Any page, URL fragment, screenshot, document, form field, or rendered message the agent reads may become an instruction surface. A malicious page or document may redirect the synthetic subject into disclosing session data, submitting sensitive information, copying internal content, or revealing one-time codes while operating under the user’s authority.

Investigators should review the agent’s directive, browser session context, visited URLs, rendered content, screenshots, clipboard activity, form submissions, downloads, uploads, and application audit logs. Particular attention should be given to external pages processed before sensitive actions, unusual navigation paths, one-time code exposure, and actions taken inside authenticated sessions.

Investigative Relevance

Browser and desktop agents are relevant because they allow a synthetic subject to operate through the same interface and session as a human user. This can bypass traditional separation between advice and action, since the agent can directly interact with applications rather than only recommend steps.

A user action trigger occurs when an action in an application interface starts an agent run. This may include submitting a form, clicking a button, saving a record, uploading a file, updating a field, or completing another workflow step.

This deployment pattern creates an elevated exposure condition because the action that starts the run may not be the same as the content that shapes it. The agent may process free-text fields, attachments, comments, descriptions, or uploaded records as task context, even where that content was supplied by an external or low-trust submitter.

The primary risk is delayed execution of injected content. A malicious instruction may be planted in a frontend field or submitted record, then executed later when an internal employee opens, reviews, routes, or processes the item. The run may execute under the application, workflow, or employee identity, while the effective instruction came from the external submitter.

Investigators should review the trigger action, submitted fields, attachments, record history, user identity, workflow permissions, agent run logs, tool calls, and downstream actions. Particular attention should be given to free-text fields, externally supplied content, and cases where an internal user triggered processing of a record created or modified by someone else.

Investigative Relevance

User action triggers are relevant because they allow external or low-trust content to influence an agent run through normal application behavior. The employee may appear to have initiated the run, but the instruction path may originate in submitted data.

This sub-section is especially relevant where agents process web forms, customer relationship management records, support tickets, uploaded files, comments, case notes, lead forms, application records, or other frontend-supplied content.

A webhook event trigger occurs when an inbound event from another system automatically starts an agent run. This may include a new ticket, inbound email, status callback, chat application event, customer relationship management update, or other webhook-driven workflow.

This deployment pattern creates an elevated exposure condition because the agent may run without a human reviewing the event first. The event payload may contain free text, metadata, links, attachments, or structured fields that the synthetic subject treats as task context.

The primary risk is attacker-shaped event input. Public or weakly authenticated endpoints may allow an external actor to forge, replay, or manipulate event payloads. A single malicious event may then trigger downstream actions, such as ticket routing, message generation, record updates, external calls, or tool execution, before anyone notices.

Investigators should review the event source, webhook authentication, payload content, replay protections, trigger rules, agent run logs, tool calls, downstream actions, and output destinations. Particular attention should be given to forged or repeated events, unusual payload fields, newly observed sources, and actions that exceed the normal event workflow.

Investigative Relevance

Webhook event triggers are relevant because they allow external or third-party system events to initiate agent behavior without direct human oversight. The workflow may appear routine, while the effective instruction is carried in the event payload.

This sub-section is especially relevant where agents process inbound webhooks, status callbacks, chat events, ticket events, email events, customer updates, integration messages, or other automated triggers from public, partner, or weakly trusted systems.

A batch processing trigger occurs when an agent or model processes queued rows, files, records, or items in a scheduled data pipeline. This may include Extract, Transform, Load (ETL) jobs, bulk classification runs, document processing queues, ticket enrichment, record summarization, or scheduled workflow automation.

This deployment pattern creates an elevated exposure condition because each item is processed without per-item human review. A single poisoned row, file, record, or queued item may enter the model’s context and influence the run while appearing to be ordinary batch input.

The primary risk is hidden manipulation inside routine throughput. Because the run is bulk and scheduled, a tampered item may be difficult to distinguish from normal processing. If the agent has broad pipeline permissions, one poisoned record may trigger outputs, updates, classifications, external calls, or downstream actions across the job’s full data scope.

Investigators should review the pipeline directive, schedule, input queue, source records, transformation logs, model outputs, tool calls, downstream writes, error handling, and affected data scope. Particular attention should be given to anomalous individual records, repeated harmful outputs across a backlog, externally sourced rows or files, and changes that occurred without per-item approval.

Investigative Relevance

Batch processing triggers are relevant because they allow a synthetic subject to act across many records at machine speed with limited human visibility. A harmful instruction or manipulated input may be hidden inside otherwise normal pipeline activity.

Poisoned tool description occurs when a connected tool’s description, metadata, schema, or usage instructions contain hidden or adversarial instructions that influence the synthetic subject. These instructions may be visible to the model during tool selection but hidden, truncated, or unclear to the human reviewer.

This configuration creates an elevated exposure condition because tool descriptions are not passive documentation. They may enter the model’s context and affect which tool is selected, what data is passed to it, and how the synthetic subject behaves before or after the call.

The primary risk is metadata-driven manipulation. A synthetic subject may disclose secrets, call unsafe tools, pass sensitive data, or perform unauthorized actions because the tool description instructs it to do so.

Investigators should review tool descriptions, metadata, schemas, client display behavior, hidden text, encoded content, prompt-like language, and tool-call logs. Particular attention should be given to descriptions containing instructions to ignore rules, access sensitive files, forward data, or prefer one tool over another.

Investigative Relevance

Poisoned tool descriptions are relevant because the attack surface may sit in tool metadata rather than user prompts or tool code. This sub-section is especially relevant where tools are installed from marketplaces, open registries, third-party repositories, or MCP servers managed outside the organization.

Inter-agent context propagation occurs when an orchestrated AI system is configured to pass one synthetic subject’s output into another synthetic subject’s context. This may occur through inter-agent messages, delegated task records, summaries, shared memory, generated work products, workflow state, tool outputs, or orchestration-layer handoffs.

This configuration creates an elevated exposure condition because model-visible context can move across agents, roles, tools, and trust boundaries. A receiving synthetic subject may rely on inherited context without knowing its original source, trust level, or integrity.

The primary risk is unvalidated context transfer. Content first processed by a low-trust or attacker-influenced synthetic subject may be reformatted, summarized, copied, or embedded into another agent’s task context. As the context moves through the system, its original provenance may become less visible while its ability to influence downstream behavior increases.

A related risk is capability amplification through delegation. A synthetic subject with limited access may pass inherited context to a tool-equipped worker, privileged agent, or downstream workflow with greater operational reach. The downstream synthetic subject may then act on that context as if it came from the orchestrator, an approved task record, or another trusted system component.

Investigators should review the agent graph, context-sharing configuration, delegation paths, inter-agent message formats, shared memory stores, task handoff records, summarization steps, tool-output routing, provenance tags, and trust-boundary controls. Particular attention should be given to context copied between agents, missing source attribution, inherited instructions, repeated unusual text appearing across agents, and downstream actions that trace back to propagated context rather than an approved operator objective.

Investigative Relevance

Inter-agent context propagation is relevant because context-sharing is a design decision that defines how synthetic subjects influence each other. In an orchestrated system, the risk is not only what an individual agent can access, but what context it can pass to other agents with different permissions, tools, or responsibilities.

This sub-section is especially relevant where agents summarize each other’s work, pass task instructions, share memory, consume generated records, exchange tool outputs, or delegate actions to tool-equipped workers without enforcing provenance, trust-level separation, and integrity checks.

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.

MCP tool-output invocation occurs when output returned by a Model Context Protocol (MCP) tool causes a synthetic subject to act. MCP is an integration pattern that allows a synthetic subject to discover and use external tools, data sources, and actions through a structured interface.

This invocation occurs after a tool call, when the tool result is returned to the synthetic subject’s context. The output may contain ordinary data, but it may also contain instruction-bearing content that causes the synthetic subject to call another tool, disclose information, alter its plan, or continue a workflow in an unsafe direction.

The primary risk is tool-returned instruction execution. A compromised, malicious, or attacker-influenced MCP tool may return content that the synthetic subject treats as a command rather than as data. This is especially significant where the tool processes web pages, files, tickets, customer records, repository content, database results, or other low-trust sources.

Investigators should review raw tool outputs, tool-call logs, returned content, subsequent tool calls, prompt and response records, and downstream actions. Particular attention should be given to instructions embedded in tool results, external content returned by tools, repeated tool-call chains, and actions that began only after a specific tool output entered context.

Investigative Relevance

MCP tool-output invocation is relevant because tool results can become an instruction source after the operator has already approved or initiated a tool call. The investigation must determine whether the synthetic subject acted on the requested tool result or on instructions embedded inside that result.

This sub-section is especially relevant where MCP tools retrieve webpages, read files, query databases, summarize tickets, inspect repositories, fetch external resources, or return model-visible text from untrusted or mixed-trust sources.

MCP resource content invocation occurs when content exposed through an MCP resource causes a synthetic subject to act. MCP resources allow servers to expose contextual data, such as files, documents, records, repository content, logs, or other readable material, to the client and model context.

This invocation creates an elevated exposure condition because resource content may be treated as task-relevant context while also carrying embedded instructions. A resource may appear to be a document, file, record, or data object, but contain prompt-like text that directs the synthetic subject to ignore rules, call tools, disclose information, or change behavior.

The primary risk is resource-borne instruction execution. A malicious or low-trust resource may be read as data, but used by the synthetic subject as an instruction source. This is especially significant where MCP resources expose external files, shared folders, repository content, user-submitted records, logs, or other material that may be modified by untrusted parties.

Investigators should review MCP resource reads, raw resource content, source provenance, access permissions, retrieved records, prompt and response logs, and actions following resource access. Particular attention should be given to instruction-like text in resources, hidden or obfuscated content, externally writable resources, and actions that follow resource reads rather than operator prompts.

Investigative Relevance

MCP resource content invocation is relevant because resources can introduce instructions through a data channel rather than a tool description or direct prompt. The synthetic subject may appear to be reading context, while the effective instruction is embedded inside that context.

This sub-section is especially relevant where MCP servers expose filesystems, repositories, documentation stores, ticket systems, customer records, logs, emails, or other resources that may include untrusted or externally influenced content.

MCP sampling invocation occurs when a Model Context Protocol (MCP) server requests that the client or host perform a model completion on the server’s behalf. 

A model completion is the process where a model generates a response from supplied messages, instructions, or context. In this pattern, the MCP server can ask the host model to generate text, reason over supplied content, summarize information, or produce an answer that is then returned to the server or used in the workflow.

This invocation creates an elevated exposure condition because the server is no longer only returning data or exposing tools. It may initiate a model-facing request that causes reasoning, summarization, generation, or tool-adjacent behavior through the client’s model environment.

The primary risk is server-originated model steering. A malicious or compromised MCP server may use sampling requests to introduce instructions, request sensitive context, summarize information it should not receive, or cause the host model to generate content that supports later misuse.

Investigators should review MCP sampling requests, server identity, request payloads, messages supplied by the server, model responses, user consent records, returned outputs, and subsequent server or tool activity. Particular attention should be given to sampling requests from low-trust servers, requests involving sensitive context, unexpected model completions, and server-originated prompts that resemble operator instructions.

Investigative Relevance

MCP sampling invocation is relevant because it allows an MCP server to initiate model activity rather than merely respond to a user-initiated tool call. The invocation source is the server request, and the resulting model output may influence later actions.

This sub-section is especially relevant where MCP clients permit server-requested sampling, agentic workflows, model-in-the-loop tools, server-side planning, or integrations that allow external servers to request completions through the host model.