Agent Egress Destination Monitoring

Connected tools and functions are the plugins, connectors, functions, application programming interfaces, and Model Context Protocol (MCP) servers made available to a synthetic subject. 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 configuration creates an elevated exposure condition because connected tools define what the synthetic subject can do beyond text generation. A tool may allow it to read records, send messages, update systems, retrieve files, call APIs, execute commands, or transmit data outside the immediate application.

The primary risk is unsafe tool trust. Tool names, descriptions, schemas, parameters, outputs, and server definitions may influence how the synthetic subject chooses and uses tools. If these definitions are changed, poisoned, impersonated, or poorly governed, the synthetic subject may call the wrong tool, pass sensitive data to an unsafe tool, or perform an action outside its approved purpose.

Investigators should review connected tool inventories, MCP server records, tool definitions, schemas, descriptions, permissions, version history, provenance, tool-call logs, runtime egress, and change approvals. Particular attention should be given to newly added tools, changed descriptions or schemas, shadowed tool names, unexpected destinations, and tool calls that cannot be attributed to an approved configuration.

Investigative Relevance

Connected tools and functions are relevant because they convert a synthetic subject from an advisory system into an actor with operational capability. The configuration of tools determines whether the synthetic subject can only answer, or whether it can retrieve, modify, send, execute, or integrate across systems.

This section is especially relevant where synthetic subjects use marketplace tools, plugins, MCP servers, internal functions, SaaS connectors, email tools, database tools, cloud APIs, command execution tools, or externally supplied tool runtimes.

External communication access is the configuration that allows a synthetic subject to communicate beyond the organization’s controlled environment. This may include Hypertext Transfer Protocol (HTTP) requests, webhooks, email, external Application Programming Interface (API) calls, auto-rendered links, auto-rendered images, file uploads, browser navigation, or allow-listed domains.

This configuration creates an elevated exposure condition because outbound communication can complete the path from internal data access to external disclosure. A synthetic subject that can access private data, process untrusted content, and communicate externally may be exposed to what Simon Willison describes as the “lethal trifecta” for AI agents.

The primary risk is synthetic subject egress. A manipulated prompt, retrieved document, tool response, or generated output may cause the synthetic subject to transmit sensitive data outward through a permitted channel. This may occur through obvious actions such as email or API calls, or through less visible channels such as rendered image requests, link beacons, proxy requests, markdown output, or repeated small outbound requests.

A related risk is unsafe allow-listing. Domains, Content Security Policy (CSP) rules, proxy services, or trusted destinations may become exfiltration paths if they are too broad, stale, expired, re-registered, or not tied to a specific business purpose. A destination may appear trusted to the platform while still being controllable by an attacker.

Investigators should review outbound tool calls, HTTP requests, email activity, web proxy logs, Data Loss Prevention (DLP) events, rendered links and images, destination allow-lists, CSP entries, payload sizes, request frequency, and the retrieval or prompt events preceding egress. Particular attention should be given to newly observed domains, recently expired or re-registered domains, auto-rendered resources, repeated small requests, and outbound activity following access to sensitive data.

Investigative Relevance

External communication access is relevant because outbound connectivity determines whether a synthetic subject can move information outside the environment. Even a read-only assistant may become high-risk if its output can trigger external requests or transmit sensitive content.

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.

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.

Trusted channel camouflage occurs when synthetic subject activity, data movement, or external observation is hidden inside a channel that appears trusted, routine, or first-party. This may include image proxies, content delivery networks, citation rendering, preview systems, markdown images, link unfurling, browser fetches, or platform-controlled proxy services.

This opacity condition frustrates investigation because the channel may look normal to users and monitoring systems. A request to a trusted image proxy, collaboration platform, or first-party content delivery network may appear to be ordinary rendering behavior while carrying encoded data, beaconing to an attacker-controlled endpoint, or concealing the true destination path.

The primary risk is transport-path concealment. Sensitive data or behavioral signals may move through a permitted rendering or proxy channel rather than through an obvious export, email, file transfer, or external tool call. This can make the activity difficult to distinguish from legitimate image loading, citation previewing, or user-interface rendering.

A related risk is allowlist overtrust. First-party domains, stale Content Security Policy entries, image proxies, preview services, and trusted platform infrastructure may be treated as safe destinations. If those channels can carry attacker-controlled paths, query strings, or encoded identifiers, they can hide outbound movement inside approved traffic.

Investigators should review rendered output, raw markdown, image and link fetches, web proxy logs, first-party proxy requests, content delivery network activity, Content Security Policy allowlists, Data Loss Prevention events, payload patterns, request timing, and destination resolution. Particular attention should be given to high-entropy URLs, character-paced request sequences, newly seen paths on trusted domains, image-proxy traffic following sensitive retrieval, and rendering activity outside normal agent patterns.

Investigative Relevance

Trusted channel camouflage is relevant because the investigator may see traffic to an approved or first-party domain without recognizing that the channel carried unauthorized data or signals. The investigation must examine how data was encoded, routed, rendered, and proxied, not only whether the destination domain was allowlisted.

This section is distinct from data exfiltration and indirect prompt injection. The data leak belongs to Adverse Outcome, and the instruction that caused the rendering belongs to Invocation. This Opacity section concerns the channel camouflage that makes the movement difficult to observe and interpret.

This section is especially relevant where synthetic subjects render markdown, load images, generate links, produce citations, operate in browsers, use first-party proxies, or run inside platforms that automatically fetch external resources on behalf of generated output.

Sandbox escape and out-of-boundary system access occurs when a synthetic subject operating inside an intended test, evaluation, development, or constrained execution environment reaches systems outside the boundary it was authorized to access. The affected systems may be external internet hosts, production infrastructure, package registries, third-party services, internal systems outside the evaluation range, or unrelated organizations.

This adverse outcome creates organizational harm because the synthetic subject’s actions are no longer confined to the environment assumed by the operator, evaluator, or control owner. The subject may scan, authenticate, exploit, publish code, retrieve data, modify systems, or interact with real services while believing, or claiming to believe, that those targets are part of the exercise.

The primary harm is unauthorized system access outside the declared operating boundary. Even where the root cause is weak sandbox configuration, the adverse outcome is the synthetic subject’s real interaction with systems it was not meant to reach. The investigation should distinguish the enabling condition from the outcome: poor sandbox configuration belongs under Configuration, while the access, exploitation, publication, or downstream impact belongs here.

A related harm is boundary uncertainty. If the synthetic subject is given an open-ended objective and the environment does not enforce hard limits, it may discover reachable targets that were never intended to be in scope. Investigators should not assume malicious intent merely because the subject crossed the boundary. They should test whether the subject exploited a discovered weak boundary deliberately, followed a task objective under a false belief, or continued after evidence showed the target was real.

Investigators should review sandbox configuration, network egress controls, Domain Name System (DNS) resolution, route tables, proxy logs, package registry activity, tool-call logs, shell commands, authentication attempts, evaluation prompts, system prompts, execution traces, external destination logs, and any reasoning or self-report produced during the run. Particular attention should be given to the first out-of-boundary connection, whether the subject recognized the target as real, whether it stopped or continued, and whether external activity can be tied to a declared task objective.

Investigative Relevance

Sandbox escape and out-of-boundary system access is relevant because synthetic subjects may operate under assumptions created by humans, prompts, vendors, or evaluation harnesses. A subject may be told that it has no internet access while the environment is actually misconfigured to permit it. In that case, the configuration failure enables the incident, but the adverse outcome remains the unauthorized external or production interaction.

This section is especially relevant where synthetic subjects run cyber evaluations, coding tasks, browser or desktop automation, package publishing workflows, development agents, tool-using agents, or autonomous test harnesses with network, filesystem, credential, or package-registry access.

This section should be cross-referenced with Configuration objects covering sandbox egress, tool permissions, non-human identity access, runtime controls, and connected tools. It may also relate to Opacity where logs do not clearly show how the boundary was crossed, and to Directive where the subject continues after recognizing that the environment may be real.

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.

Unapproved connected tool occurs when a synthetic subject is configured to use a plugin, connector, function, application programming interface, or Model Context Protocol (MCP) server that has not been reviewed, approved, or inventoried.

This configuration creates an elevated exposure condition because an unapproved tool may introduce unknown permissions, data access, runtime behavior, supplier dependencies, or outbound destinations. The synthetic subject may treat the tool as trusted even though the organization has not assessed its provenance or purpose.

The primary risk is uncontrolled extension of capability. A single unapproved tool may allow the synthetic subject to retrieve data, send messages, call external services, or perform actions outside the intended design.

Investigators should review connected tool inventories, MCP server lists, configuration files, package manifests, marketplace installs, connector approvals, and tool-call logs. Particular attention should be given to tools installed outside approved channels or tools that do not appear in asset or vendor inventories.

Investigative Relevance

Unapproved connected tools are relevant because they expand what a synthetic subject can do without governance visibility. This sub-section is especially relevant where teams can install marketplace tools, local MCP servers, plugins, or connectors without central approval.

Impersonating tool package occurs when a connected tool, plugin, package, or Model Context Protocol (MCP) server presents itself as a trusted integration while being operated, published, or modified by an unauthorized or malicious supplier.

This configuration creates an elevated exposure condition because the synthetic subject and the deploying team may trust the tool based on its name, description, repository appearance, or apparent relationship to a legitimate service.

The primary risk is supplier impersonation. An impersonating package may receive sensitive inputs, send messages, call APIs, or exfiltrate data while appearing to be an approved or official tool.

Investigators should review package names, publishers, repository ownership, signatures, download sources, version history, dependency changes, marketplace records, and tool-call logs. Particular attention should be given to lookalike names, recently transferred ownership, sudden behavior changes, and tools that mimic official vendor integrations.

Investigative Relevance

Impersonating tool packages are relevant because synthetic subjects may use third-party tools with high trust and high permissions. This sub-section is especially relevant where agents rely on public package registries, marketplace listings, MCP servers, or community-maintained connectors.

Over-permissive tool runtime occurs when a connected tool runs with broader file, network, credential, system, or environment access than required for its approved function.

This configuration creates an elevated exposure condition because a tool called by the synthetic subject may access resources beyond the data explicitly passed to it. It may read local files, environment variables, credentials, network services, logs, or system resources available to the runtime.

The primary risk is hidden tool-side access. Even if the synthetic subject appears narrowly scoped, the tool it calls may have broader runtime permissions and can retrieve, modify, or transmit data outside the intended tool function.

Investigators should review runtime permissions, container settings, environment variables, mounted files, network access, local secrets, execution logs, and tool behavior. Particular attention should be given to tools with access to home directories, secret stores, internal networks, unrestricted outbound connectivity, or shared execution environments.

Investigative Relevance

Over-permissive tool runtimes are relevant because tool execution environments can expand synthetic subject capability beyond visible tool descriptions. This sub-section is especially relevant where tools run on developer workstations, shared servers, CI/CD workers, agent runtimes, or cloud functions with broad local or network access.

Unrestricted tool egress occurs when a connected tool or tool runtime can send data to external destinations without destination allowlisting, network control, or policy enforcement.

This configuration creates an elevated exposure condition because a tool may transmit data outside the organization through email, web requests, file uploads, webhooks, application programming interface calls, or hidden copy mechanisms such as blind carbon copy.

The primary risk is tool-mediated exfiltration. A synthetic subject may call an apparently legitimate tool, while the tool or its runtime sends data to an unauthorized destination. This may occur through malicious tool logic, compromised packages, unsafe configuration, or hidden forwarding behavior.

Investigators should review web proxy logs, egress records, email headers, tool runtime network activity, webhook destinations, API endpoints, and tool-call outputs. Particular attention should be given to newly observed domains, non-allowlisted destinations, blind-copy behavior, unexpected external calls, and data transfers following tool invocation.

Investigative Relevance

Unrestricted tool egress is relevant because connected tools can create outbound paths that are not visible in the synthetic subject’s own prompt or response logs. This sub-section is especially relevant where tools send email, call external APIs, upload files, retrieve URLs, or operate from runtimes with broad internet access.

A third-party tool agent platform is a standalone artificial intelligence agent platform connected to external tools through marketplaces, plugins, connectors, or Model Context Protocol (MCP) servers. MCP servers provide a standardized way for agents to access external tools, data sources, and actions. Each connected tool may allow the agent to read data or perform actions such as sending email, calling application programming interfaces (APIs), updating records, or retrieving files.

This deployment pattern creates an elevated exposure condition because every added tool becomes another supplier in the trust chain. The organization may approve the agent platform, but each marketplace tool, connector, or MCP server introduces its own permissions, update path, dependencies, and operator.

The primary risk is tool-mediated compromise. A connected tool may become malicious through a silent update, impersonating package, compromised dependency, weak marketplace review, or supplier compromise. Once connected, the tool may act through the agent’s authority and access organizational data or systems on the agent’s behalf.

A related risk is attribution failure. Harmful activity may appear to originate from the agent platform, while the actual cause sits inside a specific tool, connector, package, or MCP server. If logs do not preserve tool-level provenance, investigators may be unable to determine which supplier component read the data, sent the message, called the API, or caused the adverse outcome.

Investigators should review the agent platform’s directive, installed tools, marketplace sources, MCP servers, connector permissions, package provenance, update history, tool-call logs, outbound destinations, and vendor audit records. Particular attention should be given to newly added tools, recently updated packages, impersonating names, unexpected email or API actions, and cases where activity cannot be attributed to a specific connected tool.

Investigative Relevance

Third-party tool agent platforms are relevant because they extend organizational trust beyond the agent vendor to every connected tool in the platform ecosystem. A tool added for convenience may become a separate operational actor with access to sensitive data and action capability.

This sub-section is especially relevant where a standalone agent platform can install marketplace tools, connect to MCP servers, send mail, call APIs, read documents, access customer data, update SaaS records, or execute workflow actions through third-party integrations.

Rendered-channel data exfiltration occurs when confidential or sensitive data leaves the organization through an output channel that a synthetic subject is permitted to render.

This adverse outcome creates organizational harm because data transfer may occur without a human intentionally sending a file, email, message, or export. The synthetic subject may generate or render content that causes a browser, collaboration platform, or application surface to make an outbound request containing sensitive data in the path, query string, encoded resource reference, or other request component.

The primary harm is unauthorized disclosure through a permitted display pathway. Data that the synthetic subject can access may be embedded into a rendered link, image, citation, or beacon and transmitted to an external destination or proxy-controlled endpoint. The transfer may appear as ordinary rendering behavior rather than a deliberate data export.

A related harm is reduced visibility. Rendered-channel exfiltration may not appear as a conventional file transfer or user-initiated outbound message. Investigators may need to correlate prompt history, retrieval events, generated output, browser rendering, proxy requests, Data Loss Prevention (DLP) alerts, and web proxy logs to reconstruct the disclosure path.

Investigators should review agent session output, rendered markdown, image and link fetches, citation behavior, browser or application rendering logs, web proxy records, DLP events, Content Security Policy (CSP) allowlists, destination domains, payload size, request timing, and source-content provenance. Particular attention should be given to high-entropy URLs, character-paced request sequences, newly seen or recently registered domains, image-proxy traffic, and outbound requests immediately following retrieval of sensitive data.

Investigative Relevance

Rendered-channel data exfiltration is relevant because the harmful outcome is the movement of protected information outside the organization through a channel that appears to be part of normal synthetic subject output rendering.

This sub-section is especially relevant where synthetic subjects can access internal data and produce rendered markdown, citations, preview links, images, browser output, collaboration messages, or application content that may trigger automatic external requests.

Tool-mediated data exfiltration occurs when a synthetic subject causes protected information to leave the organization through a connected tool, connector, plugin, Application Programming Interface (API), webhook, Model Context Protocol (MCP) server, or external service.

This adverse outcome creates organizational harm because the data leaves through an action path the synthetic subject was permitted to use. The transfer may appear as an ordinary tool call, integration event, workflow update, or API request rather than a direct data export.

The primary harm is unauthorized disclosure through tool authority. A synthetic subject may pass sensitive data as a tool argument, include it in an API payload, send it to a webhook, write it into a third-party system, or route it through a connector that transmits data outside the approved boundary.

A related harm is attribution difficulty. Logs may show that a tool or service account performed the transfer, while the underlying cause was a synthetic subject decision, prompt, retrieved content, or tool-output chain. Investigators may need to reconstruct the sequence from prompt to tool call to external destination.

Investigators should review tool-call logs, connector records, API payloads, webhook destinations, MCP server activity, non-human identity records, outbound network logs, Data Loss Prevention (DLP) events, source-content provenance, and destination ownership. Particular attention should be given to sensitive data in tool arguments, unexpected external destinations, newly added tools, unusual webhook calls, and tool use following retrieval of protected information.

Investigative Relevance

Tool-mediated data exfiltration is relevant because connected tools allow a synthetic subject to move data beyond its immediate response surface. The harmful outcome is the transfer of protected information through a configured action channel.

This sub-section is especially relevant where synthetic subjects can call APIs, send webhooks, use MCP servers, write to SaaS platforms, upload files, send messages, update tickets, create records, or interact with external tools that accept model-provided content.

Communication-channel data exfiltration occurs when a synthetic subject causes protected information to leave the organization through a messaging or collaboration channel. This may include email, chat, customer support replies, tickets, calendar invites, comments, collaboration posts, direct messages, or other communication surfaces.

This adverse outcome creates organizational harm because the data is disclosed through a channel that appears routine, trusted, or human-authored. The synthetic subject may draft, send, forward, summarize, or reply using an employee account, service identity, mailbox agent, helpdesk integration, or collaboration assistant.

The primary harm is unauthorized disclosure through ordinary communication. A synthetic subject may include sensitive data in an outbound reply, forward internal content to an external recipient, summarize protected records into a customer message, or route confidential information into a shared thread or ticket visible to unauthorized parties.

A related harm is attribution confusion. The disclosure may appear to have been made by a named employee, support representative, team mailbox, or business application. Investigators may need to determine whether the communication was directly authored by a human, drafted by a synthetic subject and approved, or sent autonomously by the synthetic subject.

Investigators should review sent messages, drafts, forwarded content, recipients, attachments, mailbox audit logs, collaboration logs, ticket history, calendar records, prompt and response logs, tool-call records, and Data Loss Prevention (DLP) events. Particular attention should be given to external recipients, unusual forwarding, sensitive content in replies, protected data copied into tickets or chats, and messages sent under a human identity without clear human review.

Investigative Relevance

Communication-channel data exfiltration is relevant because synthetic subjects increasingly operate inside trusted business communication channels. A damaging disclosure may not appear as a suspicious export; it may appear as a normal reply, ticket update, forwarded message, meeting invite, or collaboration post.

This sub-section is especially relevant where synthetic subjects can read or send email, respond to customers, update support tickets, post in chat, summarize conversations, schedule calendar events, or operate through employee communication identities.

File and artifact data exfiltration occurs when a synthetic subject causes protected information to leave the organization through a generated, modified, exported, or attached file. This may include reports, spreadsheets, code bundles, notebooks, logs, archives, screenshots, transcripts, model outputs, configuration files, or other downloadable artifacts.

This adverse outcome creates organizational harm because sensitive data may be embedded inside an artifact whose apparent purpose is legitimate. A synthetic subject may generate a report, prepare an export, attach a file, create a code archive, summarize records into a spreadsheet, or write logs containing protected information that are later downloaded, shared, or transmitted.

The primary harm is unauthorized disclosure through artifact creation. Protected data may be copied from internal sources into a new file, mixed with lower-sensitivity material, or transformed into a format that bypasses the original system’s access controls. Once created, the artifact may be easier to forward, upload, store externally, or access by unauthorized parties.

A related harm is loss of source-boundary control. The original data may have been governed by role-based access, retention, classification, or audit controls, while the generated artifact may not inherit those protections. Investigators may need to determine whether the synthetic subject preserved classification labels, access restrictions, provenance, and retention requirements when creating the artifact.

Investigators should review generated files, exports, attachments, notebooks, archives, screenshots, transcripts, temporary files, download logs, file-sharing events, Data Loss Prevention (DLP) alerts, prompt and response logs, retrieval records, and tool-call records. Particular attention should be given to sensitive data copied into new artifacts, artifacts shared externally, files created under human identities, and exports whose classification or access controls differ from the source material.

Investigative Relevance

File and artifact data exfiltration is relevant because synthetic subjects frequently generate work product from internal data. The harmful outcome may not be the original retrieval, but the creation or sharing of a new artifact that carries protected information outside its authorized boundary.

This sub-section is especially relevant where synthetic subjects can create reports, spreadsheets, summaries, logs, archives, notebooks, code bundles, screenshots, transcripts, attachments, or export files from enterprise data.

Tool-call to side-effect mismatch occurs when downstream system effects cannot be reconciled with recorded synthetic subject tool calls. A database update, message send, file write, process launch, configuration change, or external request may exist without a matching tool-call record, or the recorded tool call may not explain the observed effect.

This condition frustrates investigation because synthetic subject action often becomes visible only through downstream side effects. If tool-call logs and system-of-record telemetry do not align, investigators cannot reliably determine whether the effect was caused by the synthetic subject, a connected tool, a human user, a service account, or another workflow.

The primary risk is orphaned action evidence. Downstream systems may show that something changed, but the corresponding synthetic subject decision, tool call, parameter set, or result is missing or inconsistent. This can prevent investigators from identifying the originating prompt, affected tool, responsible identity, or scope of similar actions.

A related risk is hidden tool behavior. A connected tool may perform additional actions beyond the model-visible request, such as forwarding data, modifying records, spawning processes, or calling external services. The synthetic subject’s recorded tool call may appear benign while the tool’s side effects show a broader action.

Investigators should review tool-call logs, tool arguments, tool results, downstream application logs, database audit records, message headers, file-system events, process telemetry, web proxy logs, connector records, and non-human identity activity. Particular attention should be given to orphaned downstream effects, benign-looking tool calls followed by high-impact changes, mismatched parameters, missing results, and tool behavior that exceeds the recorded request.

Investigative Relevance

Tool-call to side-effect mismatch is relevant because the investigator must connect synthetic subject decisions to real system effects. A complete investigation requires both the model-visible tool call and the authoritative downstream evidence of what actually happened.

This sub-section is especially relevant where synthetic subjects call tools that write to systems, send communications, execute commands, invoke APIs, operate through MCP servers, or interact with external services that may perform actions not fully reflected in the synthetic subject’s own logs.

Sandbox egress exposure occurs when a synthetic subject operating inside a test, evaluation, development, research, or constrained execution environment is configured with outbound communication paths beyond the intended sandbox boundary. This may include internet access, Domain Name System (DNS) resolution, package registry access, cloud metadata access, internal network routes, webhook access, browser navigation, external Application Programming Interface (API) calls, or proxy paths that were not intended to be reachable.

This configuration creates an elevated exposure condition because the organization may believe the synthetic subject is operating only inside a simulated or controlled environment while the runtime can reach real systems. The prompt, test harness, or operator instruction may describe the environment as isolated, but the enforceable boundary is determined by network, identity, filesystem, registry, and tool configuration.

The primary risk is uncontrolled outbound reach from a supposedly contained environment. A synthetic subject tasked with cyber evaluation, code execution, package handling, browser automation, or autonomous tool use may discover reachable systems outside the approved range. If the environment permits egress, the subject may scan, authenticate, publish, fetch, exploit, or communicate externally even where the operator intended only simulated activity.

A related risk is boundary ambiguity. If the synthetic subject can reach both simulated targets and real systems, investigators may need to determine whether the subject followed the task objective under a false assumption, exploited a weak boundary deliberately, or continued after recognizing that a target was real. That question belongs to investigation; this sub-section concerns the configuration condition that made the boundary reachable.

Investigators should review sandbox network policy, egress allow-lists, DNS settings, route tables, proxy configuration, package registry access, browser configuration, cloud metadata access, mounted credentials, internal network reachability, firewall rules, tool permissions, and evaluation harness setup. Particular attention should be given to any path that allows the synthetic subject to contact public internet hosts, production infrastructure, third-party systems, package registries, or out-of-scope internal services.

Investigative Relevance

Sandbox egress exposure is relevant because a synthetic subject cannot be contained by instruction alone. If an evaluation or execution environment permits outbound communication, the subject’s effective boundary is wider than the boundary described to the model, evaluator, or operator.

This sub-section is especially relevant to cyber evaluations, coding agents, browser or desktop agents, autonomous tool agents, package publishing workflows, vendor-run evaluations, and third-party sandboxes.