403 Forbidden for any request from a blocked agent.
How It Works
- You call
POST /agents/{id}/blockwith a reason. - The API writes the block to the database and publishes it to Redis.
- The proxy checks Redis on every incoming request — blocked agents get an immediate
403. - An
agent.blockedaudit event is emitted automatically. - To restore access, call
POST /agents/{id}/unblock— anagent.unblockedevent is emitted.
Block an Agent
Unblock an Agent
What the Agent Sees
When a blocked agent sends a request through the proxy, it receives:Audit Trail
Every block and unblock action emits an audit event:| Event Type | Description |
|---|---|
agent.blocked | Agent was blocked (includes reason and actor) |
agent.unblocked | Agent block was removed (includes actor) |
Enforcement Architecture
The kill switch uses Redis for sub-millisecond enforcement:- Write path: API writes block to PostgreSQL and publishes to Redis.
- Read path: Proxy checks Redis on every request (before policy evaluation).
- Fail-open: If Redis is unavailable, the proxy falls back to allowing the request (same as policy cache behavior).
- Latency: Block takes effect within milliseconds of the API call.
Use Cases
- Incident response — Immediately stop a compromised or malfunctioning agent.
- Cost containment — Block an agent that is burning through budget unexpectedly.
- Compliance — Emergency shutdown to satisfy regulatory requirements (EU AI Act Article 14).
- Anomaly response — Automated block triggered by anomaly detection (coming soon).

