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.