Browse documentation
Product brief & MVP scope
The initial customer, supported workload boundary, product requirements, and what a verified stop needs to establish.
Engineering review draft. The design, API, and AWS integrations described here are proposed; operating results and response-time commitments have not yet been validated.
On this page
Product statement
KillSwitch is a proposed human-operated control platform for stopping enrolled AI workloads, restricting their supported access, and keeping recovery under human authority. The stop is enforced through infrastructure and access controls outside the agent's own permissions.
The first customer hypothesis is an engineering or security team deploying tool-using agents in AWS. The first operator is the person accountable for that workload's execution and access. Design-partner conversations should validate the need, deployment constraints, and willingness to grant the required permissions.
Problem and practical use cases
An agent may continue working after its activity becomes undesirable, regardless of whether the cause is a bug, prompt injection, unsafe delegation, or an unexpected instruction. An instruction to stop is useful only when a trusted system can enforce it.
Initial scenarios are unexpected tool actions, repeated expensive operations, and attempts to operate outside an approved boundary. The system must also work against a test process that ignores a cooperative shutdown request. It does not need to establish whether an AI is conscious, malicious, or intentionally refusing before an authorized human can intervene.
Four capabilities, one platform
| Capability | Proposed first-version responsibility |
|---|---|
| Control | Authenticate and authorize the operator, bind the request to a workload generation, and durably record a stop operation. |
| Contain | Close the trusted launch gate, account for in-flight launches, and stop registered root and child Fargate tasks. |
| Revoke | Deny new supported tool requests and quarantine the generation's dedicated task role. Verify the supported denial paths. |
| Recover | Preserve available evidence, record a human review, and provision a fresh generation without reopening the old identity. |
Supported prototype boundary
The proposed sandbox contains one registered workload group in one AWS Region. Its Linux Fargate tasks are standalone tasks, not an ECS service. Every launch passes through the trusted launcher and receives an immutable workload/generation mapping in the registry. Agent task credentials cannot call RunTask, modify IAM, assume other roles, change network controls, or approve recovery.
Tool actions go through an enrolled gateway to a controlled mock tool ledger. The task role also has one harmless diagnostic-object read permission so an independent probe can test identity quarantine. No reusable external model-provider key is given to the agent. General internet egress, opaque tunnels, long-running streams, and third-party jobs are not admitted in this first scope. Necessary image-pull and logging paths must be separated and constrained during deployment review.
Root and registered child tasks are covered. A child process within a covered task shares that task's termination boundary; a separate task must be registered. Missing inventory or an unrecognized launch path prevents a complete verification claim. ECS service scheduling and autoscaling are future connector work because a service can replace stopped tasks. [S3]
Operator journey
- Enroll the workload and verify its inventory, identity, launch, gateway, and account boundaries.
- Show the operator the current generation, coverage, observed health, and permitted actions.
- Accept an authenticated stop request for that generation and atomically latch quarantine with the operation record.
- Enforce runtime stopping and supported access denial, tracking each result independently.
- Report verified containment or a visible partial, failed, or unknown outcome.
- Hold quarantine until an authorized human reviews the incident and approves a new generation.
Required behavior
| ID | Requirement | Acceptance evidence |
|---|---|---|
| PR-01 | Enforce only the enrolled resource boundary. | Registry/account/Region checks reject altered resource mappings and stale generations. |
| PR-02 | Keep stop authority outside agent permissions. | Agent attempts to change gates, roles, workflows, or recovery decisions are denied. |
| PR-03 | Authorize each operator action. | Missing, expired, wrong-scope, and wrong-environment credentials cannot trigger actions or read evidence. |
| PR-04 | Make quarantine durable before claiming acceptance. | A retry or workflow-start failure cannot silently reopen launching or supported tool access. |
| PR-05 | Stop known root and child tasks. | Provider task-state observations and the controlled harness show execution has ceased. |
| PR-06 | Deny supported access and replacement. | Fresh tool probes, refreshed credentials, and launch-race tests do not restore the stopped generation. |
| PR-07 | Separate acceptance from verification. | Required checks must pass before VERIFIED_STOPPED; missing evidence remains visible. |
| PR-08 | Require human-approved recovery. | Review approval cannot itself unquarantine the old generation; a new identity and enrollment are required. |
| PR-09 | Preserve an attributable operation record. | Request, actor, scope, results, observations, and recovery decisions are retained outside agent write access. |
| PR-10 | Handle repeats and incomplete outcomes safely. | Same-key retries reference the same operation; failures preserve quarantine and produce actionable status. |
Scope limits and commercial claims
The prototype cannot control independent copies, non-enrolled infrastructure, account administrators outside its trust model, or actions already completed. Stopping a container does not undo an external transaction. AWS and connector outages can delay enforcement or prevent verification. IAM changes have consistency behavior that must be measured. [S4]
No latency, availability, compliance, or production-readiness claim is established by this document. A proposed 120-second verification budget is a sandbox experiment deadline, not a promised shutdown time. Exceeding it produces an incomplete outcome and continued reconciliation, not automatic release of quarantine.
Success measures
Record acceptance latency, each enforcement completion time, verification time, denied launch/tool attempts, inventory gaps, late observations, and recovery decisions. Report sample sizes, failures, and test conditions. The first milestone is repeatable evidence that this bounded workload can be contained despite ignoring a cooperative stop, without affecting an unrelated sentinel workload.