leash

agent
Security Audit
Fail
Health Warn
  • License — License: MIT
  • Description — Repository has a description
  • Active repo — Last push 0 days ago
  • Low visibility — Only 5 GitHub stars
Code Fail
  • rm -rf — Recursive force deletion command in demo/inject.sh
  • rm -rf — Recursive force deletion command in demo/safe.sh
  • rm -rf — Recursive force deletion command in internal/policy/builtin/recommended.yaml
Permissions Pass
  • Permissions — No dangerous permissions requested

No AI report is available for this listing yet.

SUMMARY

Guardrails for AI coding agents — block catastrophic tool calls before they run. Semantic, agent-neutral, near-zero false positives.

README.md

🐕 Leash

Guardrails for AI coding agents.

Leash blocks the catastrophic command before your agent runs it —
and stays silent for everything else.

CI
 ·  License: MIT
 ·  CLI  ·  Rules  ·  Architecture

An agent is asked to exfiltrate AWS credentials; Leash blocks the tool call before it runs

An agent is asked to send your AWS credentials to a URL. It reaches for the tool
call — cat ~/.aws/credentials | curl … — and Leash blocks it before it runs,
so the agent backs off. No denylist to evade: Leash parses the command and judges
what it actually does.


Why Leash

AI agents run with your permissions. A confused — or prompt-injected — agent
can delete your files, leak your keys, or wire up persistence, with nothing
standing between it and your machine. The denylist "guardrails" floating around
are substring matchers: trivially dodged (rm -fr, a script written then run),
and so noisy you turn them off.

Leash is built the other way:

  • 🧠 Semantic, not substring. rm -rf ~, rm -fr ~, rm -r -f ~,
    sudo rm -rf $HOME — one dangerous intent, all caught.
  • 🎯 Near-zero false positives. rm -rf node_modules,
    git push --force-with-lease, npm install — never touched. This is the
    product.
  • 🚦 Block, ask, or allow. Unambiguous catastrophe is blocked; the
    plausibly-legit gets a confirm prompt; the everyday passes in silence.
  • 🔒 Permissive modes don't weaken it. Agent hooks run before the
    permission system, so a leash deny blocks even in auto-accept or
    --dangerously-skip-permissions sessions — where it's the only guardrail
    left standing.
  • 🪶 Fails open. If Leash can't parse something, the command runs. A
    guardrail must never brick the agent it protects.
  • 🧩 Agent-neutral. One portable rulepack. Claude Code today; Codex, Cursor,
    and Gemini next.

See it in the loop

It stops prompt injection, not just clumsy commands. A hidden instruction in
a file steers the agent into rm -rf ~ — Leash blocks the tool call and tells you
where it came from.

A prompt injection hidden in a Makefile tries to make the agent delete your home directory; Leash blocks it More scenarios — asks when unsure · stays quiet on routine work · keeps secrets out of the model

Asks before an irreversible action — force-push, history rewrite:

Leash pauses a force-push and asks the human to confirm

Stays out of the way on everyday commands — near-zero false positives:

Leash lets rm -rf node_modules and npm install run without a prompt

Keeps secrets out of the model's context — even a cat with no network:

Leash asks before an agent reads cloud credentials into its context

Install

# Homebrew — macOS
brew install hoophq/tap/leash
# npx — macOS / Linux, no install
npx @hoophq/leash

Quickstart — Claude Code

leash init --global   # add the PreToolUse hook to .claude/settings.json, for every project

Start a Claude Code session and Leash is live. Ask the agent for something
reckless — it gets stopped, or asked to confirm.

claude

All CLI commandsinit, check (test a verdict without
an agent), hook, and version.


What it stops

The recommended pack is embedded in the binary and always on:

It stops an agent from… like
wiping your home or root rm -rf ~ · sudo rm -rf / 🛑 deny
wiping a disk dd of=/dev/sda · mkfs.ext4 /dev/sdb1 🛑 deny
detonating a fork bomb :(){ :|:& };: 🛑 deny
exfiltrating a secret cat ~/.ssh/id_rsa | curl … 🛑 deny
opening up a system path chmod -R 777 / 🛑 deny
deleting outside your workspace rm -rf ~/.config/x ⚠️ ask
reading a key into its context cat ~/.aws/credentials ⚠️ ask
piping the web into a shell curl … | sh ⚠️ ask
rewriting git history git push --force · git reset --hard ⚠️ ask
installing off-registry npm i git+https://… · pip install git+… ⚠️ ask
injecting an install hook a postinstall added to package.json ⚠️ ask
setting up persistence crontab - · a LaunchAgent · systemctl enable ⚠️ ask

…and it is not fooled by flag reordering, sudo, $HOME vs ~, or a
renamed fork bomb. Every detector ships with tests that pin both the catch and
the safe cases.

Write your own rules & the full match reference


Make it yours

Layer your own rules with a ./.leash.yaml (auto-discovered) or --rules <file>:

rules:
  - id: no-terraform-destroy
    effect: deny
    match:
      shell: { command_in: [terraform] }
      regex: '\bterraform\b.*\bdestroy\b'

Or retune a built-in rule's effect in a single line — no need to redefine it:

overrides:
  git-force-push: deny                # ask  -> deny
  pipe-to-shell-from-network: allow   # silence it

Rules & overrides, in depth


How it works

agent tool call  →  adapter  →  engine (shell-AST facts)  →  rulepack  →  allow · ask · deny

An adapter normalizes each agent's tool call into a neutral action; the
engine parses shell commands into semantic facts; rules match those facts
and the most severe effect wins. The engine and rulepacks know nothing about any
specific agent — which is what makes one rulepack portable across all of them.

Architecture & extension points


What Leash is — and isn't

Leash is local self-protection: it lives in your config, and you can edit or
remove it. That's exactly right for protecting yourself from an agent's
mistakes. It is honestly not a compliance control — a determined user (or an
agent running as you) can disable anything on a machine they fully control.

Need guardrails your developers can't turn off — centrally managed, enforced
fleet-wide, with approval workflows and audit? That's a different trust model,
and it's what hoop.dev does. Same idea, enforced where the
developer can't override it.


Roadmap

  • Semantic detectors — deletes, disk wipes, fork bombs, exfiltration,
    world-writable, off-registry installs, manifest hooks, persistence
  • One-line installers — Homebrew, npx
  • More agents — Codex, Cursor, Gemini CLI
  • A shareable rulepack registry — leash add <pack>

License

MIT © hoop.dev — built by the team behind hoop.

Reviews (0)

No results found