Egress Destination Allow-Listing

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.

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.

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.

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.

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.