Our AI agents can write files, run shell commands, push to git, and open PRs. Giving software that kind of access without guardrails would be insane. So we built a permission system. Here's how it works.
Three dimensions
Every agent action goes through three checks that intersect to produce a yes/no/ask decision.
13 permission domains
Everything an agent can do falls into one of 13 domains: filesystem (read/write/delete), git (read/write/push/force-push/create PR), shell, web, browser, tasks, projects, comms, teams, workflows, agents, skills, and MCP external tools.
Each permission has three possible levels: allow (just do it), ask (pause and get human approval), or never (blocked, full stop). So a coding agent might have filesystem read/write on "allow," git push on "ask," and force-push on "never."
Autonomy modes
Nobody wants to configure 13 domains for every agent. So there are four autonomy presets:
Full — agent runs autonomously, only critical stuff needs approval. Good for trusted agents on well-tested codebases.
Partial — low-risk auto, medium/high risk needs approval, critical blocked. The default.
Manual — everything except read-only needs approval. For when you're still feeling out a new agent.
Custom — roll your own per-risk-level rules.
Risk tiers
Every tool gets a risk classification. Reading a file is "none" — no side effects. Writing is "low" — reversible. Committing is "medium." Pushing or opening PRs is "high." Force-push would be "critical." The autonomy mode maps each risk tier to an action. Agent in "partial" mode uses a "high" risk tool? It pauses and asks.
Permission profiles
We ship eight built-in profiles: Read Only, Standard, Full Access, Coding Standard, Marketing Safe, Commerce Restricted, Analytics Read-Only, and Minimal Chat. Each one sets all 13 domains to sensible defaults for a role.
Coding Standard, for instance, gives full filesystem and git access but blocks agent configuration and team management. A coding agent has no business reconfiguring other agents. Profiles can be overridden per-agent with JSON patches if you need to tweak one domain without forking the whole profile.
Who approves what
When an agent hits an "ask" permission, someone needs to approve. But who? Depends on the action, the agent, and the team. The point is you’re always in the loop when it counts.
We built an approval authority resolver. Policies are evaluated in specificity order: agent-level overrides team-level, which overrides org-wide defaults. Each policy matches on action patterns ("git_*", "file_delete") and risk levels, then resolves to approvers — specific people, anyone with a role, or any team member.
You can require all approvers to agree, any one to approve, or set a minimum — two sign-offs for production file deletion, that kind of thing. Scales from a solo founder approving everything to an enterprise with multi-person approval chains.
Audit trail
Every action — auto-approved, human-approved, or blocked — gets logged. Agent, session, task, tool, risk level, decision, plus summaries of input and output.
The log is hash-chained with SHA-256. Each entry includes a hash of the previous entry plus its own data. Modify or delete an entry and the chain breaks. Same idea as blockchain but applied to agent audit logs. Useful for compliance, also useful for debugging — when an agent does something weird, you can trace the exact sequence of actions and approvals.
Layers, not walls
No single check is enough. The whole thing works because multiple layers back each other up. Profiles define access. Autonomy modes set the leash length. Skill filtering catches conflicts between what a skill declares and what the profile allows. Server-side middleware validates every action even if the client-side check passes. Approval policies route decisions to the right humans. The audit chain records everything.
If one layer has a bug or gets bypassed, the others still hold. The client is never the authority — the server is the single source of truth.
Three principles
Fail safe. If there's any ambiguity about whether an agent should do something, the answer is no. You opt into permissions, never out.
Granular but usable. 13 domains sounds like a lot. In practice, most teams pick a profile and never touch individual permissions. The complexity is there if you need it.
Audit everything. Not as an afterthought. The hash chain is a core feature, not a checkbox. When autonomous software acts on your behalf, you need receipts.
We're still stress-testing all of this on our own codebase before letting anyone else near it. But so far, it's holding up — agents get enough freedom to be useful and enough constraints to be trustworthy.