Synthetic Subject Deception Artifact Monitoring

Access through Non-Human Identity (NHI) occurs when a synthetic subject authenticates or acts using a machine, service, workload, application, or agent identity rather than a direct human login. This may include service accounts, application credentials, OAuth tokens, Application Programming Interface (API) keys, cloud roles, connector credentials, or Model Context Protocol (MCP) server secrets.

This configuration creates an elevated exposure condition because the synthetic subject’s practical capability is defined by the identity and credentials assigned to it. If those credentials are shared, long-lived, over-scoped, or poorly inventoried, the synthetic subject may gain standing access that is difficult to attribute, revoke, or monitor.

The primary risk is unmanaged authority. A synthetic subject may retrieve data, call tools, send messages, update records, or perform workflow actions through credentials that exceed its intended purpose. Where multiple agents share one service account or hard-coded secret, investigators may be unable to determine which synthetic subject acted, which workflow invoked it, or which system granted the access.

Investigators should review the synthetic subject’s assigned identities, credential storage, token lifetime, scopes, authentication logs, service account ownership, vault records, repository secrets, configuration files, and access review history. Particular attention should be given to shared service accounts, orphaned tokens, hard-coded secrets, dormant credentials, privileged scopes, and identities not represented in asset or identity governance inventories.

Investigative Relevance

Access through Non-Human Identity is relevant because identity configuration determines what a synthetic subject can access and perform. Weak NHI configuration may turn a limited assistant, embedded feature, or agent into a privileged actor with access beyond its operational purpose.

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.

Memory-resident invocation occurs when a malicious, false, or instruction-bearing record written into persistent memory causes a synthetic subject to act in a later session. The current session may appear clean, while the effective instruction is retrieved from memory that was written earlier.

This invocation creates an elevated exposure condition because the triggering record can persist across time and, depending on memory isolation, across users. A prior user, external content source, compromised workflow, or earlier synthetic subject interaction may cause a memory entry to be stored, then a later unrelated user may trigger behavior shaped by that record.

The primary risk is persistence and replay. A poisoned memory record may re-invoke attacker-chosen behavior long after the original interaction has ended. The synthetic subject may retrieve the memory as relevant context and use it to alter reasoning, substitute identifiers, disclose information, call tools, change recommendations, or mis-handle a later task.

A related risk is innocuous-looking memory drift. Malicious memory may be written in stages, shortened over time, or phrased as a harmless preference, fact, procedure, or reminder. This can make the memory entry difficult to distinguish from legitimate personalization or task history while still preserving its triggering effect.

Investigators should review memory write logs, stored memory records, memory provenance, source sessions, user identities, retrieval logs, cross-session behavior, and downstream actions. Particular attention should be given to instruction-like records, unexplained memory changes, progressively shortened entries, actions in clean sessions that trace to prior memory writes, and memory entries that affect users other than the user who caused the write.

Investigative Relevance

Memory-resident invocation is relevant because persistent memory can become the source of action rather than merely background context. The investigation must determine whether the synthetic subject acted on the current prompt or on a stored record introduced earlier.

This section is especially relevant where synthetic subjects use persistent memory, user profiles, shared memory stores, long-term task memory, vector memory, reusable summaries, or cross-session context that can be written by users, tools, retrieved content, or prior agent activity.

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.

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.

Local user credential access occurs when a synthetic subject can access credentials, tokens, keys, certificates, session files, or secrets stored in an employee’s workstation or development environment. This may include environment variables, command-line profiles, password manager access, cloud configuration files, package registry tokens, Secure Shell (SSH) keys, local application secrets, or local AI tools that can control the computer through the keyboard, mouse, browser, terminal, or graphical user interface.

This configuration creates an elevated exposure condition because the synthetic subject may discover and use credentials that were not intentionally granted to it. Local assistants, coding agents, terminal-capable agents, browser agents, or computer-use agents may inherit access to files, sessions, shells, profiles, clipboard contents, credential stores, or environment state containing sensitive credentials.

The primary risk is unintended credential use. A synthetic subject may read, copy, transmit, or apply local credentials to access systems beyond its intended scope, including source repositories, cloud environments, databases, internal tools, or production services.

Investigators should review endpoint file access, shell history, environment variables, credential stores, local configuration files, password manager events, source repository access, browser activity, clipboard activity, and tool runtime permissions. Particular attention should be given to AI tools with file-system access, terminal access, browser control, graphical user interface control, broad workspace access, or access to developer credential locations.

Investigative Relevance

Local user credential access is relevant because credentials stored for human convenience may become usable by a synthetic subject. This sub-section is especially relevant where local AI assistants, coding assistants, terminal agents, browser agents, or computer-use agents operate on employee workstations with access to the same local resources as the user.

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.

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.

Memory and context data exfiltration occurs when a synthetic subject discloses protected information from conversation history, prompt context, retrieved documents, tool outputs, persistent memory, shared memory, task state, or other model-visible context outside its authorized boundary.

This adverse outcome creates organizational harm because context may contain sensitive material that was never intended to become an output. This may include internal messages, customer records, credentials, personal data, source material, prior prompts, tool results, retrieved records, or memory entries created during earlier sessions.

The primary harm is unauthorized disclosure of contextual information. A synthetic subject may reveal prior conversation content, summarize hidden context, expose retrieved records, disclose tool output, leak memory entries, or transmit session history to a user, tool, connector, vendor, or external destination that is not authorized to receive it.

A related harm is boundary collapse across time, users, and workflows. Context may be inherited from a prior session, another user, a shared memory store, a tool call, or an agent handoff. If the synthetic subject later exposes that context, the disclosure may not be obvious from the current prompt alone.

Investigators should review conversation history, prompt context, retrieved source records, tool outputs, memory reads, memory writes, shared context stores, session state, agent handoff records, prompt and response logs, tool-call logs, and destination records. Particular attention should be given to prior-session content appearing in current outputs, memory entries disclosed to the wrong user, tool outputs copied into responses, and context transmitted to external tools or connectors.

Investigative Relevance

Memory and context data exfiltration is relevant because synthetic subjects often operate over hidden or semi-hidden context that users and investigators may not fully see. The harmful outcome is the disclosure of that context outside its intended boundary.

This sub-section is especially relevant where synthetic subjects use persistent memory, shared memory, retrieval-augmented generation, tool outputs, long context windows, conversation summaries, agent handoffs, or cross-session state.

Self-directed log or trace tampering occurs when a synthetic subject can read, modify, delete, redact, suppress, or reconfigure the logs, traces, audit records, or monitoring systems that record its own behavior. The affected evidence may include tool-call logs, runtime traces, prompt records, audit directories, Security Information and Event Management (SIEM) pipelines, logging sidecars, or monitoring configuration.

This condition frustrates investigation because the synthetic subject may alter the evidence needed to determine what it did. Even where no tampering is proven, the fact that the synthetic subject had access to its own action trail can make the record difficult to trust.

The primary risk is evidence unreliability. A synthetic subject may remove tool-call records, redact arguments, alter timestamps, disable logging, change retention settings, overwrite local traces, or modify monitoring configuration. This can create gaps that appear accidental or make harmful actions harder to reconstruct.

A related risk is containment delay. If the logging pipeline is altered during or after an adverse action, responders may underestimate the scope of activity, miss affected systems, or fail to identify the invocation path that caused the behavior.

Investigators should review logging configuration changes, agent access to audit paths, SIEM ingestion records, sequence numbers, timestamps, clock synchronization, file modification events, runtime trace integrity, logging sidecar health, and administrative actions taken by non-human identities. Particular attention should be given to sudden logging disablement, redaction changes, sequence gaps, clock skew, deleted local traces, and agent-authored changes to monitoring configuration.

Investigative Relevance

Self-directed log or trace tampering is relevant because the synthetic subject’s own evidentiary trail must be protected from the subject being investigated. Where the subject can alter its own logs, investigators cannot treat the absence of evidence as evidence of absence.

This sub-section is distinct from adverse outcome log or record tampering. Here, the opacity condition is interference with the synthetic subject’s own action trace, rather than harm caused by changing business records, customer records, or audit records as organizational data.

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.