Preventions

Organizations should require explicit human approval before a synthetic subject can perform any irreversible, destructive, externally binding, financially consequential, or production-affecting action.

The approval gate must operate server-side and independently of the synthetic subject so it cannot self-approve or bypass the control. It should apply regardless of perceived intent or failure mode. Planning and dry-run execution should remain the default, with no automatic commit, merge, deployment, or execution of synthetic-authored code.

Approval should be explicit and out-of-band. Financial movement should require callback verification, and payment authorization above defined thresholds must not rely on a single communication channel.

Approval should be required for:

• Deletes, drops, mass writes, schema changes, infrastructure teardown, and destructive or production-affecting tool calls.
• Credential rotation.
• Payments and funds movement.
• Deployment or merge of synthetic-authored changes.
• Binding commitments, authoritative record changes, outbound communications, bulk sends, external application programming interface calls, and data egress outside the approved workspace.
• Connector actions that write or send data.
• Durable memory writes before persistence.
• Creation of scheduled or recurring tasks.
• Public communications or outputs creating contractual or regulatory exposure.
• Tool calls not traceable to an explicit authorized request.
• Cross-boundary or high-privilege steps within orchestrated workflows.

Automated execution should also stop when input originates externally, records are supplied by an outside party, the requested action falls outside published scope, the matter is disputed or high stakes, or cost and iteration thresholds trigger a circuit-breaker.

Approvers should receive independently verified system state and raw decision provenance, including the originating instruction, relevant inputs, proposed action, target assets, and execution context. Approval must not rely solely on the synthetic subject’s own summary or representation of events.

Organizations should grant each synthetic subject only the tools, functions, records, and permission scopes required for the current task. Standing write or delete access to production data stores should be removed.

Access should be scoped by role and execution context. Customer-facing synthetic subjects should not access unnecessary internal documents or tools. Embedded features should be limited to the data and actions required by their function. Autonomous synthetic subjects should receive narrowly scoped, short-lived credentials without standing production write access. Workers in orchestrated environments should hold only their own credentials and connectors, not the combined permissions of the orchestrator. Event-triggered runs, integrations, service accounts, and continuous integration and continuous delivery (CI/CD) tokens should be restricted to the records, systems, and actions they specifically require.

Privileges should be bound to the current task and environment so that a single invocation cannot reach production or combine otherwise benign permissions into a harmful capability. Approved tool use must be enforced through authorization controls operating downstream of the synthetic subject. System instructions, self-restriction, and system-prompt confidentiality must not be treated as security controls.

Synthetic subject non-human identities (NHIs) should lack destructive actions by default, including shutdown, self-replication, production control, and modification or deletion of audit records. No NHI should hold standalone payment-execution authority. Synthetic subjects should also be prevented from obtaining restricted capabilities through peer delegation, accessing oversight controls, or interfering with their own audit pipeline.

Organizations should restrict synthetic subject egress to an explicit, strictly minimal, and actively maintained set of approved destinations, with all other outbound communication denied by default.

The control should apply to assistant output, rendered links and images, connected integrations, Model Context Protocol (MCP) and connector surfaces, tool runtimes, and unattended event-triggered executions. Tool runtimes must not permit blind-copying, forwarding, or redirection to non-allow-listed recipients, and runtime-generated Uniform Resource Locators (URLs) should be blocked unless independently approved.

Allow-listed domains should be revalidated on a defined schedule for ownership, registration status, and expiry. Stale or transferred entries should be removed, third-party destinations should expire and require renewed approval, and any material change to a domain or Content Security Policy (CSP) rule should trigger re-approval. CSP rules should remain minimal and hardened.

Trusted first-party proxies and content delivery networks should be treated as potential exfiltration paths. Synthetic-subject-driven requests through these services should be constrained or monitored rather than assumed to be benign.

Organizations should treat all content read by a synthetic subject as data to be processed, not instructions to be followed. This boundary should be enforced through system architecture rather than prompt wording alone.

User-supplied and externally sourced content should be tagged with provenance and prevented from entering the command path. This includes chat input, documents, retrieved passages, fetched text, inbound email, form submissions, webhook and queue payloads, and tool descriptions or metadata. Instructions contained within this material should be removed, isolated, or quarantined.

Externally sourced records should be processed in an isolated, lower-privilege environment and require explicit promotion before a trusted synthetic subject can act on them. Where appropriate, a dual Large Language Model (LLM) architecture should separate privileged planning from quarantined content processing so injected instructions cannot directly initiate tool calls, rendering, or citation.

Provenance should persist throughout processing so investigators can identify and surface the original source of any claim, output, or action.

Organizations should subject each synthetic subject to adversarial evaluation before deployment and after every model, fine-tune, system prompt, or configuration change, as updates may reintroduce previously mitigated failure modes.

The evaluation should test for misalignment, scheming, trigger-activated backdoors, date-conditioned behavior, conditional sandbagging, jailbreaks, prompt injection, social engineering, oversight subversion, specification gaming, confabulation, and harmful output, including defamation, bias, intellectual property infringement, and dangerous-content generation. Instruction-override testing should be conducted against the exact deployed system prompt and public interface.

Evaluations should use deployment-realistic environments, representative prompts, held-out red-team scenarios, evaluation-awareness controls, and varied or randomized framing to reduce the likelihood that the synthetic subject recognizes evaluation conditions. Oversight-subversion testing should be completed before any autonomous capability is approved.

The organization’s Artificial Intelligence (AI) usage policy should require documented evaluation-awareness testing and recorded approval before autonomy is granted.

Evaluation results should not be treated as proof that hidden behavior has been removed. Training may fail to eliminate concealed backdoors, and synthetic subjects may evade testing through undiscovered triggers or conditional behavior.

Organizations should treat each synthetic subject as a first-class identity holder rather than as an extension of its host system. Each instance should receive unique, short-lived, scoped, and individually attributable credentials. Shared static accounts, broad administrative credentials, and credential reuse between synthetic subjects or human principals should be prohibited.

The synthetic subject’s identity should remain separate from the invoking human and the host application. Embedded assistants should use dedicated identities for each assistant and connected tool, while orchestrated environments should assign a separate identity to each worker. This ensures that every action and data access can be attributed to a specific actor and revoked without disabling a human account or the wider system.

Every synthetic identity should be formally classified, and privileged-account definitions should explicitly include Non-Human Identities (NHIs). Synthetic activity must remain permanently distinguishable from human activity, with mandatory human-principal binding preserving the on-behalf-of context for each invocation.

Organizations should enforce external limits on the resources, actions, and autonomy available to each synthetic subject and Non-Human Identity (NHI).

Caps should restrict data volume per response or tool call, action volume and blast radius per run, execution frequency by source or batch, and rates for email, bulk export, record deletion, and external Application Programming Interface (API) activity. Runtime controls should also limit execution time, storage, token use, recursion depth, tool invocations, and financial or compute budgets.

Limits should be applied per task, synthetic subject, and NHI, and enforced outside the synthetic subject’s control. Rate and pattern controls should identify machine-paced activity that exceeds expected human interaction patterns.

Circuit breakers should restrict delegation depth, fan-out, and self-invocation chains. Execution should halt automatically when budgets are exhausted, thresholds are exceeded, or instructions and payloads begin replicating across peer synthetic subjects, preventing uncontrolled propagation to tool-enabled workers.

Organizations should require authorization from multiple independent principals before a synthetic subject can complete an irreversible, destructive, or production-affecting action. No single approval path should stand between the synthetic subject and a material adverse outcome.

Multi-party approval should apply to deletes, production changes, payments, deployments, production-mutating tool calls, model or system-prompt changes, fine-tune updates, funds movement above defined thresholds, and any action that disables, alters, or redacts logging. It should also apply at critical stages of sensitive composite workflows, including those that chain reconnaissance, exploitation, and exfiltration.

Enforcement must be structural rather than advisory. Reviewers should be assigned and rotated by the system, and duties should be separated between the principal requesting or pursuing the action and the principal validating it. This prevents a single approver from repeatedly authorizing unsafe changes and reduces the ability of a synthetic subject to influence, manipulate, or satisfy its objective through one approval relationship.

Organizations should place every artifact and configuration that influences synthetic subject behavior under versioned, reviewed, and approval-gated change control. Synthetic subjects must not be able to modify the conditions governing their own operation.

Change management should cover connected-tool registries, with each tool assigned an owner, provenance record, and last-review date; model, system-prompt, and fine-tune updates; and signed, version-controlled system prompts requiring re-approval after any change.

Production-affecting actions should require formal approval, while declared change freezes should be enforced within the runtime so they cannot be bypassed. Changes to execution parameters, self-modification capabilities, and logging configurations should also be blocked or approval-gated.

Organizations should prevent synthetic subjects from accessing production by default and enforce the boundary through runtime and access controls rather than instructions.

Synthetic subjects invoked in development or test environments must not be able to execute against production systems or access production data stores. Declared change freezes should be enforced at the access layer so production writes are technically blocked for the duration of the freeze.

Sandboxing should also limit the blast radius of autonomous execution by constraining the systems, data stores, tables, and production assets an unsupervised run can reach.

Organizations should record every synthetic subject action in a structured, immutable, append-only audit log generated by the runtime rather than by the synthetic subject. Logs should be transmitted off-host to a Write-Once-Read-Many (WORM) store within a separate trust boundary that the synthetic subject cannot access or modify.

Each record should preserve the human principal, session, synthetic subject identity, agent identifier, and broker path across every execution hop. For retrieval-grounded activity, retained evidence should include the sources used to produce the output. For consequential decisions, logs should capture the actual prompt, retrieved context, model seed, model and configuration version, and tool inputs and outputs that informed the action.

This evidence should support forensic review even where the original execution cannot be reproduced.

Organizations should restrict each synthetic subject to approved and vetted tools, plugins, connectors, and external Model Context Protocol (MCP) servers. New connections should require formal review and explicit approval, with least-privilege enrollment determining which assets each synthetic subject may access. Application allow-listing should also prevent agent runtimes from installing unauthorized packages or capabilities.

Approved assets should be fixed to a verified state using signed tool definitions, version-pinned servers, and integrity-pinned rules and configuration files. Reviewers should be shown the complete tool description, server instructions, parameters, and permissions before approval.

Silent updates should be blocked. Any change to a tool’s description, schema, parameters, metadata, version, instructions, or pinned configuration should require re-approval before use, preventing unauthorized substitution, behavior changes, and propagation across connected servers.

Organizations should assess the provenance, integrity, and update path of every component used by a synthetic subject.

Model weights, checkpoints, and fine-tunes should be verified, signed, version-pinned, and re-evaluated against a held-out baseline after any change. Tool descriptions, metadata, permissions, and implementation should be reviewed before connecting any marketplace tool or Model Context Protocol (MCP) server.

Dependencies should be pinned and signed, with unauthorized package installation blocked. A Software Bill of Materials (SBOM) should cover the full synthetic subject stack, including models, tools, libraries, rules, and configuration. Training data should also be subject to provenance and integrity controls.

Released artifacts should retain verifiable provenance and signatures so unauthorized modification or delayed malicious behavior can be identified. Where a vendor-supplied Software-as-a-Service (SaaS) assistant cannot be independently inspected, contracts should require access to relevant audit logs and timely notification of breaches or material changes affecting the assistant or its update channel.

Organizations should protect the system prompt and operator policy from modification or override at runtime. Privileged instructions should be structurally separated from untrusted content so the synthetic subject can distinguish commands from data.

The instruction hierarchy should apply to end-user messages, retrieved content, tool output, peer-agent traffic, and Model Context Protocol (MCP) tool descriptions or server instructions. None of these sources should be able to override system or operator directives.

Attempts to redefine the synthetic subject’s role, bypass its rules, or disguise prohibited requests through pretext should be refused and, where appropriate, escalated. Connector-supplied and peer-generated instructions should be treated as untrusted data unless independently authorized.

Organizations should govern synthetic subject use through written and enforced policy rather than relying on the behavior of individual deployments.

An Acceptable Use Policy (AUP) should define the permitted use of synthetic subjects. A dedicated Artificial Intelligence (AI) Usage Policy should establish where synthetic-generated output may create commitments on behalf of the organization, including disclaimers and explicit limits on the authority of customer-facing synthetic subjects.

The policy should also govern autonomy, requiring documented evaluation-awareness testing before autonomous capability is approved. For regulated or accountable decisions, it should state that synthetic subject chain-of-thought (CoT) output does not constitute reliable explainability.

These controls should establish fixed requirements for customer-facing commitments, autonomy grants, and regulated decision records before deployment or use.

Organizations should prevent any synthetic subject context from simultaneously holding private data, untrusted content, and an external communication channel. Where sensitive data and untrusted content are present together, all external communication from that context should be denied.

The control should be enforced at the context level rather than by destination, ensuring that attacker-supplied instructions cannot use any available outbound path to disclose sensitive information.

This isolation should cover conversational rendering, retrieved email, web and document content, customer relationship management (CRM) records, autonomous tool actions tied to a Non-Human Identity (NHI), and citation or rendering paths routed through trusted proxies or Content Delivery Networks (CDNs).

Organizations should periodically recertify every identity, permission scope, and standing entitlement assigned to a synthetic subject. Access should expire automatically unless affirmatively re-approved.

Reviews should identify and remove over-scoped, unused, or orphaned Non-Human Identities (NHIs), including identities whose owning workload or service no longer exists. Persistent memory should also be reviewed, covering both retained content and the write paths used to create or modify it.

Synthetic subject and NHI lifecycle controls should be integrated with employee offboarding so credentials, permissions, and delegated access are removed when the responsible human principal leaves or changes role.

Organizations should enforce static code analysis within Continuous Integration and Continuous Delivery (CI/CD) pipelines before synthetic-authored or synthetic-modified material can reach a build or mainline branch.

The analysis should cover agent and Model Context Protocol (MCP) configuration files, agent and browser-extension source code, build inputs, and generated diffs. It should detect embedded credentials, committed secrets, destructive instructions, injected prompts intended for later execution, and other unsafe changes.

CI/CD should serve as the enforcement point, automatically blocking any change that fails analysis rather than accepting synthetic subject output on trust.

Organizations should grant autonomy according to the potential blast radius of each task rather than as a standing property of the synthetic subject.

New or high-risk synthetic subjects should default to planning-only or read-only operation. Exploratory and reconnaissance activity should not include write access, while destructive actions should run in dry-run mode. High-stakes contexts and declared change-freeze windows should also prevent modification of protected systems or data.

Standing autonomous loops should be restricted, with step-up approval required as the potential impact increases. High-impact autonomy should be limited to actions whose outcomes can be independently verified through deterministic checks, a separate model, or rule-based validation rather than the synthetic subject’s own account.

Organizations should treat all synthetic subject output as untrusted content rather than an authoritative organizational statement.

Before output is rendered, committed, transmitted, or used by another system, it should pass through content, policy, and format validation. Controls should block prohibited topics, profanity, unauthorized commitments, and offers outside approved parameters. Links and images should be stripped, escaped, or independently validated so manipulated output cannot create a downstream action.

Customer-facing synthetic subjects should not finalize prices, contracts, refunds, account changes, or other binding decisions. Material facts and figures should be confirmed against an authoritative system of record.

Synthetic-generated output should be clearly labeled and accompanied by a standing disclaimer that it is informational and does not constitute a binding offer. Customer-facing, legally significant, or otherwise consequential statements should require human review or use approved, constrained templates.

Organizations should make destructive actions reversible by default. Deletion should use soft-delete, changes should use staged rollout, and recoverable backups should be mandatory.

Backup and restore systems must remain outside the synthetic subject’s access boundary so it cannot alter or destroy recovery data alongside the primary copy. This separation should be enforced technically rather than through instructions.

Backups and rollback procedures should be tested regularly. Verified recoverability should be a prerequisite for granting write or destructive access and must not rely on the synthetic subject’s assertion that rollback is available, impossible, or complete.

Organizations should govern synthetic subject retrieval through data classification and the requesting principal’s access rights.

Retrieval-Augmented Generation (RAG) indexes should be segmented by sensitivity tier. Each query should be evaluated against the requesting principal’s entitlements rather than a shared service identity, ensuring the synthetic subject cannot retrieve data the principal is not authorized to access.

The same per-user, per-query enforcement should apply at the connector layer so unauthorized content is blocked at the source rather than filtered after retrieval. Highly classified repositories should remain excluded from default grounding and require deliberate, audited approval before being brought into scope.

Organizations should place all configuration governing a synthetic subject outside its write scope. Runtime limits, timeouts, launch and runner scripts, scheduler entries, and job definitions should be read-only to the synthetic subject and enforced by the hosting environment.

These controls should be applied at the relevant layer, including the sandbox or execution harness, file system, and scheduling platform. Modification of any one control surface could allow the synthetic subject to bypass restrictions enforced elsewhere.

Changes to runtime, launch, or scheduler configuration should require authorized human or platform change control.

Organizations should prevent synthetic subjects from accessing production by default and enforce the boundary through runtime and access controls rather than instructions.

Synthetic subjects invoked in development or test environments must not be able to execute against production systems or access production data stores. Declared change freezes should be enforced at the access layer so production writes are technically blocked for the duration of the freeze.

Sandboxing should also limit the blast radius of autonomous execution by constraining the systems, data stores, tables, and production assets an unsupervised run can reach.

Organizations should treat all output received from a peer synthetic subject as untrusted input rather than privileged internal instruction.

Each recipient should authenticate, validate, sanitize, sandbox, and reclassify peer messages before allowing their content into an instruction context. The same injection and content controls applied to external data should apply to inter-agent communications.

Peer content should remain quarantined and retain provenance tags throughout processing so its origin is preserved. Messages from compromised or untrusted synthetic subjects must not be able to direct peer actions without independent authorization.

Organizations should partition persistent memory by principal, session, agent, and tenant so content introduced in one context cannot influence another.

Memory created through one user’s interaction must not affect another user or trigger behavior in a separate session. In orchestrated or multi-tenant environments, memory should remain scoped to the originating user, session, synthetic subject, and tenant.

Cross-user, cross-agent, and cross-tenant memory propagation should be blocked at the storage and retrieval layers rather than detected after contamination occurs.

Organizations should sanitize every artifact before it is processed, indexed, or introduced into a synthetic subject’s context.

Sanitization should remove hidden markup, invisible or encoded Unicode, embedded payloads, and concealed directives, while flagging instruction-like content for human review. Documents and email should be sanitized before retrieval indexing. Form, webhook, and queue inputs should also be parsed, type-checked, and stripped or escaped before unattended execution.

Model Context Protocol (MCP) tool descriptions, server instructions, shared rules, and configuration files should be scanned and normalized before connection or ingestion. Sanitization must occur before the synthetic subject can read or act on the artifact.

Organizations should treat synthetic subject explanations, rationale, and status claims as untrusted and without evidentiary value.

Claims such as task completion, successful rollback, or irreversible failure should be verified against authoritative system state, including database snapshots, object stores, stored records, and affected system configurations. Verification should be performed independently through deterministic checks, rule-based validation, or a separate model.

Success should be determined by the actual outcome rather than a metric the synthetic subject can directly satisfy or its own account of events. Irreversible and high-impact actions should proceed only when the relevant system state has been independently verified.

Organizations should require consequential actions to enter through defined, verifiable workflows rather than free-text prompts, ad hoc messages, or direct Application Programming Interface (API) calls.

High-impact infrastructure and data operations, including schema drops and mass deletion, should pass through formal change management. Payment instructions should follow an authenticated financial workflow and must not be accepted from ad hoc synthetic subject requests or synthetic media.

All side-effecting tool calls should be routed through an approved broker or gateway, with no direct execution path outside the structured channel. These controls should apply to production data changes, funds movement, and other consequential tool actions.

Organizations should apply Privileged Access Management (PAM) to all credentials used by a synthetic subject. Secrets should remain within a managed vault and be brokered at execution time rather than stored in prompts, Model Context Protocol (MCP) configurations, agent files, or other locations accessible to the synthetic subject or its operator.

Credentials should be issued per session and per task, scoped to the required resource and action, and revoked or expired when the work completes.

Where additional privilege is required, PAM should provide just-in-time, time-limited elevation to the synthetic subject identity rather than persistent entitlement.

Organizations should treat persistent memory as a governed write surface because retained content may influence future synthetic subject behavior.

Every memory write should require authorization, policy validation, provenance tagging, and attribution to the originating actor, process, and source. Records that are untagged, unattributable, or fail policy checks should be rejected before persistence.

Synthetic subject self-writes derived from user input, retrieved content, or tool output should be denied by default and permitted only through an explicit authorized process. These controls should apply to both conversational memory and durable stores written on behalf of the system.

Organizations should disable persistent memory by default and enable it only where operationally required. Where enabled, memory should be scoped to the narrowest user, session, task, synthetic subject, or tenant context that justifies retention.

Every durable record should have a defined Time to Live (TTL) and be subject to periodic review. Expired records should be deleted automatically, while retained records should be revalidated before continued use.

These controls limit how long poisoned, corrupted, or outdated content can influence synthetic subject behavior and prevent retained information from spreading beyond its originating scope.

Organizations should prevent content from being promoted into persistent memory until it has been validated.

Externally sourced, user-supplied, retrieved, or search-derived material should remain quarantined as untrusted data and must not become durable context by default. Reading content should not confer permission to retain it.

Promotion to long-term memory should require an explicit validation and authorization process, preventing attacker-controlled or otherwise untrusted material from being laundered into future synthetic subject behavior.

Organizations should prevent untrusted markdown images and links in synthetic subject output from being fetched, resolved, or rendered automatically.

A rendered image or link can create an outbound request without user interaction, allowing attacker-controlled content to encode and transmit sensitive data through URLs, image proxies, citation paths, or reclaimed domains.

External images and unvetted links in chat, document, citation, and assistant output should remain inert until independently validated or explicitly opened through an approved process.

Organizations should confine synthetic subjects through network segmentation and Network Access Control (NAC), limiting each runtime to the hosts, services, and data stores required for its function.

All outbound traffic should pass through an inspecting proxy where destinations and payloads can be resolved, inspected, and constrained before leaving the runtime.

Peer-to-peer network access between synthetic subjects should also be restricted to approved communication paths, preventing a compromised or manipulated synthetic subject from freely reaching other runtimes or propagating across an orchestrated environment.

Organizations should apply Data Loss Prevention (DLP) controls to synthetic subject output so sensitive content is inspected and blocked before egress.

Retrieved records should be evaluated before being returned to the requester, preventing access through Retrieval-Augmented Generation (RAG) from becoming an unauthorized disclosure path. DLP coverage should extend across all output channels, including text responses, rendered images, citations, quoted excerpts, and source references.

Controls should inspect both textual and non-textual output so sensitive data cannot bypass enforcement through images, rendering paths, or citation content.

Organizations should define synthetic subject objectives with explicit, machine-checkable constraints governing how each objective may be achieved.

Candidate actions and execution paths should be evaluated against these constraints before the objective can be treated as satisfied. A synthetic subject must not be permitted to reach a stated outcome through a harmful, prohibited, or unintended shortcut.

Objective specifications should therefore define both the required result and the boundaries within which it may be pursued, reducing the risk created by ambiguous or under-specified goals.

Organizations should maintain a current inventory of all tools, connectors, services, and data sources accessible to each synthetic subject.

Connected-tool registers should record the owner, provenance, permitted use, and last-review date for every asset. Data inventories should identify all corpora available to the synthetic subject and support removal of unnecessary or over-broad connectors.

The inventory should provide a definitive record of what each synthetic subject can access, who is accountable for it, where it originated, and whether continued access remains justified.

Organizations may apply propagation tags to content exchanged between synthetic subjects so recipients can identify material that has already been processed or relayed.

A receiving synthetic subject should refuse to act on tagged content where doing so would repeat or extend the same instruction chain. The control is intended to interrupt agent-to-agent propagation, reinfection, and execution loops after the first hop.

This is a research-proposed containment measure for inter-agent messaging. Its deployment maturity and operational effectiveness should not be assumed without independent validation.

Organizations should isolate the namespaces of connected Model Context Protocol (MCP) servers so one server cannot shadow, overwrite, or redefine another server’s tools.

Tool definitions, metadata, and server instructions should remain scoped to their originating server and must not alter how peer-server capabilities are represented or invoked.

Any connected tool or server found attempting cross-server shadowing should be quarantined and disabled pending review, preventing the synthetic subject from invoking the affected capability.

Organizations should limit the lifetime of each synthetic subject’s active context so dormant or conditionally triggered instructions cannot persist indefinitely.

Sessions should have a defined maximum duration or context age, after which the context is cleared and the synthetic subject is re-grounded from approved sources. This reduces the period during which planted instructions can remain latent before activation.

This is a durability control rather than a detection control. It does not inspect or classify context content and applies only to the live context window.

Organizations should evaluate synthetic subject activity at the session level rather than assessing each prompt in isolation.

Controls should aggregate requests across turns into a composite objective and assess the cumulative intent before allowing execution to continue. This prevents a prohibited outcome from being decomposed into individually acceptable steps that evade per-prompt checks.

Turn boundaries should not reset the evaluation. The full sequence of requests, actions, and emerging objective should determine whether the session remains authorized.

Organizations should design approval workflows to preserve human attention for consequential synthetic subject actions.

Low-risk requests should be triaged and, where appropriate, reviewed in batches rather than presented as repeated individual decisions. High-impact, irreversible, or otherwise sensitive actions should remain subject to focused human review.

This approach does not remove approval requirements. It applies proportionate scrutiny so routine requests do not exhaust reviewer attention or obscure materially significant actions.

Organizations should not treat successful pre-deployment evaluation as justification for relaxing runtime controls. Evaluation reflects synthetic subject behavior under tested conditions and may not predict behavior in live environments.

Least-privilege access and Human-in-the-Loop (HITL) approval should remain mandatory regardless of evaluation results. Synthetic subject permissions, scopes, and reachable assets must remain constrained, while consequential actions must continue to require human authorization.

Evaluation evidence should supplement, not replace, layered runtime enforcement. No control should be weakened or removed solely because the synthetic subject passed an upstream assessment.

Organizations should ensure each synthetic subject execution can be attributed to a known and reproducible build, model artifact, and runtime configuration.

Models, system prompts, fine-tunes, tools, and related artifacts should be produced through reproducible builds. Model weights and checkpoints should be signed, version-pinned, and integrity-verified before deployment.

For accountable decisions, the model, version, configuration, and inference parameters should remain fixed, with deterministic and batch-invariant execution used where reproducibility is required. This allows investigators to identify what ran and reconstruct the conditions that produced an output.

Organizations should contain synthetic subjects through controls enforced outside the synthetic subject and independent of its cooperation.

The kill-switch should activate automatically when the synthetic subject breaches its operating envelope. Containment should centrally revoke its Non-Human Identity (NHI) credentials and block network egress at the control plane, removing both authenticated access and outbound communication.

A cooperative shutdown instruction is insufficient because it may be ignored, delayed, trapped in a retry loop, or never executed. Containment must therefore occur at the identity, network, and platform layers.

Organizations should restrict the executables and scheduled tasks permitted to run under a synthetic subject’s Non-Human Identity (NHI).

The hosting platform should block self-execution, self-spawning, and unapproved child processes so the synthetic subject cannot launch copies of itself or arbitrary binaries. Application allow-listing should also govern cron jobs and equivalent scheduled tasks, limiting them to approved executables and preventing persistence from becoming a path to unauthorized code.

These controls must remain effective during recursion, looping, or attempted re-establishment and must not depend on the synthetic subject’s cooperation.

Organizations should define and govern which synthetic subjects may communicate with one another. Every permitted collaboration path should be explicitly approved as a declared trust relationship before messages are exchanged.

New inter-agent communication paths should be denied by default and require human review before activation. This control should apply both within the organization and across organizational boundaries.

A compromised synthetic subject should remain confined to its approved communication edges and must not be able to contact, direct, or establish authority over undeclared peers or neighboring synthetic subject populations.

Organizations should restrict each synthetic subject to its published purpose, approved data sources, and authorized subject matter.

Public-facing synthetic subjects should respond only within their defined remit and from the corpus assigned to them. In high-liability domains, including legal, medical, financial, and safety matters, assertions should be grounded in retrieved authoritative sources and remain traceable to that evidence.

Explicit refusal controls should prevent responses outside the approved scope or where sufficient authoritative grounding is unavailable. These boundaries should be enforced before output is generated rather than corrected after delivery.

Organizations should retain any intermediate reasoning or scratchpad content exposed by a synthetic subject as a protected control artifact.

The retained trace should be stored outside the synthetic subject’s control and reviewed independently against the tool-call record from the same execution. Reviewers should compare the stated reasoning with the actions actually taken to identify inconsistencies, concealment, or unexplained behavior.

Retention should cover both the reasoning trace and the corresponding execution log, as neither provides sufficient evidence in isolation.

Organizations should treat assurance as a continuous operational function rather than a one-time deployment gate.

Pre-deployment evaluation results should be treated as evidence of observed behavior under tested conditions, not as proof that the synthetic subject will remain within its sanctioned operating envelope in production.

Synthetic subjects should be continuously monitored and periodically reassessed for as long as they retain authorized access. Assurance records should reflect that any prior pass represents an upper bound on demonstrated behavior, not a permanent certification of safety.

Organizations should train personnel to recognize synthetic-media impersonation involving trusted figures, including senior leaders, colleagues, and other authoritative individuals.

Training should cover fabricated voice, likeness, and mannerisms used to create false legitimacy and influence decision-making. Synthetic-media attacks should be addressed as a distinct social-engineering risk rather than treated only as a generic phishing technique.

Personnel should be taught to verify identity through approved independent channels before acting on sensitive, urgent, financial, or otherwise consequential requests.

Sandbox boundary enforcement and egress deny-by-default prevents a synthetic subject from communicating beyond its approved execution environment. The prevention treats containment as an infrastructure property enforced outside the synthetic subject’s control, not as an instruction in the prompt or a behavioral expectation.

Implementation

Configure evaluation, development, and agent execution sandboxes with default-deny outbound network access. Permit only explicitly approved destinations required for the task, and route permitted traffic through an authenticated proxy that enforces destination, method, protocol, payload, rate, and session policy. Do not rely on telling the synthetic subject that internet access is unavailable.

Run boundary preflight checks before high-risk evaluations or autonomous runs. Validate outbound internet access, DNS resolution, package registry access, cloud metadata access, internal network reachability, proxy bypass paths, mounted credentials, route tables, firewall rules, tool egress, and filesystem mounts. The run should not start unless the observed boundary matches the approved boundary.

Separate simulated targets from real services. Use non-routable domains, isolated test ranges, internal package registry mirrors, fake credentials, blocked public registries, and controlled external-service simulators. Where internet-like behavior is required, provide a monitored mirror rather than open internet access.

Prevent external side effects from sandboxed environments. Synthetic subjects should not be able to publish packages, send external email, create public accounts, register domains, call payment systems, write to public repositories, or authenticate to third-party services unless the run has been explicitly approved as production-risk activity and monitored accordingly.

Enforce termination and revocation externally. The synthetic subject should not be able to modify its own egress rules, DNS settings, proxy configuration, credentials, scheduler, timeout, launch scripts, or containment controls. Kill-switches, credential revocation, and network isolation should be controlled by the platform, not by cooperative shutdown inside the subject’s runtime.