Approvals and Guardrails

Verdicts

Verdict	Effect
`ALLOW`	continue
`REQUIRE_APPROVAL`	poll for approval if `hitl_enabled`, otherwise follow fallback behavior
`BLOCK`	raise `GovernanceHaltError` at task boundary or `GovernanceBlockedError` at Layer 3
`HALT`	raise `GovernanceHaltError` and short-circuit future tasks on that agent

Class	When
`GovernanceHaltError`	`BLOCK` or `HALT` at governed task boundaries
`GovernanceBlockedError`	`BLOCK` or `HALT` at Layer 3 hooks
`GovernanceAPIError`	API failure with `governance_policy=fail_closed`
`GovernanceApprovalExpiredError`	approval window expired

When OpenBox returns REQUIRE_APPROVAL:

hitl_enabled=True — the SDK polls until the approval resolves
hitl_enabled=False — approval handling falls back to configured fallback behavior
exclude_crews_hitl — lets you disable approval polling for selected crews

OpenBox responses can include guardrail output that:

redacts activity_input before task execution
redacts activity_output before returning results
raises validation errors when the payload is rejected and no redacted fallback is provided

Policy runs before guardrails. If policy already returns a non-ALLOW verdict, guardrails for that same event may not run.

If a guardrail you expect does not fire:

CrewAI may swallow GovernanceBlockedError raised from inside a tool path and surface a later ValueError from the before-LLM-call hook instead.

If you want a cleaner task-boundary failure:

Boundary	Match against
`ActivityStarted`	`input.activity_input[*].description`
`ActivityCompleted`	`input.activity_output.result`
DB hook	`input.spans[*].attributes["db.operation"]`
File hook	`input.spans[*].name == "file.write"` plus file path