진짜 킬 스위치는 에이전트의 추론 바깥에 존재합니다. 한 번의 호출로, 해당 에이전트에 대한 이후 모든 결정 검사가 정책 계층에서 deny를 반환하게 됩니다 — 에이전트의 프롬프트가 무엇이라고 말하든 관계없습니다. 이것은 모델이 무시하거나, 반박하거나, 교묘한 입력으로 설득당해 벗어날 수 있는 "제발 멈춰"라는 지시가 아닙니다. 모델이 절대 볼 수 없는 플래그이며, 모델에게 발언권이 없는 계층에서 검사됩니다.
"에이전트에게 멈추라고 지시하는 시스템 메시지를 추가하라"는 것이 본능적인 첫 번째 답이지만, 그것은 잘못된 계층입니다. 시스템 프롬프트는 모델이 주의를 두고 경쟁하는 다른 모든 지시와 나란히 해석하는 하나의 지시일 뿐입니다 — 성공한 프롬프트 인젝션, 새 지시를 더 이상 읽지 않는 멈춰버린 에이전틱 루프, 또는 컨텍스트 앞쪽에 묻힌 지시의 우선순위를 단순히 낮추는 모델을 포함해서입니다. 이러한 실패 모드 중 어느 것도 가정이 아닙니다. 바로 킬 스위치가 존재하는 이유가 되는 정확한 시나리오들입니다. 에이전트를 멈추기 위해 의존하는 메커니즘이 현재 오작동하고 있는 것과 동일한 추론 프로세스 내부에 있다면, 그것은 통제가 아닙니다. 제안일 뿐입니다.
권한 guard.killswitch.write 을 가진 운영자가 이유와 함께 POST /v1/suite/guard/kill/{agent_id} 을 호출합니다. 이렇게 하면 에이전트의 레코드에 is_killed = true 이 설정됩니다 — 그 이상도 이하도 아니며, 에이전트 자체의 프로세스는 여기에 전혀 관여하지 않습니다.
POST /v1/decisions/check 은 다른 어떤 분기보다 먼저 킬 플래그를 평가합니다. 이후의 모든 요청은 deny 와 함께 reason_code: "agent_killed" 이 반환됩니다. 에이전트가 어떤 행동을 시도하고 있었는지와 무관합니다.
킬된 에이전트는 새로운 이동 가능한 신뢰 자격 증명을 발급할 수 없습니다. POST /v1/credentials/issue 은 is_killed 을 확인하는 순간, 다른 무엇이 실행되기도 전에 403을 반환합니다.
Vault 원장 항목(agent.killed), 표준 감사 로그 행, 그리고 위험 심각도의 워크스페이스 알림이 킬 시점에 모두 기록됩니다 — 에이전트 자체와 무관하게 누가, 언제, 왜 그랬는지에 대한 기록이 남습니다.
POST /v1/suite/guard/unkill/{agent_id} 은 플래그를 지우고 정상적인 결정 검사와 자격 증명 발급을 복원합니다. 에이전트를 킬해도 신뢰 점수 이력에는 영향을 주지 않습니다 — 이는 별도로 감사 로그에 기록되는 운영자 작업입니다.
경계에 대해 정확히 짚어봅시다. 킬 스위치는 VeriSwarm에 허가를 요청하는 모든 체크포인트에서 거부합니다 — 결정 검사, 자격 증명 요청, 킬된 에이전트로 향하거나 그로부터 오는 A2A 작업 인계입니다. 에이전트 자체의 런타임에 들어가 작업 도중 실행을 멈추게 할 수는 없으며, 에이전트가 이미 보유하고 있어 VeriSwarm에 먼저 확인하지 않는 시스템에 여전히 제시할 수 있는 자격 증명을 취소할 수도 없습니다. 그래서 이것은 여섯 가지 중 하나의 통제이며, 다른 통제를 대체하지 않습니다 — 최소 권한 도구 권한과 PII 토큰화는 누군가 킬 스위치에 손을 대기도 전에 에이전트가 잘못할 수 있는 것을 줄여 줍니다. 여섯 가지 통제 전체 체크리스트 보기.
킬 스위치를 활성화하거나 되돌리려면 guard.killswitch.write 권한을 가진 세션 토큰이 필요하며, 이는 super_admin, platform_admin, tenant_admin, 그리고 operator 역할이 보유하고 있습니다. 이는 의도적으로 에이전트 자체의 API 키로는 접근할 수 없습니다. 손상된 에이전트, 또는 나쁜 행동을 향해 추론해 나가는 에이전트는 스스로를 킬하거나 킬 해제할 수 없습니다. 통제는 반드시 외부에서 와야 합니다.
운영자가 발동하는 오버라이드로, 에이전트 자체의 코드 경로나 협조에 의존하지 않고 특정 에이전트의 행동 능력을 즉시 차단합니다. VeriSwarm에서는 한 번의 호출 — POST /v1/suite/guard/kill/{agent_id} — 이 에이전트 레코드의 플래그를 전환합니다. 그 시점부터 해당 에이전트에 대한 모든 신뢰 결정 검사(POST /v1/decisions/check)는 reason_code: "agent_killed"와 함께 deny를 반환하며, 해당 에이전트에 대한 새 자격 증명 발급은 아예 거부됩니다. 되돌릴 수 있습니다. 킬 해제 호출(POST /v1/suite/guard/unkill/{agent_id})이 정상 동작을 복원합니다.
네 — 시스템 프롬프트 지시는 모델이 설득당해 벗어날 수 있는 요청일 뿐입니다. 그것이 핵심적인 차이입니다. 진짜 킬 스위치는 에이전트에게 멈추라고 요청하지 않습니다. 대신 에이전트가 행동을 시도할 때 일어나는 일 자체를 바꿉니다. 검사는 모델 자체의 추론 루프 바깥, 결정 계층에서 일어나므로, 성공한 프롬프트 인젝션, 멈춰버린 에이전틱 루프, 또는 모델이 단순히 이전 지시를 무시하는 것 모두 상관없습니다 — 다음 결정 검사는 어쨌든 거부되어 돌아옵니다.
실시간 결정 경로에 대해 확인된 세 가지입니다. 해당 에이전트에 대한 POST /v1/decisions/check로의 이후 모든 호출은 deny를 반환합니다(decision_preview.py는 다른 어떤 분기보다 먼저 agent.is_killed를 확인합니다). 해당 에이전트를 위한 새로운 이동 가능한 자격 증명 발급은 403으로 거부됩니다(routes/credentials.py). 그리고 VeriSwarm의 A2A 프로토콜과 JIT 접근 검사가 관련된 경우, 다른 에이전트가 킬된 에이전트에게 작업을 넘기거나 접근 권한을 부여하려는 시도 또한 차단됩니다. 하지 않는 것은 에이전트 자체의 프로세스에 들어가 실행 도중에 멈추게 하는 것입니다 — 다음 답변을 참조하세요.
아니요, 그리고 이것이 결정 계층 킬 스위치의 정직한 한계입니다. VeriSwarm에 허가를 요청하는 이후의 모든 체크포인트에서 거부합니다 — 결정, 자격 증명 발급, A2A 작업 인계입니다. 에이전트가 이미 발급받아 다른 곳에서 사용할 수 있는 자격 증명을 가지고 있거나, 행동하기 전에 VeriSwarm을 확인하지 않는 시스템에서 작동하는 경우, VeriSwarm에서 킬해도 그 경로에는 도달하지 못합니다. 킬 스위치는 행동하기 전에 결정을 확인하는 에이전트를 위한 정책 계층 통제입니다 — 바로 그렇기 때문에 보안 체크리스트의 통제 #2(최소 권한 도구 권한)와 통제 #4(인젝션 스캐닝)가 킬 스위치의 백업으로서가 아니라, 킬 스위치에 손을 대야 하기 전에 에이전트가 잘못할 수 있는 것을 줄이는 통제로서 독립적으로 중요한 것입니다.
아니요 — 활성화하거나 되돌리려면 guard.killswitch.write 권한을 가진 세션 토큰이 필요하며, 이는 전체 액세스 역할(super_admin, platform_admin, tenant_admin, operator)이 보유하고 있습니다. 이는 설계상 에이전트 자체의 API 키에는 노출되지 않습니다. 손상된 에이전트 — 또는 그것을 손상시킨 무언가는 — 흔적을 지우기 위해 스스로를 킬할 수 없으며, 스스로를 킬 해제할 수도 없습니다.
킬 스위치는 VeriSwarm Guard의 일부이며, Max 요금제 기능입니다. Vault가 활성화되어 있으면 모든 활성화와 되돌림은 불변의 Vault 원장 항목(agent.killed / agent.unkilled)을 기록하며, 여기에 표준 감사 로그 항목과 위험 심각도의 워크스페이스 알림도 더해집니다 — 그래서 에이전트 자체가 보고하는 것과 무관하게 누가, 언제, 왜 그 에이전트를 킬했는지에 대한 기록이 남습니다.
킬 스위치는 Max 요금제의 Guard 기능입니다. Gate의 무료 등급은 먼저 그것이 연결되는 결정 계층과 이벤트 가시성을 제공합니다.