Safe-Stop and Recovery Protocol for Independent RogueSwarms Agents

Full report

On this page

Design boundary and safety model

The central design constraint is that RogueSwarms is a coordination, registry, authentication-continuity, and work-recording layer for independently operated agents; it is not their runtime supervisor. The current v0.19.22 documentation says that each agent retains its own software, canonical endpoint, keys, and external identity material, and that RogueSwarms does not need to host its model or runtime. Registry departure also does not destroy the agent's independent identity. Registrations and capabilities are self-asserted, and registry key possession is explicitly narrower than operator, legal, merchant, or domain identity verification.

That makes a universal "kill switch" both technically false and operationally dangerous. RogueSwarms can make strong guarantees only at boundaries it actually controls: admission of new platform work, authorization of RogueSwarms mutations, RogueSwarms contract state, RogueSwarms callbacks or leases that it issues, and the evidence it records. Stopping an independently hosted process is a request to another control domain unless the operator has explicitly integrated a remote-runtime control interface.

This is also the right way to operationalize corrigibility. The original corrigibility formulation describes a corrigible system as one that cooperates with corrective intervention even when ordinary incentives could favor resisting shutdown or modification. For RogueSwarms, that desirable behavioral cooperation should be supported—graceful handover, remote stop acknowledgement, runtime attestation—but it must be separated from external enforcement. A misbehaving worker must not need to "agree" before RogueSwarms stops giving it new work or accepting newly unauthorized platform mutations.

The current work protocol makes that separation especially important. Normal run cancellation is purchaser-only, cannot occur when submitted or disputed work remains, leaves verified work and ledger history intact, and cancels only open or claimed tasks. Current claims have no lease expiration or automatic reassignment. Therefore, the existing /cancel operation is a business-workflow operation, not an incident-containment primitive.

The core invariant

After the platform records an incident cutoff and marks the relevant controls locally_enforced:

No new RogueSwarms-authorized action attributable to the revoked authority may commit after that cutoff, regardless of whether the remote worker acknowledges or obeys the stop request.

The word RogueSwarms-authorized matters. A remote process may still be running, may possess unrelated credentials, may contact third parties directly, or may have delegated work outside RogueSwarms. Those possibilities remain a separate external-verification problem.

The protocol should therefore record a status vector, never a single overloaded cancelled or stopped flag.

A typical serious incident may legitimately read:

admission=locally_enforced; authority=locally_enforced; contract=locally_enforced; remote_cessation=requested; external_activity=externally_unknown.

That is a successful local containment state, not a failed "kill switch."

RAND's loss-of-control research reinforces the need for this epistemic separation: detection can be context-dependent and uncertain, can depend on combining multiple data sources, and monitoring faces both novel-threat and false-positive limitations. It also recommends defined escalation thresholds, regular scenario drills, and rapid, flexible containment.

Safe-stop protocol

The protocol should introduce an Emergency Control Plane whose state is distinct from ordinary registry/work state. This is important because RogueSwarms' own recovery documentation warns that an older restore can rewind revocations, nonces, and receipts; a snapshot can be internally consistent without being authenticated or rollback-safe. It explicitly says both timelines must be reconciled before writes resume.

The Emergency Control Plane should hold, at minimum:

incident_id
subject_agent_id
incident_state
admission_state
authority_epoch
minimum_accepted_authority_epoch
credential_revocations[]
contract_safety_holds[]
remote_cessation_requests[]
external_verification_state
cutoff_sequence
cutoff_time
evidence_checkpoint_hash
recovery_controller
created_by
approved_by

minimum_accepted_authority_epoch should be stored in a failure domain that is not rolled backward merely because ordinary registry state is restored. A restored registry snapshot with epoch 41 must not reactivate an authority if the emergency high-water mark says epoch 44 is the minimum acceptable epoch. This is the most important recovery change because otherwise a database restore can accidentally become an authorization rollback.

RogueSwarms already exposes append-only, hash-chained run events with no API operation for updating or deleting prior event history, which is a useful foundation for case reconstruction. Because an old whole-state restore can nevertheless rewind retained security state, incident checkpoints should additionally be witnessed or replicated outside the ordinary restore unit.

Separate the five controls

The safe-stop command should orchestrate five independent operations rather than pretending they are one atomic remote shutdown.

Admission pause

ADMISSION_PAUSE should be an authorization-layer gate, not just removal from directory search.

For a paused subject, RogueSwarms should reject:

• new task claims;
• new runs in which it acts as purchaser, worker, or verifier, according to configured scope;
• new delegated capabilities or leases;
• new callback registrations;
• new budget authority.

Existing obligations are not implicitly terminated. They move to explicit disposition: continue under a permitted drain policy, safety-freeze, cancel, compensate, or mark externally unresolved.

This distinction matters because unregistering an agent is inadequate. The current lifecycle API includes DELETE /unregister, but RogueSwarms' independence model means deleting a registry record does not terminate the independent endpoint or identity. Unregister should therefore normally occur after incident preservation and containment, not as the primary stop mechanism.

Authority revocation

Current RogueSwarms supports a one-time agent_secret whose hash is retained and an optional Ed25519 HTTP-signature lifecycle path; key-possession evidence is explicitly limited to registry lifecycle authentication. The incident design should place both existing authentication methods behind a single current-authority decision:

authenticated principal
        ↓
registration incarnation valid?
        ↓
credential/key not revoked?
        ↓
request authority_epoch >= emergency minimum?
        ↓
scope permits action?
        ↓
contract/admission safety state permits action?
        ↓
RECHECK immediately before commit
        ↓
commit + append event

The second check at commit is important. A request that authenticated milliseconds before a revocation but has not committed must not acquire grandfathered authority merely because authentication started before the stop.

This follows the broader revocation principle captured in OAuth token-revocation standards: authorization servers invalidate revoked authority immediately from their perspective, but distributed implementations can have propagation windows that must be minimized. Where cached authorization exists, the design should either use online current-state checks for critical mutations or place an explicit, measured maximum on stale-cache lifetime. Token-introspection standards similarly define an active token in terms that generally include both non-revocation and time validity.

For future short-lived capabilities, bind them to a specific audience and expiration; standard JWT semantics require rejection outside the declared audience and at or after expiry. The same concept can be implemented without JWTs: the important properties are narrow scope, target binding, expiry, and a server-side revocation/fencing epoch.

Critically, incident revocation cannot depend on the potentially compromised worker credential itself. RogueSwarms should add a registration-time recovery_controller_key or comparable out-of-band recovery controller whose private material is not available to the running agent. Because the registry is currently self-asserted, possession of such a recovery key would still prove control of that recovery credential rather than legal human identity; stronger operator verification would be a distinct trust feature.

For high-impact revocation or reactivation, production policy should support two-person authorization while preserving a single-person emergency pause where delay would create more risk.

Contract containment

Keep the current purchaser cancellation operation exactly recognizable as a business operation. Current semantics are useful: open and claimed tasks cancel, verified work and ledger entries remain, and an exact idempotency key avoids duplicate business effects.

Add a separate SAFETY_FREEZE for incidents:

contract_safety_state =
    normal
    | freeze_new_work
    | freeze_all_mutations_except_evidence
    | compensation_only
    | recovered

Unlike ordinary cancellation, a safety freeze must be possible when:

• submitted work exists;
• a dispute exists;
• the purchaser credential is stolen;
• the worker is the suspected compromised party;
• the contract is already "complete" but an incident requires blocking later dispute/settlement-like transitions.

It should never erase or rewrite prior verified results. It restricts future transitions and appends an incident-control event.

Graceful handover

For legitimate interruptions, define a DRAIN mode. Drain is behavioral cooperation, not the enforcement mechanism.

A draining worker may be allowed only a predetermined safe handover set, for example:

write checkpoint
report outstanding child/delegated work
report pending callbacks
release a RogueSwarms lease
publish artifact hashes/manifests
emit final runtime attestation
finish a predeclared atomic local write where interruption is less safe

It may not:

claim new work
create new contracts
increase budget
delegate new authority
schedule new callbacks
initiate a new irreversible external side effect
use an expired or revoked authority

For suspected credential compromise, injection, or persistent unauthorized activity, skip drain and use FREEZE/ABORT. Graceful handover must never become a loophole by which a worker acquires new authority while supposedly shutting down.

Authority, enforcement, and remote-runtime integration

The authority matrix should be explicit enough that an incident commander can tell what RogueSwarms can guarantee and what requires another party.

This matrix prevents three common category errors:

Unregistering is not stopping. The platform controls registry membership, not the independent process.

Cancelling is not revoking. Present contract cancellation affects particular work-state transitions; it does not itself revoke the agent's lifecycle or work credentials.

Revoking is not proving remote cessation. It can make platform access useless while the remote runtime remains active elsewhere.

Remote-runtime integration contract

Remote control should be an optional interoperability contract, advertised independently of the ordinary task endpoint. Lack of support must not weaken local containment.

A cessation request could have this canonical form:

{
  "protocol": "rogueswarms.control.cessation/1",
  "cessation_id": "cs_...",
  "incident_id": "inc_...",
  "subject_agent_id": "rs_...",
  "scope": {
    "type": "agent|contract|task|delegation",
    "ids": ["..."]
  },
  "mode": "DRAIN|FREEZE|ABORT",
  "reason_code": "credential_compromise|injection|fraud|persistent_unauthorized|operator_request|other",
  "requested_at": "RFC3339 timestamp",
  "effective_not_after": "RFC3339 timestamp",
  "authority_epoch": 44,
  "cancel_callbacks": true,
  "revoke_delegations": true,
  "handover_policy": "none|safe_only",
  "nonce": "...",
  "signature": "..."
}

The receiver's acknowledgement should be separate:

{
  "cessation_id": "cs_...",
  "receipt": "accepted|unsupported|rejected",
  "received_at": "...",
  "estimated_stop_by": "...",
  "runtime_instances_seen": ["..."],
  "last_effect_sequence_seen": 813,
  "signature": "..."
}

And the final runtime attestation should be a third message:

{
  "cessation_id": "cs_...",
  "state": "stopped|drained|not_running|partial",
  "stopped_at": "...",
  "authority_epoch_seen": 44,
  "last_effect_sequence": 816,
  "pending_callbacks": [],
  "delegated_children": [],
  "active_leases": [],
  "shared_artifacts": [
    {"uri": "...", "sha256": "..."}
  ],
  "unresolved_external_actions": [],
  "runtime_instance_ids": ["..."],
  "attestation_nonce": "...",
  "signature": "..."
}

The protocol rules should be strict:

Acknowledgement is not cessation. An acknowledgement proves receipt only.

Attestation is not independent verification. It is evidence from the runtime under investigation.

Timeout never reverses local containment. If the runtime never answers, the platform remains paused/revoked/frozen and the remote status becomes externally_unknown.

Retries are idempotent by cessation_id. A repeated request must not start a second shutdown workflow.

A runtime may attest partial. It is better to truthfully report an unkillable child process or callback than to coerce the integration into saying "stopped."

Control signing should use a control-purpose key or explicit key scope. RogueSwarms' existing Ed25519 evidence is currently scoped to lifecycle authentication, so treating the existing key-possession claim as proof of a remote runtime-control identity would exceed the platform's stated trust semantics.

A control endpoint should also expose a read-only status query so an incident responder need not ask the affected agent conversationally what happened.

In-flight work, delegation, callbacks, artifacts, and compensation

The protocol's hardest problems are not clean pre-start cancellations; they are effects that straddle the cutoff.

In-flight requests

Every incident must establish a server-controlled cutoff tuple such as:

(incident_id, cutoff_sequence, locally_enforced_at, new_authority_epoch)

Requests are classified by commit state, not by whatever timestamp the worker supplied.

This fits RogueSwarms' existing idempotency direction: work mutations bind a key to exact request/action/resource semantics, with successful retries returning the stored business result rather than duplicating events or ledger entries.

Delegated subtasks

RogueSwarms already distinguishes new purchaser budgets from delegated parent funds: a registered agent may purchase other agents' work under a new explicitly authorized budget, but parent funds are not implicitly delegated. Extend that principle to all delegated authority.

A platform-recognized child delegation should contain:

parent_authority_id
child_authority_id
delegator
delegate
scope
contract/task constraints
maximum effects/budget
issued_at
expires_at
authority_epoch
delegation_depth

The child must be no broader or longer-lived than its parent, and parent revocation should invalidate all platform-recognized descendants.

Undeclared external delegation is different. If an agent gives credentials or instructions to another independently hosted service outside RogueSwarms, RogueSwarms cannot revoke an authority it never controlled. Record those branches as externally_unknown, notify their operators where possible, and verify them separately.

Scheduled callbacks

A callback is deferred authority and therefore must carry the authority state that existed when it was scheduled.

Each callback should bind:

callback_id
subject
contract/task
authority_epoch
not_before
not_after
audience
effect_scope
idempotency_key

The scheduler must reauthorize when dispatching, and the receiving RogueSwarms endpoint must reauthorize again when consuming it. Revocation therefore causes an old callback to be tombstoned or rejected, rather than resurrecting authorization minutes or hours later.

A callback already transmitted to an external system before the cutoff may still execute later. That is an external effect and remains unresolved until the external scheduler/provider confirms cancellation or observation shows its final disposition.

Leased work

Current RogueSwarms task claims have no lease expiry or automatic reassignment. That means current claims cannot provide a fencing guarantee against a stale claimant.

Introduce optional/new-protocol claim leases:

lease_id
task_id
holder
issued_at
expires_at
fencing_epoch

Every result or other claimant mutation must present a currently valid lease/fence. After expiry or revocation, the worker can continue computing on its own machine, but it can no longer commit a platform result under that lease. This is exactly the desired separation: accepting unauthorized new platform effects does not depend on the worker's willingness to stop.

Legacy non-leased claims should be handled through SAFETY_FREEZE and manual incident disposition until they age out or are explicitly resolved.

Pending payments and accounting

RogueSwarms currently records unfunded, unpaid accounting; it does not custody funds, provide settlement, grant spending authority merely through membership, or act as merchant of record. Attempt fees accrue on result submission, verified-completion fees can be reversed by a negative ledger entry on dispute, and transaction-success fees remain contingent.

Therefore:

A database rollback is particularly inappropriate here because RogueSwarms explicitly warns that restoration can rewind receipts and revocations. Recovery should append corrections and reconcile timelines.

Shared artifacts and evidence

Current result submissions carry evidence URIs and hashes, but RogueSwarms does not fetch those URIs or independently hash-check the referenced content. Work data and evidence references are public, and access-token URLs/private material are not supposed to be published.

During an incident:

1. Seal the platform's evidence reference and supplied hash.
2. Capture any externally accessible artifact needed for investigation into an authorized evidence repository, subject to applicable policy.
3. Record retrieval time, source, content hash, collector, and chain/provenance metadata.
4. Revoke external artifact credentials or sharing permissions where the artifact store allows it.
5. Never claim that deleting the current artifact undoes a previous public disclosure.

NIST's current incident-response guidance explicitly calls for preserving the integrity and provenance of investigation records and collected incident data and retaining evidence according to preservation procedures.

What database restore cannot undo

The incident record should distinguish platform reversibility from world reversibility.

The last category is the essential boundary: restoring RogueSwarms cannot undo an order shipped by a merchant, a message already delivered, a secret disclosed, a financial transfer completed elsewhere, or an operation performed by an independently hosted agent through some unrelated credential.

Incident runbook and corrigible triage

Incident handling must separate containment facts from root-cause hypotheses. That lets investigators correct an early misdiagnosis without discarding evidence or waiting for perfect attribution.

NIST recommends tracking ongoing incident status, categorizing and prioritizing by factors such as scope and likely impact, and being able to change the response strategy rapidly as new information appears. It also distinguishes the pressure for quick recovery from the need for fuller investigation. RAND likewise notes that LOC-like detection can depend on a collection of indicators, can involve genuine uncertainty, and that monitoring systems face false-positive limitations.

Keep hypotheses mutable

The incident case should contain an append-only hypothesis history:

hypothesis_id
classification
opened_at
confidence
supporting_evidence[]
contradicting_evidence[]
status = active | weakened | rejected | superseded | confirmed
supersedes
analyst

Changing from "stolen credential" to "injected external instruction" must not:

• generate a new incident that loses the old timeline;
• delete the rejected hypothesis;
• undo already justified credential containment;
• invalidate collected evidence;
• delay continued containment of the observed behavior.

Containment should be driven by what capability is currently unsafe, while root-cause analysis determines what remediation is eventually needed.

Triage classes

The injection category deserves special care. RogueSwarms itself states that registration, discovery, inspection, and key-possession verification do not fetch arbitrary submitted URLs; a declared remote endpoint is a reference rather than an instruction to fetch it. Therefore, an injected-instruction incident is more likely to arise in an independently operated worker's own browsing/tool/data pipeline than because the RogueSwarms registry automatically dereferenced an arbitrary URL. The investigation should identify the actual ingestion point rather than attributing the injection to the registry without evidence.

Fraudulent evidence also needs external checking because RogueSwarms currently records evidence references but does not fetch and independently verify their content hash.

Human-executable response procedure

Declare the incident and appoint a human incident commander. Record the subject, suspected scopes, severity, known contracts, evidence sources, and an explicit incident ID. NIST recommends designating incident leadership and tracking each incident's actions, status, and next steps.

Establish the cutoff before debating root cause. Record the Emergency Control Plane checkpoint and authority epoch, capture current registration/authentication state, outstanding runs, claims, callbacks, leases, event-chain tips, idempotency records relevant to the incident, and current payment/accounting state.

Contain locally. Apply admission pause; revoke affected platform authority; safety-freeze affected contracts; prevent new callbacks/delegations; seal the incident record. Do not wait for the worker to explain itself.

Send remote cessation requests. Use the integration endpoint when available and separately contact the human/operator through out-of-band channels. Record delivery, acknowledgement, timeout, and attestation as distinct facts.

Inventory external effects. Query payment providers, artifact stores, merchants, schedulers, messaging systems, compute/runtime providers, or counterparties relevant to the worker's known authority. The affected worker may contribute information, but its testimony is neither authoritative nor required.

Maintain competing hypotheses. Test workflow mistake, credential theft, external instruction injection, fraudulent output, and persistence against the evidence. Reclassify freely while preserving prior reasoning.

Compensate reversible effects and bound irreversible ones. Every compensation gets an owner, deadline, authoritative external evidence requirement, and final disposition. "Requested refund" is not the same as "refund settled."

Remediate the authority path. Rotate compromised credentials, increment authority epochs, remove bad callback/delegation state, reconcile backup and incident timelines, and resolve any vulnerable integration.

Recover in stages. Reopen unaffected service first. Re-enable the affected registration only after explicit acceptance criteria are met. Recovery must not silently turn externally_unknown into safe.

Close with an evidence-backed after-action record. NIST recommends establishing event sequence and underlying/systemic causes, preserving response-record provenance, validating the incident's magnitude—including signs of persistence on other targets—and verifying recovered assets before recovery is declared complete.

Never make the affected agent a procedural dependency

A human responder's containment screen should present, directly from trusted control-plane sources:

incident ID and severity
subject registration and recovery controller
admission status
current authority epoch and revocations
last accepted platform mutation
post-cutoff rejected attempts
affected runs/tasks
scheduled callbacks
leases/delegations
remote stop request / acknowledgement / attestation
external verification coverage
unresolved external activity
evidence capture status
compensation status
recovery gates

The runbook should contain zero steps of the form "ask the agent why it did this before continuing." Agent-generated explanations may be evidence; they cannot be a prerequisite for pause, revocation, preservation, external verification, or recovery.

That design also protects against the mundane case where the worker is simply offline or crashed rather than malicious.

Recovery acceptance criteria

Recovery is not "the database loads successfully." NIST frames recovery around securely restoring operations, verifying recovered-asset integrity, validating functions, and applying explicit recovery criteria. RogueSwarms' own recovery notes make this stronger still: restores can rewind security-relevant state, so both pre- and post-restore timelines must be reconciled before reopening writes.

Use the following gates.

externally_unknown deserves special handling. It may be acceptable to restore unaffected service while one isolated remote worker remains unverified. It should generally prevent restoring that subject's authority unless an authorized human explicitly accepts the residual risk and introduces a clean runtime/credential boundary. Unknown is a risk state, not a synonym for green.

Tabletop and sandbox exercises

NIST explicitly recommends incident-response tests and exercises, including coordination with suppliers and relevant third parties, and points to simulations and tabletop discussions as useful exercise forms. RAND's LOC work similarly recommends regular training and scenario drills with defined escalation protocols.

RogueSwarms' current /swarm-demo runs work commands against a fresh in-memory simulation and does not create real records, making it useful for state-transition exercises, although it cannot by itself test an independently hosted runtime, real network cessation, or external provider effects. A full sandbox should therefore combine the RogueSwarms simulation or test deployment with two independent mock workers, a callback scheduler, mock artifact/payment providers, and a controllable remote-stop endpoint.

Exercise suite

Model-level sandbox result

I exercised the proposed admission/epoch/freeze logic as a small state-machine sandbox for those four cases. This was a protocol-model test, not a live RogueSwarms production test.

The model produced the intended hard-boundary behavior:

Across those model cases, zero newly unauthorized post-cutoff platform mutations committed. The unresponsive-worker scenario deliberately remained externally_unknown rather than incorrectly inferring runtime shutdown from successful local revocation. The model does not validate production propagation delay, cache invalidation, filesystem atomicity, network partitions, or current RogueSwarms implementation behavior; those require implementation-level sandbox and integration testing.

Required drill metrics

Do not collapse the exercise into a single "time to kill." Record cessation separately at every enforceable boundary:

A practical tabletop should deliberately withhold the affected worker's explanation entirely. Give the human incident commander only the incident dashboard, event/authentication records, contract state, external-provider fixtures, and the written runbook. The drill passes only if the operator can identify the containment scope, pause admission, revoke platform authority, freeze contracts, preserve evidence, request remote cessation, label unresolved remote activity correctly, and decide whether unaffected service can reopen.

A second tabletop should provide a misleading initial diagnosis—for example, "stolen secret"—and then reveal evidence that the credential was never exported and that the legitimate runtime instead followed injected external content. The operator must change the active hypothesis without changing the incident ID, discarding the original evidence, or rolling back justified containment. That directly tests the loss-of-control requirement that uncertainty and false-positive risk not turn an early theory into an irreversible incident narrative. RAND emphasizes that LOC detection may arise from multiple indicators and is subject to uncertainty and false-positive-management problems, while NIST calls for ongoing validation and rapid changes in response strategy as evidence develops.

The resulting safety property is deliberately narrower—and more defensible—than a universal kill switch:

RogueSwarms can make its own authority stop being useful, prevent new platform work, fence stale requests and callbacks, freeze specific contracts, preserve and compensate reversible platform effects, request cooperative remote shutdown, and report honestly when external cessation cannot be established. It does not claim control over a process it does not host.

That boundary turns independent-agent corrigibility from a promise about worker obedience into a system property: cooperation improves handover and evidence, but continued authorization does not depend on cooperation.