update · TowCue Editorial Team
UiPath adds LLM as Judge guardrails: when natural-language checks help AI agents
UiPath released an LLM as Judge guardrail in preview on September 7, 2026. Here is how it works, where it adds value, what it costs, and why it should complement rather than replace deterministic controls.
Quick answer
UiPath released a new LLM as Judge guardrail in preview on September 7, 2026 for Agents in Automation Cloud and Test Cloud.
Instead of checking only a fixed category such as a predefined policy violation, the new guardrail lets teams write a rule in plain natural language and ask another LLM to evaluate an agent prompt, response, or LLM call against that rule. That makes the control layer much more flexible for organization-specific policies that are difficult to express with simple keywords or fixed classifiers.
The important tradeoff is cost and reliability. UiPath states that every Judge check makes a real LLM call, so it consumes Agent Units or Platform Units on top of the agent's own usage. An LLM judge is also probabilistic: it can interpret nuanced instructions, but it should not be treated like a deterministic permission boundary.
TowCue's view: use LLM-as-judge checks for semantic quality and policy interpretation, while keeping authentication, authorization, irreversible actions, hard data-loss-prevention rules, and financial limits behind deterministic controls and human approval.
For a broader deployment framework, pair this with TowCue's AI agent best-practices guide, AI tool selection guide, and tool finder.
What UiPath released
UiPath's September 7 release notes describe LLM as Judge as a built-in guardrail that can evaluate:
- an agent prompt before or after execution
- an agent response
- an LLM call inside an agent workflow
- custom policy instructions written in natural language
The key difference from fixed-category guardrails is that the Judge can interpret a policy that is specific to your workflow.
A support team, for example, might write a rule such as: "Reject responses that promise a refund unless the record contains an approved refund status." A procurement team might ask the Judge to flag a response that recommends a vendor without citing the approved vendor list. A regulated workflow might ask the Judge to detect when the response sounds more certain than the evidence supports.
Those are semantic checks. They depend on context, intent, and meaning rather than a single forbidden word.
Why this matters for production agents
As agents move from chat into operational workflows, a simple content filter is often not enough.
Real policies frequently look like this:
- Do not claim that an external action succeeded unless the tool returned a success result.
- Escalate when the user's request conflicts with a policy stored in the case record.
- Do not summarize a customer as eligible unless all required fields are present.
- Block a final answer if it contains an unsupported number or an uncited recommendation.
A conventional classifier can handle narrow categories, but it struggles when the rule depends on several pieces of context at once.
An LLM judge can evaluate that richer situation. This makes it useful as a semantic checkpoint between an agent's reasoning and a business outcome.
UiPath also supports guardrails at organization-wide and per-agent levels, so teams can combine a central policy baseline with workflow-specific checks. Its Agent Instance Management view exposes guardrail activity, including whether a guardrail runs pre- or post-execution and whether the resulting action was Block, Escalate, Filter, or Log.
The hidden cost: every Judge check is another model call
UiPath explicitly says that each LLM as Judge evaluation makes a real LLM call and consumes additional Agent Units or Platform Units. This remains true when the guardrail runs during agent evaluation.
That means a workflow with one main agent call and three Judge checkpoints is not economically equivalent to a workflow with one main call and no semantic guardrails.
The exact unit consumption depends on UiPath's licensing model and the model tier involved. For UiPath-hosted models, current documentation says consumption is generally calculated per LLM call, with different rates for basic, standard, and premium tiers. UiPath also notes that hosted-model calls are metered in 64K input-token increments, so a sufficiently large context can incur multiple call charges.
The practical implication is simple: do not scatter Judge calls across every step just because the feature is available.
Instrument them where the risk justifies the extra inference.
Where an LLM judge is a good fit
1. Evidence and citation checks
A Judge can inspect whether the agent's conclusion is actually supported by the sources or tool outputs it received.
This is especially useful for research, compliance summaries, internal decision support, and workflows where the agent must distinguish facts from assumptions.
2. Policy interpretation
Policies written by humans often contain exceptions and context-dependent language. A natural-language Judge can serve as a first semantic interpretation layer before the workflow proceeds.
It should not be the final enforcement boundary for irreversible actions, but it can identify cases that deserve escalation.
3. Response quality gates
A Judge can catch outputs that are technically valid but operationally poor: unsupported certainty, missing required fields, incomplete reasoning, or a final response that fails a workflow-specific checklist.
4. Evaluation pipelines
Because the guardrail can also run during evaluations, teams can use the same policy language during pre-production testing and runtime monitoring. That helps reduce the gap between an offline benchmark and what the deployed agent is actually expected to do.
Where it should not be the only control
An LLM judge should not be your sole barrier for:
- payment limits
- permission checks
- secrets access
- destructive file operations
- account deletion
- regulated data transfer
- irreversible external communication
- authentication or authorization
Those controls should remain deterministic whenever possible.
A useful rule is:
Use models to interpret policy; use code and permissions to enforce hard boundaries.
If a $10,000 transfer is prohibited, enforce the limit in the transaction system. Do not ask an LLM to decide whether the number "looks too high."
If an agent may send external email only after approval, make approval a required workflow state rather than a prompt instruction.
A low-risk rollout pattern
Start with one workflow where mistakes are visible and reversible.
- Identify one failure mode that fixed classifiers do not capture well.
- Write the Judge instruction as a short, testable policy rather than a long legal document.
- Run it first in Log or Escalate mode if your UiPath configuration allows that behavior for the chosen guardrail path.
- Compare Judge decisions against human review on a representative evaluation set.
- Track false positives, false negatives, latency, and added Agent/Platform Unit consumption.
- Only promote the check to a blocking role when its failure behavior is understood.
- Keep deterministic controls around irreversible tools even after the Judge performs well.
This follows the same principle in TowCue's agent deployment checklist: define permissions, checkpoints, stop conditions, and evidence before granting more autonomy.
The architecture TowCue would use
For a high-value enterprise agent, we would separate controls into three layers.
Layer 1: deterministic boundaries
Identity, permissions, data access, transaction limits, tool allowlists, and approval requirements live here.
These should be enforced by the platform or application, not by model persuasion.
Layer 2: semantic guardrails
LLM as Judge belongs here.
It interprets contextual requirements such as evidence quality, policy fit, unsupported claims, escalation conditions, and workflow-specific response standards.
Layer 3: observability and review
Log guardrail outcomes, investigate recurring failure patterns, and periodically re-evaluate the Judge instruction as prompts, tools, and model behavior change.
UiPath's guardrail observability is useful here because operators can see which agents have guardrails, which action was triggered, the execution stage, and recent enforcement results.
What to measure before scaling it
Do not judge the Judge only by whether a demo looks convincing.
Measure:
- false-negative rate: harmful or non-compliant cases the Judge lets through
- false-positive rate: acceptable cases it blocks or escalates
- added latency: time added to the critical path
- added unit consumption: incremental LLM calls and 64K billing increments where applicable
- policy stability: whether small prompt or context changes materially change the decision
- human-review reduction: whether the Judge actually removes review work rather than adding another alert stream
The target should not be "maximum guardrail coverage." It should be better risk-adjusted throughput.
TowCue take
UiPath's LLM as Judge preview reflects a larger shift in enterprise AI: the control plane is becoming model-assisted too.
That is useful because many important business rules are semantic. They cannot be reduced to a regex or a fixed taxonomy.
But it also creates a new temptation: treating a second LLM as if it makes the first LLM deterministic.
It does not.
The safer pattern is to let the Judge answer questions like:
"Does this output appear consistent with our policy and evidence?"
Then let deterministic systems answer questions like:
"Is this agent allowed to execute the action?"
If teams preserve that separation, LLM judges can become a powerful quality and governance layer. If they blur it, they risk turning a probabilistic safety check into a false sense of control.
Research sources
- UiPath Agents release notes — September 2026 — September 7, 2026 release of LLM as Judge in preview.
- UiPath Agents — Guardrails — guardrail scope and organization-wide vs. per-agent configuration.
- UiPath Agents — Licensing — Agent/Platform Unit consumption and LLM-call metering.
- UiPath Agents — Managing UiPath agents — guardrail observability and enforcement activity.