Adrian is intended to be a security guard, not an operational dependency. The default is fail-open. If something on Adrian’s side breaks, your agent keeps running. A small set of cases fail-closed with a syntheticDocumentation Index
Fetch the complete documentation index at: https://docs.adrian.secureagentics.ai/llms.txt
Use this file to discover all available pages before exploring further.
[BLOCKED by security policy] ToolMessage substituted in, where letting the action through would defeat the security guarantee.
Verdict timeout
In Block mode the SDK waits up toblock_timeout (default 30.0s, env ADRIAN_BLOCK_TIMEOUT) for a verdict before letting a tool run. On timeout the SDK fails open, logs verdict timeout for tool_call_id=…, fail-open at WARN, and runs the original tool.
Alert mode never waits. Human Review waits indefinitely; resolution comes from the dashboard reviewer or a process exit. There is no timeout-driven fail-open in Human Review.
Classifier failure
If Adrian’s classifier can’t return a verdict (a connectivity issue, an upstream error, or an output we can’t parse), Adrian never fabricates a synthetic one. Brief blips are retried in place and almost always resolve in under a second. Persistent failures are handled by Adrian’s resilient architecture: events are redelivered on a backoff schedule and, only as a last resort, set aside for operator review. Unrecognised classification codes are dropped rather than guessed at. From your agent’s perspective the failure is invisible. In Alert mode the agent runs to completion as normal. In Block mode the SDK waits up toblock_timeout (30s by default), then proceeds with a warning. In Human Review mode it waits for a human reviewer to step in. Every failure is observable on Adrian’s side: retries are logged, retired events are counted, and missing verdicts show up as gaps on the dashboard, so issues stay visible to operators without ever being charged to your agent.
First tool call before LoginAck (cold start)
The SDK only knows the agent profile’s policy mode after the server’sLoginAck arrives. If a tool call happens before that, the SDK waits up to 5 seconds. If LoginAck doesn’t arrive, the SDK fails closed with [BLOCKED by security policy] and logs WARN: ToolNode: LoginAck not received within 5s; halting.
This halt is SDK-local. No verdict frame is sent, no database row is written, no
on_verdict / on_block callback fires, and the dashboard event feed shows nothing for it. The only trace is the SDK’s WARN log. Worth knowing if you’re investigating a blocked tool call and can’t find a corresponding event in the dashboard.Other behaviour
| Case | Posture |
|---|---|
| WS disconnect mid-wait | Verdict futures persist across reconnect; resolved by replay or fail-open at timeout |
| Reconnect | Exponential backoff 1s to 30s cap; 10s ping / 15s pong heartbeat |
| Server close 4003 (quota exhausted) | Reconnect delayed 60s |
| Server close 4401 (API key revoked) | WS dropped; reconnect handshake fails 401 until a new key is configured |
| Replay buffer overflow (default 1000 frames) | FIFO eviction; one-shot WARN at first overflow, cumulative drop count logged on next reconnect |
| Tool call with no producing LLM | Fail-open; tool runs (no tool_call_id to correlate against) |
| Human Review reviewer rejects | Halt with [BLOCKED by security policy] |
| Human Review SDK restart while review is pending | Late resolution dropped on arrival; audit trail in dashboard survives |