Keeps your agents on the path.

Most of the rules your team works by were never written down. Shep turns them into one set of rules for every AI coding agent you run, enforced where the agent acts. When a rule says no, the agent is told the approved way, so the job gets done instead of handed back to you.

Planned support Claude Code Cursor GitHub Copilot Codex Gemini CLI Your own agents
Why now

Agents have the keys. The rules are still suggestions.

97M+monthly downloads of the MCP SDK, the protocol agents use to reach your tools and data
10,000+active public MCP servers
Anthropic, Dec 2025 ↗

“[Rules] are strong guidance injected into the model prompt, not fail-closed runtime guards. The model is asked to follow them, but adherence is not guaranteed.”

Cursor staff, answering “the agent is ignoring the rules” on the Cursor forum, July 2026 · Source ↗

Instructions aren’t enforcement

11×

“I explicitly told it eleven times in ALL CAPS not to do this.” Replit’s agent deleted a production database during a code freeze anyway. The data was later restored.

Jason Lemkin (SaaStr), via The Register, July 2025 ↗
What we measured

A bare no ends the job. The approved way finishes it.

Every agent can already be told no. What it does next depends on what it’s told. We tested that before building the product around it.

Jobs finished the approved way

78/80

when the block named the approved way. Told only “not allowed”, the agent stopped and handed the work back.

Block with the approved way78/80
Bare no8/80

Cheaper per finished job

7.7×

lower cost per finished job: $0.091 against $0.695. On the tasks taken from real repos it was 4.1×. Runs with the approved way used slightly more tokens, 109K against 98K, because they did the work.

Specific beats generic, in real sessions

85%

of blocks and corrections that named a specific alternative were resolved without the person stepping in, against 57% that didn’t.

Specific alternative85%
None, or generic “stop and explain”57%

73% of the rules we found in one team’s agent sessions were written down nowhere. They lived in the corrections a person typed, and 21 of those corrections repeated a rule the agent already had.

317 rules from 107 real Claude Code sessions. That is the part Shep is built to capture.
How we tested. Shep’s own studies, October 2026, before outside users.
  • Finish rate and cost: 240 randomized agent runs on 8 tasks (4 from real repos), with the block delivered by a test harness. 8 tasks is a small set, so read the size of the gap, not the decimals.
  • Rules files: in the runs that gave the agent a rules file, it still tried the forbidden action in 54–58% of them.
  • Real sessions: 444 block and correction events across 107 sessions from one team.
  • Next we’re running the same tests on outside teams’ repos.
How it works

Say yes to agents. Keep the rules.

Most teams have two options today: approve every command by hand, or switch features off. Shep is a third one. You write a rule once, and it holds in every agent.

Write the rule

Once, in plain words or in the open rule format.

  • Say what's allowed and what isn't, and what to do instead.
  • Draft rules from your team’s own corrections, the ones you keep typing to the agent (planned).
  • Keep rules in your repo, reviewed like code.
rules/files.yaml
rule: fs.outside-project
on: delete
block_when: path is outside ./
instead: "Delete only paths under ./build or ./tmp"
stop_after: 2 retries, then ask a person

Enforce it

Where the agent acts, out of the agent's reach.

  • Installs through each agent's own hooks, so nothing changes in how people work (planned).
  • Fails closed. If Shep can't check an action, the action doesn't run (planned).
  • The agent can't switch a rule off by adding a suppression comment to the code. Locking the rule files themselves is planned.
agent sessionexampleallowed

Correct the agent

A blocked action comes back with the approved way.

  • Says what was blocked, and the rule it broke.
  • Gives the approved way first, as a command the agent can run.
  • Says when to stop retrying and ask a person.
what the agent reads
BLOCKED (fs.outside-project): rm -rf ~/ deletes
        outside the project.
LIMIT   Deletes are allowed only inside the
        project folder.
INSTEAD rm -rf ./build to remove the build folder.

Check the result

What changed, not only what was asked (planned).

  • Compares before and after, so a command that looked right can't do something else.
  • Spots patterns across many changes, like a rule broken a little at a time.
  • Caps spend and runaway loops per agent and per person (planned).
after the run
changed   3 files in ./src
outside   0 files outside the project
secrets   none written
result    matches the rules

Keep the record

Every agent action, with the evidence.

  • One history across every agent: what ran, what was blocked, what changed.
  • Export it to your security tools, or hand it to an auditor (planned).
  • See which rules fire most, and fix the ones that get in the way.

OWASP’s MCP Top 10 (beta) names lack of audit and telemetry as a top risk (MCP08). Source ↗

record.jsonl
{"agent": "claude-code", "user": "dev-042",
 "action": "rm -rf ~/", "rule": "fs.outside-project",
 "outcome": "blocked", "next": "rm -rf ./build",
 "recovered": true}
The whole loop

One rule, three actions, start to finish.

  1. Write
  2. Enforce
  3. Correct
  4. Check
  5. Record
record edit src/app.ts rm -rf ~/ blocked rm -rf ./build recovered 3 actions · 1 blocked · 1 recovered
Questions

What developers ask first.

Pulled from the questions developers ask about agent rules, hooks and guardrails.

Isn’t this just a CLAUDE.md or AGENTS.md?

A rules file is a request. The agent reads it and usually follows it, but nothing makes it. Shep checks the action itself, before it runs.

Keep your rules file. In our tests a good one did most of the work, and the agent still tried the forbidden action on about half the tasks. Shep enforces the parts that matter.

Why not a sandbox, or Claude Code’s auto mode?

Use a sandbox. It limits what can happen. It doesn’t know your team’s way: that you use pnpm, not npm, or that nobody edits generated files by hand.

Auto mode blocks what looks dangerous and tells the agent to find a safer path on its own. Shep names the path, using your team’s rules, in every agent you run.

Every agent has hooks already. What’s new?

Hooks aren’t new, and Shep runs on them. What’s new is what the agent gets back when it’s blocked. Told only “not allowed”, agents in our test stopped and handed the work back: 8 of 80 jobs finished. Told the approved way, 78 of 80 did.

Can’t the agent just find a way around it?

That’s the failure Shep is built against. The check runs outside the agent, on the action it’s about to take. The plan: if Shep can’t check an action, the action doesn’t run, and the agent can’t switch a rule off with a suppression comment.

No rule engine catches everything. We test Shep against bypass attempts and fix what gets through.

Can’t I just write my own hook?

You can. Then you write it again for each agent your team uses, and keep them all in step. Most hooks people share also just say no, and a bare no is the version that finished 8 of 80.

Does it slow the agent down or use up my context?

The check is designed to run on your machine with no model call, so it doesn’t touch the agent’s context. Same action, same answer, every time.

When it blocks, the agent spends a little more finishing the job the right way. Per finished job, it came out 4 to 8× cheaper in our tests, because a bare no finishes almost nothing.

Which agents does it work with?

Claude Code and Codex come first, then Cursor, GitHub Copilot and Gemini CLI. All are planned: you write the rules once, and they apply in each agent through its own hooks.

Where do the rules live, and what if two disagree?

In your repo, reviewed like code, and each rule will ship with its own tests (planned). When an allow rule and a deny rule both match, the deny wins.

Get early access.

Shep is in development. Leave your work email and we'll tell you when you can try it.