AI Guardrails for Beginners: The Playbook on Human Approval

Meera, a developer in Pune, built a helper that answers customer emails and can also issue refunds. On day one it worked nicely. On day two it refunded an order twice because a customer wrote, “please fix this, I am angry.”

Nothing was hacked. The helper simply did what it thought was helpful. Meera realised her helper needed rules it could not talk its way around. Those rules have a name: AI guardrails. This post shows AI guardrails for beginners, in five small plays.

Last verified: 1 November 2026. AI tools change fast; check the linked sources for anything newer.

Who this is for: anyone building or planning an AI feature that writes text or takes actions. No prior knowledge needed. Time: about 30-45 minutes.

What are AI guardrails, in simple words

Think of a new colleague on their first week. You do not hand them the company bank card. You give them a checklist, you let them draft things, and for anything big you say, “show me before you send it.”

That is the whole idea. A guardrail is an automatic check that runs around the AI and stops bad input, bad output or a bad action. Human approval means the AI stops and waits for a person to say yes or no before it does something that cannot be undone.

OpenAI’s agent documentation draws the same line: guardrails validate input, output or tool use and can block a run, while approvals pause a run before a sensitive action so a person or a policy can accept or reject it.

The playbook at a glance

1. Sort every action into safe, risky or never.
2. Check what goes in, before the AI starts.
3. Check what comes out, before anyone sees it.
4. Pause for a human on risky actions.
5. Keep a record and test your guardrails.

Play 1: Sort every action into safe, risky or never

Goal: know which actions the AI may do alone.

1. Write down every action your AI can take.
2. Mark reading and drafting as safe.
3. Mark anything that spends money, deletes, sends or changes data as risky.
4. Mark anything you cannot afford to get wrong even once as never, and remove that tool.

Meera listed four actions: read an order, draft a reply, send a reply, issue a refund. The first two are safe. Sending is risky. Refunds are risky, and refunds above a set amount are “never without a person”.

You are done when: every tool has a label on paper.

Play 2: Check what goes in

Goal: reject bad requests before they cost time or money. This is an input guardrail.

1. Set a maximum message length.
2. Block topics your helper should never handle, such as legal advice.
3. Hide private data, like card numbers, before the AI sees it.

Meera added a simple rule: messages that ask for anything outside orders get a polite “I cannot help with that” and never reach the AI.

You are done when: a silly or oversized message is turned away cheaply. For tricks hidden inside messages, read our prompt injection playbook.

Play 3: Check what comes out

Goal: catch bad answers before a customer sees them. This is an output guardrail.

1. Check the shape: if you asked for a refund amount, is it a number?
2. Check the limits: is the amount under your ceiling?
3. Check the content: no private data, no promises you cannot keep.

Meera’s helper once promised “a full refund within one hour”. Her new check looks for promises of time or money and sends those drafts to a person instead.

You are done when: a deliberately bad answer is caught by plain code, not by hope.

Play 4: Pause for a human on risky actions

Goal: a person decides before anything irreversible happens. This is human approval, also called human-in-the-loop.

1. When the AI asks for a risky action, do not run it.
2. Save the request with a clear summary: what, why, how much.
3. Show it to a person with Approve and Reject buttons.
4. Run the action only after a clear yes. No answer counts as no.

Here is the idea as a tiny illustration. Real tools differ, so treat it as a sketch:

RISKY = {"issue_refund", "send_email"}

def run_tool(name, args):
    if name in RISKY:
        request_id = save_for_review(name, args)  # stored, not run
        return "Waiting for human approval: " + request_id
    return tools[name](**args)

def on_decision(request_id, approved):
    if approved:
        execute_saved(request_id)

In plain steps: risky requests are parked, a person decides, and only then the saved action runs. OpenAI’s documentation describes the same pattern: the run stops, returns the pending items and a saved state, and you resume the same run later.

Meera’s reviewer sees “Refund 1,200 rupees, order 553, customer says item arrived broken” and taps one button. Reviews take seconds, so the helper stays useful.

You are done when: a risky action never runs until a person approves it, even if you wait overnight.

Play 5: Keep a record and test your guardrails

Goal: prove the guardrails work and learn when they fail.

1. Log every block and every approval: who, when, what.
2. Write 10 test messages that should be blocked and 10 that should pass.
3. Run them after every change.

Meera reused her test list from the evals playbook and her tracing from the observability playbook, so every blocked request left a trail.

You are done when: one command tells you whether your guardrails still catch everything on the list.

Guardrail or human: which to use?

Mistakes to avoid

• Asking a human about everything. People start clicking Approve without reading. Fix: only gate risky actions.
• Guarding only the front door. A check on the first message does not cover every tool call. Fix: put the check next to the tool that causes the side effect, as OpenAI’s documentation advises for multi-agent setups.
• Treating silence as yes. Fix: no reply means no.
• Vague approval screens. Fix: show what, why and how much in one line.

How to know it is working

• Your 20 test messages give the expected block or pass result.
• No risky action appears in logs without an approval record.
• Reviewers approve most requests quickly; if they reject many, fix the AI’s instructions.

Your checklist

• ☐ Every tool is labelled safe, risky or never
• ☐ Input checks run before the AI starts
• ☐ Output checks run before the user sees anything
• ☐ Risky actions wait for a clear yes
• ☐ Blocks and approvals are logged and tested

Frequently asked questions

What does human-in-the-loop mean?

It means a person is part of the process. The AI drafts or proposes, and a person approves before important actions happen.

Are guardrails enough on their own?

No. Automatic checks catch known problems. Human approval covers the surprises, so use both for risky actions.

Does every action need approval?

No. Reading data and writing drafts can usually run alone. Ask a person when the action costs money, changes data or cannot be undone.

Will approval make my app slow?

Only for risky actions. Save the request and resume later, so nothing sits waiting and blocking other work.

Meera’s helper, one week later

A week later an angry customer wrote again. This time the helper drafted the reply, parked the refund, and Meera’s teammate approved it in ten seconds. One refund, one happy customer.

Your next action: label your AI’s tools safe, risky or never. That one list is the start of every guardrail. Next on the roadmap: fine-tuning versus RAG.

Sources: OpenAI, Guardrails and human review; DEV Community, When should an AI agent ask for human approval. Meera and her helper are a made-up example; the amounts are illustrative. Related: AI agents playbook.