Runtime action grounding for AI agents
ActionRail is an open-source project by ToolJet. It verifies consequential AI agent actions against deterministic rules and live trusted systems before the underlying tool runs.
ActionRail is currently in public beta. Interfaces may evolve before the ActionRail v1 release, which is planned for August 2026.
An agent can propose issue_refund(customer_id="cus_123", amount=480). ActionRail independently checks whether that amount is within policy, whether the customer exists, and whether the customer belongs to the authenticated caller. Only then does it return a decision.
The problem it solves
Models are good at deciding what they want to do. They are not an authority on whether a real-world action is permitted or grounded in current facts.
Prompt instructions, output validators, and model-based guardrails can shape a response. They cannot prove that a refund belongs to the signed-in customer, that an account is still active, or that a deployment target is approved at the moment the tool runs.
ActionRail places a deterministic gate at that boundary.
The same action behavior can be committed as Action Tests: versioned cases
that declare a proposed tool call, trusted context, simulated Source records,
and the required allow, hold, or block. They run through the production
decision pipeline without a model, Console, or live Source, so rule changes can
be reviewed and enforced in CI. See Action Tests.
What ActionRail protects
ActionRail is designed for consequential tools: calls that create material effects outside the agent process.
Common examples include:
- moving money, issuing credits, or changing subscriptions;
- sending messages or publishing content;
- modifying customer, billing, or identity records;
- running infrastructure operations;
- approving, deleting, or provisioning resources.
Read-only retrieval tools can remain outside the gate. You explicitly choose which tools are consequential and attach rules to their critical arguments.
A tool without a rule is allowed through unchanged. ActionRail does not infer production policy from a tool name. Treat uncovered consequential tools as a configuration gap and monitor coverage in the Console.
The three outcomes
| Outcome | Meaning | Runtime behavior |
|---|---|---|
| Allow | Every required rule and live check passed. | The underlying tool executes. |
| Hold | The action requires a human decision. | Execution pauses until review succeeds or times out. |
| Block | A required check failed or the runtime cannot establish a safe decision. | The underlying tool does not run. |
When checks disagree, the strictest outcome wins: block → hold → allow.
Where it runs
The ActionRail SDK runs inside the customer’s agent or application process. It evaluates policy locally and connects directly to configured Sources such as Postgres, MySQL, an internal HTTP API, or an MCP gateway.
The Console distributes configuration and displays operational metadata. It is not a proxy for tool calls or Source traffic.
You can operate ActionRail in two ways:
- Local configuration — load rules and Source definitions from the application. No Console is required.
- Console-managed configuration — register an agent, fetch versioned configuration, report decisions, and enable human review.
Those configuration modes work with both integration styles: use
ActionRuntime around an explicitly named Python operation, or use the
LangGraph adapter for automatic tool discovery and wrapping.
Continue with the mental model, learn the canonical terminology, or inspect the architecture and trust boundaries.