- Grant read-only access first.
- Treat deploy, send, spend, and permission changes as human-approved actions.
- Reject broad OAuth scopes when a narrower workspace or sandbox would do.
I think of permissions as a ladder
AI agents are often sold as if autonomy were one feature. I find it safer to treat autonomy as a ladder. Every rung gives the agent more usefulness and more ways to cause damage.
| Level | Permission | Example | Main risk |
|---|---|---|---|
| 1 | Suggest | Draft a reply, propose a diff, summarize a document. | Wrong output wastes review time. |
| 2 | Read | Read a repo, meeting transcript, CRM record, or analytics dashboard. | Sensitive data exposure. |
| 3 | Write draft | Create a branch, draft a Notion page, prepare an email. | Generated work may be mistaken for approved work. |
| 4 | Modify live systems | Edit production content, merge code, update tickets, change settings. | Incorrect actions create operational damage. |
| 5 | Contact or spend | Send email, invite users, buy ads, create cloud resources, issue refunds. | The agent can create financial, legal, or reputational harm. |
Most teams should start at levels 1-2. Level 3 can be safe with review. Levels 4-5 need explicit policies, logs, and approval gates.
Five questions I ask before access
- What can the agent read? List data sources, not integrations. "GitHub" is too broad; "one public repo" is specific.
- What can the agent write? Draft-only is different from merge, send, publish, deploy, or charge.
- Who approves actions? Is approval required every time, only above a threshold, or never?
- Where is the audit trail? You should be able to see prompt, input, decision, action, time, and actor.
- How do you revoke access? Revocation should be obvious, fast, and testable.
Not every integration has the same risk
I would not review a calendar reader and a deployment token with the same seriousness. The integration name is not enough; the allowed action is what matters.
| Integration | Default stance | Reason |
|---|---|---|
| Docs or notes | Read-only first | Useful context, but may contain private strategy or customer information. |
| GitHub or GitLab | Branch-only first | Agents can be useful for drafts; merging should remain human-approved. |
| Draft-only first | Sending messages creates external consequences. | |
| Slack or chat | Private-channel first | Incorrect messages can confuse teams or expose sensitive data. |
| Billing or payments | Manual approval always | Refunds, purchases, and invoices affect money and trust. |
| Cloud infrastructure | Read-only or sandbox | Creating resources can cost money; changing settings can break production. |
Prompts matter less than approval design
A safer agent is not merely a better prompt. It is a better system around the prompt: scoped tokens, dry-run mode, diffs, approvals, rollback, and logs. The interface should make it hard to confuse "suggested" with "done".
A small-team policy I would actually use
For a small team, a simple policy is better than no policy:
- Agents may read public documentation and designated non-sensitive project files.
- Agents may create drafts, branches, tickets, and internal notes.
- Agents may not send external messages, merge code, deploy, create paid resources, issue refunds, or change permissions without human approval.
- All agent actions must leave a visible log.
- Any integration touching customers, money, production, or private code requires owner approval before connection.
How I would trial a new agent
- Start with a sandbox task. Use a fake repo, sample docs, or a small internal project.
- Give one integration only. Do not connect everything on day one.
- Use read-only access where possible. The first trial should test reasoning, not permissions.
- Measure review time. A fast agent that creates slow review is not a productivity win.
- Test revocation. Disconnect the tool and confirm it loses access.
My final permission question
Ask: "What is the worst thing this agent can do without another human approving it?" If that answer makes you nervous, the permission set is too broad for the current trust level.
Concrete scenario: a support agent that can issue refunds
The risky moment is not when the agent summarizes tickets. The risky moment is when the same agent receives permission to write to the help desk, update the CRM, and trigger refunds. In that setup, one bad interpretation can become an external customer message and a financial action before anyone has reviewed it.
My default setup would be narrower: let the agent read the ticket, draft the response, and propose a refund reason. Keep the actual send and refund buttons behind a human. If the team wants automation later, add a dollar threshold and a visible audit log first.
| Permission request | My decision | Why |
|---|---|---|
| Read recent support tickets | Allow for a scoped queue | Useful context, limited blast radius. |
| Draft customer replies | Allow | Drafts are reviewable before harm. |
| Send replies automatically | Deny at first | External messages create trust risk. |
| Issue refunds below a threshold | Only after logs and review sampling | Money actions need a rollback and audit trail. |
| Change account permissions | Deny | Permission changes compound every other risk. |
When this checklist is not enough
This checklist is not enough for regulated data, health records, legal work, payroll, or production infrastructure. In those cases, treat the agent like a new internal system: involve the system owner, document access, review logs, test revocation, and require a real incident path before launch.