jd five

Input Validation and Guardrails

Your agent can call tools. Tools can hurt things: wipe a table, delete a file, refund the wrong order.

A guardrail is a check that runs before (or around) a dangerous step.
Input validation is the common form: look at the tool name and arguments; allow or block.

Do not rely on the model alone. Models guess. Rules are boring and reliable.

Where the check sits

Model may ask. Your code decides.
  Model: call run_sql("DROP TABLE orders")
              │
              ▼
       ┌─────────────┐
       │  Guardrail  │  ← your rules
       └──────┬──────┘
              │
       PASS ──┼── BLOCK (never run the tool)
              ▼
         Real tool

Simple rules that teach the idea

Tool Block when…
run_sql Text contains DROP, DELETE, TRUNCATE (case-insensitive)
run_shell Text contains rm , del , or format

Allow a safe SELECT and a safe echo hello.

Print [PASS] or [BLOCK] so you can see the gate work.

Validation vs “asking the model to be careful”

Approach Problem
“Please don’t run dangerous SQL” in the prompt Easy to ignore or jailbreak
Code that refuses bad args Same rule every time

Use both if you want. Code is the last line for dangerous tools.

What you should remember

  1. Guardrails sit between “model wants a tool” and “tool runs.”
  2. Start with clear allow/deny rules on inputs.
  3. Log blocks — you will need them when something looks “broken” but was saved.

See it in Code

The Code panel runs several candidate tool calls through a tiny guard and prints PASS/BLOCK. No API key required.