Runtime evaluation & policy
The allow, block, and approve decision model
Every pre-action evaluation resolves to allow, block, or require approval—implement each path cleanly with Auctra evaluateAction in production agents.
May 13, 2026 · 7 min read · Markdown version
Allow path
Allow means active delegation and policies permit the action as submitted. Return a decision ID agents attach to downstream API calls for correlation.
Auctra allowed responses are idempotent when callers pass a stable idempotencyKey as the second SDK option. Log action_request_id for correlation without flooding on-call.
Block path
Block when authority is missing, expired, over limit without override, or forbidden by policy. Include machine-readable reason codes and human-readable messages for support teams.
Agents should translate blocks into user-visible guidance when appropriate. Never retry blocked monetary actions without changed inputs or new delegation.
Approve path
A require_approval decision holds execution until a reviewer decides in the console. Use the action_request_id to correlate that review with your workflow.
Denied approvals should be auditable and visible to sponsors for pattern analysis. High denial rates often signal mis-tuned limits rather than malice.
Unified handling in code
Wrap evaluateAction in a single handler that branches on the decision values allowed, blocked, and require_approval. Share the handler across LangChain tools, MCP handlers, and batch jobs.
Auctra ties sponsors, expiring delegations, and pre-action evaluation into one accountability chain your security and finance teams can audit.
Key takeaways
- Authority is enforced before side effects — use Authority policies and evaluateAction together.
- Every production agent needs a named sponsor and bounded delegation visible in the console.
- Blocked and approval-required outcomes are evidence, not failures — review them in Authority policies.
Implementation checklist
- Sign up at console.auctra.tech and open Authority policies (/console/policies).
- Register one agent with a named human sponsor accountable for its actions.
- Create a narrow delegation aligned with this article's workflow (The allow, block, and approve decision model).
- Call evaluateAction from your agent or SDK before the consequential tool executes.
- Confirm sponsor, delegator, decision, and outcome appear in Audit or Authority policies.
People also ask
- What are the outcomes of pre-action evaluation?
- allowed (proceed), blocked (deny), or require_approval (wait for human review).
- Should blocked agent actions be retried automatically?
- Only after fixing inputs, renewing delegation, or receiving approval—not blindly on timeout.
- How does Auctra help with agent authority?
- Auctra registers sponsors, issues expiring delegations, evaluates actions before execution, and preserves auditable accountability records.
Try in Auctra Console
Maps to: Authority policies
Pilot runtime decisions in Auctra Console
Use Authority policies to apply this guide — register an agent, delegate authority, evaluate one real action, and inspect the audit trail. Free on Builder.
- Create a free account: https://console.auctra.tech/auth/signup?utm_source=blog&utm_medium=cta&utm_campaign=allow-block-approve-decision-model
- In Authority policies (https://console.auctra.tech/console/policies), run a free Builder pilot for one production workflow.
- Issue a bounded delegation with limits and expiration matching this guide.
- Integrate evaluateAction (SDK or REST) before money, data, or infrastructure changes execute.
- Open Audit to verify sponsor, delegator, reviewer, and decision are recorded.
Part of guide
Runtime evaluation & policy
Pre-action gates, policy engines, approval routing, and the difference between observing agents and governing side effects.
Browse full guide →Related guides
Make authority executable.
Evaluate agent actions against bounded, expiring delegation before they reach the real world. Start free on Builder — upgrade when audit retention and accountability matter.
Auctra