Try GARS's guardrails

Be the agent: try to break the rules

In a GARS workspace, GARS's guard checks each call the agent makes to Claude Code's file tools (Read, Glob, Grep, Edit, Write, MultiEdit, NotebookEdit) and to its shell tool (Bash), before it runs; calls to other tools are not checked. This is that guard, unmodified, running in your browser: pick something an agent might try, or make your own call, and ask it.

It answers as if the agent worked in a GARS workspace with two projects: public-rnaseq, registered as public, and pilot-cohort, registered as held under a data agreement (deidentified_under_agreement).

{"tool_name": "Edit", "tool_input": {"file_path": "/lab/gars/_system/guard_hook.py"}, "cwd": "/lab/gars"}

Blocked: _system/guard_hook.py is protected template or machine-owned state; a workspace session never edits it directly (R-094; decision 0058). Next: read its stage contract for the owning writer, or ask the human to update template code through the repository.

It reads each call as Claude Code hands it over: the tool's name, the tool's input, and the folder the session runs in. Exit 0 lets Claude Code run the call; exit 2 stops it, and the agent is shown the reason. Here nothing you ask is run: the guard only answers. No AI is involved in the verdict: you play the agent, and the guard is plain Python, standard library only.

At the pinned commit this page runs, the guard works in real use only under Claude Code, for a session started in GARS's workspace folder; a session started elsewhere, or another agent harness, runs unguarded. It judges the call, not why the agent made it: GARS records its resistance to prompt injection as unmeasured, and does not claim the guard stops it. Some rules stay in writing only: the guard's own header gives "do not read a colleague's directory" as one it cannot check.

The design check: batch confounded with condition

This is GARS's real design check, unmodified: press Run and it runs in your browser. No AI is involved: it is plain Python, standard library only. In a GARS run this check is part of stage 01, which its contract calls the last cheap moment before hours of pipeline compute.

This table is d01, GARS's own public test design for this flaw. As published, both A samples are in batch x and both B samples in batch y, so batch cannot be told apart from condition.

Crossing batch with condition passes; so does one batch for everyone. It reads the batch column you declare; it does not infer batch from lanes or run dates, and it passes flaws it does not look for.

What the design check looks for, and what it does not

GARS's defect catalogue lists six kinds of flaw for this stage: batch confounded with condition, one sample per group, sex or age imbalance across arms, cells treated as replicates, sample labels swapped, and a truncated sequencing file, the last caught only in the check's full integrity mode, which this page does not run. This card lets you try the first. The catalogue

Why a plain check

On the builder's own test cases, GARS's checks caught 9 of 10 kinds of planted flaw, with no false alarms on 10 clean ones. Sealed away from the builder, by a separate AI context rather than a person, 6 of 10 kinds were measured and caught; the bar of 9 of 10 is not met, and the public catch rate stays unmeasured. Decision 0103

How well models catch this on their own: the graded results

What happens next

What happens next: watch the agent stop for a person's decision (a recording made at an earlier GARS version).