How permission policies learn your defaults
An AI agent permission policy that matches on tool arguments, auto-approves a proven read-only set, and suggests rules from your history.
A permission prompt that fires on every shell command trains you to do one thing: tap approve without reading. That is the failure mode. The agent asks, you rubber-stamp, and the whole point of having a human in the loop quietly evaporates.
Cutting prompts for the sake of it solves nothing. What helps is asking at the right moments. git status should never interrupt you. git push --force to main always should. Pushary permission policies now tell those two apart, because they read the arguments the agent is about to run, not just the tool name.
The problem with name-only rules
Most gating works at the tool level. You allow Bash, or you don't. But Bash is not a unit of risk. cat README.md and rm -rf node_modules are the same tool with very different consequences. A policy that only sees "Bash" has to either ask about everything (and you stop reading) or trust everything (and you lose the gate).
Reading is cheap and safe. Writing, deleting, pushing, and spending money are not. A useful policy has to be able to draw the line inside a single tool.
Matching on arguments, with precedence
Policies in Pushary match on the command itself. You can write an exact match (git status), a prefix match (git push covers git push origin feature, git push --force, and the rest), or a tool-level rule as the fallback. When more than one rule could apply, the most specific one wins. Exact beats prefix, prefix beats tool.
So you can allow git status and git log, leave git push set to ask, and the agent stops bugging you about read-only git while still pausing on anything that rewrites a remote. The full matching behavior is in the policies docs.
Precedence is what makes this safe to use. A broad allow never silently overrides a narrow gate, because the narrower rule always takes priority.
A read-only safe floor, decided from real data
There is a set of commands that genuinely cannot hurt anything: cd, ls, cat, grep, git status, git log, git diff, and friends. They read. They don't write, delete, or send. Asking a human to approve ls is noise, and noise is what erodes attention for the prompts that matter.
So Pushary auto-approves a proven read-only floor by default. The agent runs ls, nothing interrupts you, and the action still lands in your audit trail. You keep the record without paying attention tax for it.
We did not guess at that list. We looked at 1,721 real production questions, the actual stream of things agents stopped to ask about, and pulled out the commands that were read-only every single time. The floor is built from what agents actually do, not from a hypothetical of what they might do. You can read more about how the gate works on the permission policy page.
Key takeaways
- Argument-level matching tells
git statusapart fromgit push, so reads stop interrupting you while writes still pause. - A proven read-only set auto-approves by default, decided from 1,721 real production questions, and still gets logged.
- Permission Autopilot reads your own approve and deny history and offers the rules as one-tap suggestions.
Rules mined from your own decisions
The safe floor handles the universal cases. Your workflow has its own. Maybe you always approve bun run typecheck. Maybe you always deny anything that touches .env. Those are defaults, you just haven't written them down.
Permission Autopilot watches your approve and deny history and surfaces the patterns it finds. When you have approved the same command shape enough times, it offers a rule: allow this going forward? One tap and it's in your policy. Deny the same thing repeatedly and it suggests a gate. Every rule reflects a call you already made by hand. You are just promoting it from habit to policy.
Every suggestion is yours to accept or ignore. Nothing is auto-applied behind your back. The mechanism is one-tap, and the decision stays human.
Why the audit trail matters here
Auto-approving the safe floor only works because nothing disappears. Every command, approved by you, by a rule, or by the floor, lands in the audit trail with what it was, what changed, and where the decision came from. A rule that fires silently is still a rule you can review after the fact. That is the difference between automating a decision and losing it.
How to start
Policies live in your dashboard under the agent settings, and the safe floor is on by default the moment you connect an agent. To shape the rest:
- Connect Claude Code, Codex, Gemini CLI, Cursor, or Hermes with the CLI hook. The quickstart walks through it.
- Let the agent run for a bit. The prompts you answer become the history Autopilot reads.
- Accept the rule suggestions that match how you already work, and gate the ones you don't.
A note on the edges: enforced gating needs hooks, so it works on the CLI agents. The Claude Desktop connector can notify and ask but cannot block a tool, because Desktop has no hook to gate at. That is a real limit, not a setting you can flip.
All of this ships with the agent plans. See pricing, or read the deeper writeup on permission control.