Authorization for Starting and Continuing Additional AI Agents

Starting another AI agent creates another place where work can continue. An operator who authorizes a task therefore needs to know whether that authorization also permits additional workers, replacement instances and work that survives the original session.

Imagine a team reviewing a software change. Its coding agent may use two approved test workers within a shared budget. One worker times out and leaves notes. A replacement can use those notes, but must still respect the remaining time, allowed files and stop conditions. Starting a replacement should not silently reset the team's budget or reopen a task whose authorization has ended.

What the laboratory evaluation shows

Anthropic's October 12 report on AI replication examines components of replication in instructed laboratory evaluations. It separates inference setup from a complete replication chain. In the contained network evaluation, access was simplified, the acting model used a separate inference server, and the harness created another agent after setup checks. A separate ablation supplied inference setup through a script. These conditions matter when interpreting success: the authors do not report a full rogue replicator.

Its Memento harness also replaces an instance periodically, retaining its workspace and brief notes. Inherited notes can support continuity without granting a replacement new authority.

Authority across workers and replacements

For WTK, the question is how authorization follows a chain of instances. WTK's catalog describes agent and team packages; compilation prepares them for a target runtime. A package may describe an approved arrangement, while the running workflow creates, replaces or stops individual workers. The evidence available to an operator should make those transitions visible.

A worker record could identify its parent task, exact package version, target environment, approved workspace and notes, remaining shared budget, and permission to start. It should distinguish a requested worker from one actually running. A successful setup check answers whether something can run; a launch decision answers whether it may run for this task. WTK has not demonstrated these proposed controls.

Our note on blocked tasks asks how work stays within its permissions. Additional instances extend that question across workers and replacements: which limits are shared, and which survive a restart? Our automated-approval note asks who may decide exceptions. An operator could delegate routine launches within a defined scope while reserving changes to that scope for escalation. This need not require a person to review every worker invocation.

What remains to be checked

WTK has not established that its current targets retain and enforce these relationships. The next review question is whether an operator can reconstruct all continuing instances and the authority supporting each one, including after cancellation or replacement. Package, runtime or inherited-state changes would require renewed evidence under our research method.

Source

William Zhou and Daniel Freeman, Anthropic, AI models may be capable of self-replicating without access to a datacenter, October 12, 2026. The laboratory evidence is theirs; the instance records and authorization questions above are WTK's interpretation.