Agents go where they shouldn’t
of companies say their AI agents have taken unintended actions.
SailPoint survey of 353 security professionals, May 2025 ↗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.
“[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.”
of companies say their AI agents have taken unintended actions.
SailPoint survey of 353 security professionals, May 2025 ↗of permission prompts get approved by Claude Code users. Anthropic calls it approval fatigue.
Anthropic Engineering, March 2026 ↗“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 ↗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.
when the block named the approved way. Told only “not allowed”, the agent stopped and handed the work back.
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.
of blocks and corrections that named a specific alternative were resolved without the person stepping in, against 57% that didn’t.
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.
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.
Once, in plain words or in the open rule format.
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
Where the agent acts, out of the agent's reach.
A blocked action comes back with the approved way.
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.
What changed, not only what was asked (planned).
changed 3 files in ./src outside 0 files outside the project secrets none written result matches the rules
Every agent action, with the evidence.
OWASP’s MCP Top 10 (beta) names lack of audit and telemetry as a top risk (MCP08). Source ↗
{"agent": "claude-code", "user": "dev-042",
"action": "rm -rf ~/", "rule": "fs.outside-project",
"outcome": "blocked", "next": "rm -rf ./build",
"recovered": true}Pulled from the questions developers ask about agent rules, hooks and guardrails.
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.
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.
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.
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.
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.
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.
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.
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.
Shep is in development. Leave your work email and we'll tell you when you can try it.
We’ll only use your email to tell you when Shep is ready. No spam, and we never share it. Privacy