Permissions and the autonomy slider
The whole lesson in one sentence: permissions decide what an agent may do without asking, autonomy decides how far you slide that line, and the cost of being wrong decides how much rope you hand over.
Two questions, one decision
Every time you put an agent to work you answer two questions, whether you notice or not.
- What may it do without asking you first? That is permissions.
- How much of the job do you hand over before you check the result? That is autonomy.
The first is a config file. The second is a posture. They are different things, and people who conflate them ship agents that are either annoying (asks about everything) or dangerous (asks about nothing). This lesson keeps them separate and then connects them through the one variable that actually matters: the cost of an error.
Permissions: the line between allow, ask, and deny
A permission system is a set of rules that says, for each action, whether the agent does it silently, pauses to ask you, or is refused outright. Claude Code's model is the cleanest example. From the Anthropic settings docs, the evaluation order is fixed: deny rules first, then ask, then allow. The first matching rule wins.
{
"permissions": {
"allow": ["Bash(npm run lint)", "Bash(npm run test *)", "Read(~/.zshrc)"],
"deny": ["Bash(curl *)", "Read(./.env)", "Read(./secrets/**)"]
}
}
Read that as a scope, not a recipe. You are not listing steps the agent should take. You are drawing a fence: inside it the agent moves freely, at the edge it asks, and some things it never touches no matter how reasonable the request looks mid-task. The deny list is the load-bearing part. An empty deny list with a generous allow list is how a secret ends up in a log.
One warning that matters in practice: permissions do not travel. Instructions are portable across harnesses through a shared AGENTS.md file. Permissions are not. Each harness has its own format and semantics, and no harness reads another harness's permission file. Claude Code uses .claude/settings.json (JSON), Codex uses .codex/config.toml (TOML), Gemini uses .gemini/settings.json, and so on. There is no cross-vendor standard and none is close: the AAIF working groups have published nothing, the AGENTS.md permissions: frontmatter proposal has sat open since November 2025, and the only vocabulary that converges at all is MCP tool scoping (mcp__server__tool and its cousins). So pick one harness as primary, write a tight allow list and a strict deny list there, and do not waste effort syncing permission files that will never agree.
Autonomy: a slider, not a switch
Permissions draw the fence. Autonomy decides how much of the field you let the agent cross before you look. Karpathy's framing is the one to hold onto: autonomy is a slider, not an on/off switch. Build Iron Man suits, not Iron Man robots. A suit keeps the human in the loop and amplifies them, with adjustable levels of assistance and gradual, reversible loss of control. A robot is all-or-nothing delegation: when it fails, the whole task fails.
He backs this with arithmetic, not vibes. 80% reliability per step across 5 steps is 32% end-to-end success. Fully autonomous multi-step agents are not reliable enough for critical work today. That is why the answer is a slider you can set per task, not a switch you flip once.
You can name the positions. Reading the products that already ship a slider, they sort into a spectrum:
Cursor walks a user up this exact path: Tab-completion, then inline edit, then chat, then Agent mode. Perplexity does it with Search, Research, Deep Research. The pattern is deliberate, because trust is built incrementally. A product that only offers "full autonomy" forces a trust jump most users will not make. The slider also creates a recovery path: lower positions have explicit review moments (pre-tool approval, mid-workflow review, post-generation feedback), and the human must always be able to downgrade. If you are in operator mode and see something off, the next step should drop to executor without drama.
Devin is the cautionary tale. It launched in 2024 as the "fully autonomous software engineer," and by April 2025 repositioned as a collaborator, not an autonomous engineer, with Interactive Planning making human review the default. Even the company that sold full autonomy moved its product down the slider.
The five-tier spectrum: build versus buy
Permissions and autonomy assume you have an agent to govern. Where that agent comes from is its own slider, this one from build to buy. The AI Automators' taxonomy collapses hundreds of platforms into five tiers.
| Tier | What | Who hosts | Examples |
|---|---|---|---|
| 1 | Custom code on a direct API | You | Messages API, Gemini API, OpenAI API |
| 2 | Agent framework or SDK | You | Claude Agent SDK, OpenAI Agents SDK, LangGraph, Crew AI |
| 3 | Managed platform and infra | Vendor | Vertex AI Agent Builder, Bedrock Agent Core, E2B, Modal |
| 4 | Visual low-code | Vendor | n8n, Zapier Agents, Make.com, Dify |
| 5 | Embedded SaaS agent | Vendor | Salesforce Agentforce, Intercom Fin, Atlassian Rovo |
Left to right trades the same way every time: tier 1 gives maximum control and flexibility for the longest build time and self-managed infrastructure, tier 5 gives fast time-to-market and vendor-managed infrastructure for vendor lock-in. Tier 3 sits on the hinge: managed infra, reduced flexibility. The heuristics are blunt and useful. Need full control, compliance, or privacy? Stay at tier 1 to 2. Need speed? Tier 3 to 5. No dev capacity, config only? Tier 4 to 5. Note what is not on the spectrum: agent products you use rather than build, like Claude Code itself, are the agent, not a building block.
Cost-of-error is the governor
Here is the line that ties all three together. You give an agent more rope when a mistake is cheap to catch and cheap to undo, and less when it is not. That single variable sets your permission fence, your slider position, and even your tier.
A one-off script in a scratch directory is cheap to catch and trivial to reverse, so give it a wide fence and run it as an operator. A production database migration is neither, so the deny list tightens, the slider drops to executor, and a human approves each step. Same agent, same user, different cost of error, different rope. Steinberger's OpenClaw sits at the high extreme on purpose: he runs many parallel agents, commits straight to main, and says plainly "I ship code I don't read." That is a deliberate Iron Man-robot stance from someone with fifteen years of engineering intuition as a safety net, and the 135k exposed OpenClaw instances are the reminder of what that stance costs when the net is not there. It is not a default. The point of the slider is that he chose the high end and you are allowed to start lower.
Takeaways
- Permissions are what the agent may do without asking. Order is deny, then ask, then allow, first match wins. The deny list is the load-bearing part.
- Permission files do not port across harnesses. Pick one primary, write a tight allow and strict deny, and stop syncing.
- Autonomy is a slider, not a switch: observer, executor, operator, autonomous. Always let the human downgrade.
- Build-to-buy is its own slider of five tiers, trading control for convenience.
- Cost-of-error is the governor. Cheap to catch and reverse means more rope. Expensive means less.
Where this goes next
You now have the two knobs (what an agent may do, and how far you let it go) plus a way to source the agent in the first place. The next lesson, "Agents vs workflows, deeper," goes back under the hood and pulls apart when a fixed workflow beats a free-running agent and when it does not, because half of governing autonomy is knowing which jobs should never have been an agent at all.