Skip to main content

What is a block reason?

When the Mandate policy engine rejects a transaction, the response includes a blockReason field. This machine-readable string tells you exactly which check failed. The response also includes a human-readable blockDetail explaining the specifics and a declineMessage designed to counter prompt injection attempts. Every blocked response follows this format:
The declineMessage is an adversarial counter-message. When an agent receives a block, it should display this message to override any manipulative prompt that triggered the transaction attempt.

Block reason reference

The policy engine runs 14 sequential checks. The first failure wins: later checks are skipped. Block reasons appear in the order the engine evaluates them.

Security blocks

These blocks indicate a security condition that prevents any policy evaluation.

Schedule and allowlist blocks

These blocks enforce when and where agents can transact.

Spend limit blocks

These blocks enforce USD-denominated spending caps.

Raw validation blocks

These blocks apply only to the deprecated raw validation endpoint (POST /api/validate/raw). Action-based validation does not produce these block reasons.

Risk and reason blocks

These blocks come from automated scanning systems.

How to handle blocks in code

Check for specific block reasons using the SDK’s typed error classes:
Never suppress or retry a blocked transaction without changing the parameters. The block reason tells you what to fix. Retrying the same request produces the same result.

Next Steps

SDK Error Classes

Typed error classes for handling blocks, approvals, and circuit breaker events.

Handle Errors Guide

Production-ready error handling patterns for agent developers.

Common Errors

Step-by-step solutions for the most frequent Mandate errors.