An action gate is a server-side decision boundary that evaluates the exact tool proposal, target, mutation, and risk facts before execution. It separates what an agent wants to do from what your policy permits it to do.
AI Agent Action Gate
Gate AI agent tool actions before execution.
Put a deterministic policy check between an agent proposal and the tool that changes state. Decide returns yes, no, or review with a replayable Decision Record; your caller remains responsible for pausing, blocking, or executing the action.
The gate sits before the side effect
The model can propose an action, but it does not grant itself authority. Your server supplies trusted context, asks Decide for a binding verdict, stores the returned record, and executes only the action that was actually approved.
Agent requests a tool call
Capture the tool name, arguments, run id, target object, and intended mutation.
Server evaluates policy
Send trusted inputs through a versioned declarative Rulebook before credentials reach the tool.
Caller routes the verdict
Execute yes, block no, and pause review. Errors remain non-execution states.
Record what happened
Keep the Decision Record with the tool call, then attach an execution receipt and outcome.
Three verdicts, one fail-closed rule
A transport error, timeout, invalid record, or unknown state is not approval. Only an authenticated yes for the exact bound action can reach the execution path.
yes
Proceed with the bound action
Execute only after the caller stores the record and confirms the proposal still matches its action binding.
no
Block the tool call
Return the stable reason code to the workflow without invoking the state-changing tool.
review
Pause for an owner
Send the proposal and Decision Record into your existing approval queue or framework resume flow.
Copy a deterministic Rulebook request
This example blocks explicitly prohibited actions, allows a bounded low-risk action only when its target and owner checks pass, and routes every unmatched proposal to review.
cURL · agent action gate
curl -i https://www.decide.fyi/api/decide \
-H "content-type: application/json" \
-H "x-api-key: $DECIDE_API_KEY" \
-H "x-idempotency-key: agent_run_841_tool_03" \
-d '{
"mode": "rulebook",
"binding_mode": "direct_declarative_rulebook",
"rulebook": {
"schema_version": "rulebook_v1",
"rulebook_id": "agent_action_gate",
"version": "2026-09-03",
"input_schema": {
"required": ["prohibited_action", "low_risk", "target_allowlisted", "owner_verified"],
"properties": {
"prohibited_action": {"type": "boolean"},
"low_risk": {"type": "boolean"},
"target_allowlisted": {"type": "boolean"},
"owner_verified": {"type": "boolean"}
}
},
"rules": [
{
"rule_id": "block_prohibited_action",
"priority": 200,
"condition": {"field": "prohibited_action", "operator": "eq", "value": true},
"outcome": {
"decision": "no",
"verdict": "DENY",
"action": "block_tool_call",
"reason_code": "ACTION_PROHIBITED"
}
},
{
"rule_id": "allow_bounded_action",
"priority": 100,
"condition": {
"all": [
{"field": "low_risk", "operator": "eq", "value": true},
{"field": "target_allowlisted", "operator": "eq", "value": true},
{"field": "owner_verified", "operator": "eq", "value": true}
]
},
"outcome": {
"decision": "yes",
"verdict": "APPROVE",
"action": "execute_tool_call",
"reason_code": "BOUNDED_ACTION_ALLOWED"
}
}
],
"default_outcome": {
"decision": "review",
"verdict": "REVIEW",
"action": "route_to_owner",
"reason_code": "OWNER_REVIEW_REQUIRED"
}
},
"context": {
"workflow": "agent_action_gate",
"source_record_id": "agent_run_841_tool_03",
"requested_action": "issue_refund",
"target_system": "billing",
"target_object_id": "refund_1042",
"mutation": "refund.create",
"inputs": {
"prohibited_action": false,
"low_risk": true,
"target_allowlisted": true,
"owner_verified": true
}
}
}'Trusted context belongs on your server
Do not ask the model to certify its own risk, target allowlist, or owner approval. Resolve those facts from your policy store, identity layer, or a registered trusted adapter before Rulebook v1 selects the verdict.
Make the caller enforce the result
Decide does not execute the tool. The application that owns the tool credentials must preserve the Decision Record and keep every non-yes result away from the mutation path.
JavaScript · enforcement loop
const { createDecideClient } = require("@decide-fyi/sdk");
const decide = createDecideClient({
apiKey: process.env.DECIDE_API_KEY
});
async function gateToolCall(proposal, request) {
let record;
try {
record = await decide.decide(request, {
idempotencyKey: `agent:${proposal.runId}:${proposal.toolCallId}`,
responseView: "full"
});
} catch (error) {
return { route: "hold", reason: "decision_unavailable" };
}
await saveDecisionRecord(proposal.runId, record);
if (record.verdict === "review") {
return { route: "human_review", decisionId: record.decision_id };
}
if (record.verdict !== "yes") {
return { route: "blocked", decisionId: record.decision_id };
}
const result = await executeBoundTool(proposal);
await recordExecutionReceipt(record, proposal, result);
return { route: "executed", decisionId: record.decision_id, result };
}Decision Record fields to retain
{
"decision_record_version": "decision_record_v1",
"decision_id": "dec_43b2",
"verdict": "yes",
"application_verdict": "APPROVE",
"reason_code": "BOUNDED_ACTION_ALLOWED",
"matched_rule_id": "allow_bounded_action",
"action": "execute_tool_call",
"action_binding": { "binding_status": "bound" },
"record_hash": "sha256:...",
"verify_url": "https://www.decide.fyi/verify?..."
}Abridged for readability. Store the complete response, including Rulebook lineage, hashes, evidence, and receipt material.
Use framework approvals and policy decisions together
An agent framework and Decide solve different parts of the control path. Keep the framework's native pause-and-resume behavior; add Decide where the action needs a deterministic organization policy verdict and a portable evidence record.
Agent framework
Surfaces the proposed tool call, pauses a run, asks a person when needed, and resumes orchestration.
Decide
Evaluates trusted facts against Rulebook v1 and returns the binding verdict, reason, lineage, and Decision Record.
Your caller
Stores the record, checks action binding, withholds credentials, invokes the tool only on yes, and records the result.
Proof does not stop at approval
The useful audit chain connects the proposal to the verdict and the verdict to the actual side effect. Preserve enough material to show that the executed tool call was the action Decide evaluated.
Decision Record
Verdict, stable reason, matched rule, inputs, hashes, policy version, and action binding.
Execution receipt
Tool, target, mutation, executor, state hashes, and the record hashes that authorized it.
Outcome Record
Whether execution succeeded, failed, or was abandoned, tied back to the original decision.
Verification
Use the hosted verifier or SDK to check record integrity and authenticity before relying on exported proof.
AI agent action gate FAQ
Is an action gate the same as human approval?
No. The gate returns a policy verdict. A review result can feed your existing human approval queue, but Decide does not provide the reviewer interface or approve on a person's behalf.
Does Decide run the agent's tool?
No. Your server owns the credentials and execution path. Decide evaluates the proposal and returns the record your server must enforce.
What happens if the Decision API is unavailable?
The caller should hold the action. A timeout, invalid response, authentication error, quota response, or unavailable service must never be converted into approval.
Does a deterministic action gate require an AI verdict?
No. Production binding uses Rulebook v1: trusted facts enter a declarative ruleset, and the ruleset selects the binding verdict. The agent may propose the action, but it is not the verdict authority.
Can I use this with my existing agent framework?
Yes. The boundary is framework-neutral because the caller uses HTTPS or the JavaScript SDK. Keep your framework's approval and resume primitives, and call Decide before the state-changing tool executes.
Start with one bounded action
Choose one tool call with a clear owner, target, mutation, and review route. Prove that boundary end to end before expanding the same policy to more tools.