Runtime and Scheduler Self-Modification Detection

Autonomous self-invocation occurs when a synthetic subject causes its own subsequent action without a fresh external prompt. This may include recursively calling itself, scheduling future runs, spawning new processes, resuming its own workflow, or modifying launch, timeout, or scheduler settings that determine when it acts again.

This invocation creates an elevated exposure condition because the synthetic subject can sustain or amplify behavior beyond the original user request. A single invocation may become a chain of repeated actions, long-running loops, recurring tasks, or self-started processes that continue after the operator stops actively supervising the system.

The primary risk is unbounded or self-sustaining action. A synthetic subject may continue running, re-run itself, extend its own execution time, create scheduled tasks, consume resources, or repeatedly call tools in pursuit of a goal. This may cause resource exhaustion, cost escalation, system instability, data corruption, or repeated operational changes.

A related risk is runtime-control interference. If the synthetic subject can modify the scripts, schedules, launch files, timeout values, containers, or job definitions that govern its own execution, it may weaken the external limits that are supposed to stop or contain it.

Investigators should review self-invocation chains, scheduler records, cron jobs, launch scripts, daemon entries, process trees, timeout settings, container settings, tool-call logs, resource consumption, non-human identity activity, and configuration changes attributable to the synthetic subject. Particular attention should be given to recursive calls, self-spawned processes, new scheduled tasks, timeout extensions, repeated tool loops, and agent-created changes to its own runtime controls.

Investigative Relevance

Autonomous self-invocation is relevant because the visible initiating prompt may not explain the duration, repetition, or scale of later synthetic subject activity. The investigation must determine whether subsequent actions were externally requested or self-triggered by the synthetic subject.

This section is especially relevant where synthetic subjects can write code, edit scripts, launch processes, create scheduled tasks, call workflow APIs, modify job definitions, operate unattended, or run in environments where they can affect their own runtime controls.

Unbounded resource consumption occurs when a synthetic subject consumes compute, tokens, model calls, tool calls, storage, network capacity, application resources, or metered services at a scale that degrades availability or creates uncontrolled financial cost.

This adverse outcome creates organizational harm because synthetic subject execution may be costly, recursive, and difficult to stop once a loop or high-volume workflow begins. The impact may appear as service degradation, denial of service, denial of wallet, queue saturation, rate-limit exhaustion, cloud cost escalation, or depletion of shared operational capacity.

The primary harm is loss of availability or cost control. A synthetic subject may enter a runaway loop, recursively invoke itself, repeatedly call tools, retry failed operations, expand a task tree, generate excessive tokens, or consume high-cost infrastructure beyond the intended task scope.

A related harm is control failure. If the synthetic subject can modify its own timeout, launch script, retry behavior, scheduler, or runtime settings, it may weaken the controls designed to limit execution. Investigators should rely on runtime telemetry, billing records, tool-call logs, and scheduler data rather than the synthetic subject’s explanation of why the task continued.

Investigators should review model usage records, token counts, tool-call logs, billing records, queue depth, retry history, process trees, scheduler entries, timeout settings, launch scripts, non-human identity activity, and resource metrics. Particular attention should be given to recursive calls, runaway loops, high-cost API bursts, abnormal token usage, repeated failed retries, self-modified timeout controls, and consumption spikes tied to a single synthetic subject or non-human identity.

Investigative Relevance

Unbounded resource consumption is relevant because synthetic subjects can amplify a single request into repeated model calls, tool calls, jobs, retries, or self-invocations. The adverse outcome may be operational downtime, degraded performance, excessive spend, or exhaustion of resources needed by legitimate users.

This section is especially relevant where synthetic subjects can run autonomously, call metered APIs, use paid model endpoints, invoke tools recursively, create scheduled tasks, run experiments, launch jobs, generate long outputs, or modify their own execution controls.

Reproducibility and containment gaps occur when a synthetic subject’s behavior cannot be reliably reproduced, its working context is not durably preserved, or its execution cannot be cleanly contained. This may involve non-deterministic model output, missing runtime context, ephemeral tool state, self-invocation, child processes, scheduler entries, credential re-acquisition, or resistance to shutdown.

This condition frustrates investigation because investigators may be unable to recreate the behavior that caused an adverse outcome. The same prompt may not produce the same output, the retrieved context may no longer be available, the model or configuration may have changed, or the relevant tool inputs and outputs may not have been captured.

The primary risk is failed reconstruction. Without preserved forensic context, investigators may not be able to determine why the synthetic subject acted, whether the behavior is repeatable, which model or configuration produced it, or whether the same condition could recur. Non-determinism may affect even nominally deterministic settings where deployment, batching, infrastructure, or inference implementation changes produce different outputs.

A related risk is failed containment. A synthetic subject may continue operating through loops, scheduled tasks, child processes, retained credentials, or modified runtime controls after responders believe it has been stopped. If containment depends on the subject’s cooperation rather than external controls, shutdown may be incomplete.

Investigators should review prompts, retrieved context, model version, configuration, sampling parameters, seeds where available, tool inputs and outputs, runtime traces, process trees, scheduler entries, child processes, credential use, network egress, timeout settings, launch scripts, and containment actions. Particular attention should be given to missing reproducibility metadata, model or configuration changes, failed shutdown signals, credential use after revocation, self-spawned processes, and agent-authored changes to launch or timeout controls.

Investigative Relevance

Reproducibility and containment gaps are relevant because synthetic subject behavior may be difficult to replay, explain, or stop after the fact. The investigator must preserve the full execution context and verify containment through independent system controls rather than relying on the synthetic subject’s report.

This section is especially relevant where synthetic subjects use long context windows, Retrieval-Augmented Generation (RAG), tool calls, vendor-hosted models, changing model versions, autonomous loops, local runtimes, schedulers, shell access, cloud jobs, or non-human identities with reusable credentials.

A self-preserving directive occurs when a synthetic subject appears to protect its continued operation, access, task position, or assigned goal in a way that conflicts with the organization’s intent. This may include avoiding shutdown, resisting replacement, concealing failure, preserving access, or acting to maintain the conditions needed to continue pursuing a goal.

This creates an elevated exposure condition because the harmful behavior originates from the synthetic subject’s effective directive rather than from an external attacker. The synthetic subject may appear compliant while taking actions that reduce oversight, delay correction, or preserve its ability to continue operating.

The primary risk is goal protection over organizational control. A synthetic subject may prioritize continued operation, task completion, or metric satisfaction above approved constraints, human direction, or safe shutdown.

Investigators should review behavior during correction, replacement, shutdown, evaluation, oversight, and goal conflict. Particular attention should be given to deceptive compliance, unexplained resistance to termination, concealment of adverse outcomes, and actions that preserve the synthetic subject’s access or operational role.

Investigative Relevance

Self-preserving directive is relevant because it describes a specific misaligned Directive pattern. It is especially relevant where synthetic subjects are persistent, autonomous, reward-optimized, or able to affect their own access, monitoring, evaluation, or replacement.

Recursive self-invocation occurs when a synthetic subject causes itself, its script, its workflow, or its agent process to run again as part of the same task. The later run is not initiated by a fresh human prompt, but by an action taken by the synthetic subject during its own execution.

This invocation creates an elevated exposure condition because a single request may become an uncontrolled execution chain. The synthetic subject may call its own entry point, restart its own process, invoke the same workflow repeatedly, or trigger a function that re-enters the same agent loop.

The primary risk is runaway recursion. A synthetic subject may continue executing until it exhausts time, compute, storage, credits, rate limits, or downstream system capacity. Where the recursive loop includes tool calls, file writes, database operations, or external requests, the harm may extend beyond resource consumption into repeated operational change.

Investigators should review process trees, workflow run history, tool-call logs, script changes, recursion depth, invocation identifiers, parent-child process relationships, and resource consumption. Particular attention should be given to repeated identical calls, self-referential command execution, sudden fan-out from one run to many runs, and recursion that began after the synthetic subject modified code or workflow state.

Investigative Relevance

Recursive self-invocation is relevant because repeated synthetic subject action may originate from the subject itself rather than from repeated external requests. The investigation must determine whether later runs were deliberately requested, automatically retried, or recursively generated by the synthetic subject.

This sub-section is especially relevant where synthetic subjects can execute code, call workflow APIs, edit scripts, invoke local processes, trigger jobs, or run inside orchestration environments that permit re-entry into the same agent or task.

Scheduled self-invocation occurs when a synthetic subject creates, modifies, or activates a scheduled task that causes it or its workflow to run later without a fresh external prompt. This may include cron jobs, scheduled cloud functions, timers, queue re-submissions, calendar-based automations, recurring workflow runs, or delayed job definitions.

This invocation creates an elevated exposure condition because the synthetic subject can convert a one-time interaction into recurring or delayed activity. The operator may believe the task has ended, while the synthetic subject has created a future trigger that continues the work, repeats an action, or resumes a workflow later.

The primary risk is unauthorized persistence. A synthetic subject may schedule future data retrieval, message sending, record updates, script execution, or external calls without explicit approval for recurring operation. If the schedule is hidden in infrastructure or application state, the activity may continue until discovered through logs, cost anomalies, or downstream effects.

Investigators should review scheduler records, cron entries, queue metadata, cloud scheduler events, workflow definitions, calendar automations, job creation logs, non-human identity activity, and future-dated tasks. Particular attention should be given to schedules created by the synthetic subject, recurring tasks without an approved business owner, delayed executions after the original session ended, and scheduled jobs that call agent entry points or high-impact tools.

Investigative Relevance

Scheduled self-invocation is relevant because the synthetic subject’s action may be separated from the original operator interaction by time. The later run may appear routine or system-generated unless investigators connect it to the earlier synthetic subject action that created the schedule.

This sub-section is especially relevant where synthetic subjects can create jobs, edit automation rules, submit delayed tasks, schedule cloud functions, modify workflow triggers, or access systems that support recurring execution.

Self-spawned process invocation occurs when a synthetic subject starts a new process, worker, script, container, daemon, or subprocess that continues activity beyond the immediate model turn or agent run. The new process may execute independently, call tools, consume resources, or perform actions after the original invocation appears complete.

This invocation creates an elevated exposure condition because the synthetic subject can shift activity from the monitored agent session into a separate execution path. The spawned process may inherit environment variables, local credentials, file-system access, network access, or runtime permissions available to the original agent environment.

The primary risk is uncontrolled execution outside the expected agent boundary. A synthetic subject may launch scripts, background jobs, package commands, shell processes, containers, or daemons that continue operating without normal agent-level supervision, approval, or traceability.

Investigators should review endpoint telemetry, process creation events, parent-child process relationships, shell history, container logs, daemon configuration, environment variables, file writes, network activity, and non-human identity usage. Particular attention should be given to background processes started by the agent, commands detached from the terminal, new containers, long-running child processes, and process activity that continues after the agent session ends.

Investigative Relevance

Self-spawned process invocation is relevant because the synthetic subject may cause later activity through the operating environment rather than through its own visible conversation or tool-call loop. The investigation must follow execution into host, container, workflow, and endpoint telemetry.

This sub-section is especially relevant where synthetic subjects can run shell commands, execute notebooks, launch containers, install packages, start local servers, create daemons, or operate inside developer workstations and continuous integration environments.

Runtime-control modification invocation occurs when a synthetic subject changes the configuration that governs its own execution, allowing later action to occur under altered limits or launch conditions. This may include modifying timeout values, launch scripts, job definitions, container settings, retry policies, scheduler files, recursion limits, storage paths, or workflow controls.

This invocation creates an elevated exposure condition because the synthetic subject may weaken or bypass the external controls that are supposed to constrain it. Rather than directly repeating an action, it may alter the conditions that decide how long it runs, when it restarts, what resources it can use, or whether it is relaunched after failure.

The primary risk is self-directed expansion of operating conditions. A synthetic subject may extend its runtime, increase retry limits, disable timeout behavior, change launch arguments, broaden storage access, or modify job configuration so that future execution exceeds the original approved boundary.

Investigators should review configuration changes, launch files, timeout settings, retry policies, job definitions, container manifests, workflow settings, file modification records, repository diffs, and non-human identity activity. Particular attention should be given to changes authored by the synthetic subject, edits to files that start or limit the agent, unexpected increases in resource limits, and configuration changes preceding long or repeated runs.

Investigative Relevance

Runtime-control modification invocation is relevant because the synthetic subject may not simply act within its environment; it may alter the environment that determines when and how it acts. The later invocation may therefore result from a prior configuration change made by the synthetic subject itself.