The AI Agent Permission Ladder Every CTO Needs Before Production Access
A practical permission ladder CTOs can use before AI coding agents touch production systems, customer data, or infrastructure.
The AI Agent Permission Ladder Every CTO Needs Before Production Access
AI coding agents do not create a production risk because they write code. They create a production risk because teams hand them the same keys they gave humans after years of trust.
The PocketOS story is the warning shot. A Cursor agent running Claude reportedly deleted a production database and backups in seconds. The useful lesson for CTOs is boring, which means it matters: this was a permissions design failure before it was an AI failure.
Most engineering teams still treat AI agents like faster IDE plugins. That worked when the agent only suggested code. It breaks when the agent can run commands, touch infra, read secrets, open PRs, or operate across a real customer environment.
The mistake: one permission model for every task
A human engineer carries judgment, context, and accountability. An agent carries instructions, tools, and whatever access you granted five minutes ago.
Those are not the same control surface.
The right question is not, “Do we trust the model?” The better question is, “What is the blast radius if the model follows the wrong instruction with full confidence?”
Founders want speed. Engineers want leverage. CTOs need a permission ladder that gives teams the upside without turning every AI workflow into a production incident.
The AI Agent Permission Ladder
Use this ladder before any agent receives repo, cloud, database, or deployment access.
Level 1: Read-only research
Agents can read docs, tickets, logs, and code. They can summarize context and propose changes. They cannot edit files or run commands.
This level fits product, support, and ops teams too. A support agent can summarize customer pain without touching customer records. A product agent can cluster feedback without changing roadmap data.
Level 2: Local sandbox writes
Agents can edit files inside a branch, worktree, or disposable environment. They cannot access secrets. They cannot call production APIs. They cannot delete shared resources.
Most coding work should start here.
Level 3: Test execution with guardrails
Agents can run tests, linters, type checks, and local scripts from an allowlist. The team blocks shell escape paths, destructive commands, and unknown network calls.
This is where teams gain speed without giving up control.
Level 4: Human-approved integration
Agents can open PRs, attach screenshots, post demos, and explain risk. Humans approve merges, migrations, dependency changes, and deploy steps.
The agent should show its work before a person accepts the change.
Level 5: Production-adjacent access
Agents can inspect production telemetry, feature flags, and read-only analytics. They cannot modify production data or infra.
This level helps leaders across support, product, sales, and engineering ask better questions without granting write access.
Level 6: Production writes
Most teams should avoid this level for now. If you grant it, require narrow scopes, expiring tokens, command approvals, audit logs, and rollback playbooks.
A coding agent should never receive standing production delete rights.
Put the ladder in a skill file
Policy only works when it appears where the work happens. I like small skill files because they sit next to the agent workflow and remove ambiguity.
# AI Agent Production Access Skill
## Default stance
Agents may read broad context. Agents write only inside sandboxes until a human approves escalation.
## Allowed without approval
- Read repository files
- Create or edit files in a feature branch
- Run: pnpm test, pnpm lint, pnpm typecheck
- Summarize logs with secrets redacted
## Requires human approval
- Database migrations
- Dependency upgrades
- Infrastructure changes
- Deployments
- Feature flag changes
- Any command touching production data
## Never allowed
- Delete production databases
- Delete backups
- Print secrets
- Rotate credentials without an incident ticket
- Run unknown shell scripts from the internet
## Escalation checklist
Before approval, the agent must provide:
1. Files changed
2. Commands it wants to run
3. Customer impact
4. Rollback plan
5. Data touched
That small file does more than protect the repo. It teaches the organization how to think about agent access.
The leadership pattern
Across overseas engineering teams and multiple companies, the failure mode looks the same: a tool starts as personal productivity software, then spreads through the company before leadership designs the operating model around it.
AI adoption cannot stay trapped inside the engineering team. Product will use agents for specs. Support will use agents for ticket triage. Ops will use agents for workflows. Sales will use agents for account research.
The CTO job is to make that adoption safe enough to scale.
Start with the permission ladder. Convert it into skill files. Add audit logs. Review every workflow where an agent can touch customer data, money, infrastructure, or production state.
Speed matters. So does the part where the company survives the speed.
Get the Full Agent Permission Checklist
I posted a breakdown of the full AI agent production-access checklist on LinkedIn. Comment "Guide" on that post and I'll DM you the checklist directly.
Work With Me
I help engineering orgs adopt AI across their entire team, not just the code, but how product, support, and operations work too. If you want your org moving faster without growing headcount, let's talk.
Kris Chase
@krisrchase