Recursive Self-Invocation

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.