How It Works
- An admin calls
POST /agents/{id}/quarantinewith a reason after identifying an unknown or suspicious agent. - The API marks the agent quarantined in the database and also writes a block to Redis for instant proxy enforcement.
- The proxy blocks all subsequent requests from the quarantined agent with
403 Forbidden. - An admin reviews the agent and calls
POST /agents/{id}/release-quarantineto restore access.
Quarantine is not applied automatically today - there is no auto-quarantine of newly discovered shadow agents. An admin decides to quarantine an agent explicitly.
Quarantine an Agent
Release from Quarantine
After reviewing a quarantined agent, release it to restore proxy access:List Quarantined Agents
What the Agent Sees
When a quarantined agent sends a request through the proxy:Audit Trail
Quarantine and release actions do not currently emit their own audit events. If you need a record of quarantine actions, track them through your own tooling around the API calls, or query the agent’s currentquarantine_reason via GET /agents/quarantined.
Enforcement Architecture
Quarantine uses the same Redis-backed enforcement as the kill switch:- Write path: API writes quarantine status to PostgreSQL and publishes a block to Redis.
- Read path: Proxy checks Redis on every request - quarantined agents get an immediate
403. - Fail-open: If Redis is unavailable, the proxy falls back to allowing the request.
- Latency: Quarantine takes effect within milliseconds of the API call.
Quarantine vs Kill Switch
Use Cases
- Shadow agent response - Quarantine agents you discover are not in the registry.
- Onboarding gate - Quarantine new agents until reviewed by security.
- Incident containment - Quarantine suspicious agents while investigating.
- Zero-trust enforcement - No agent gets proxy access without explicit registration and review.

