Use this note before connecting an agent to GitHub, email, Slack, Notion, Stripe, cloud infrastructure, deployment tools, or customer data. The agent's value is tied to access; the risk is also tied to access.
The permission ladder
AI agents are often described as if autonomy were one feature. In practice, autonomy is a ladder. Each rung changes the risk profile.
| 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 before granting 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.
The integration risk map
Integrations are not equal. A calendar reader and a deployment token should not be reviewed with the same seriousness.
| 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. |
Approval design matters more than prompts
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".
Useful pattern: require the agent to produce a plan before action. Review the plan separately from the generated output. Then approve only the specific action, not a broad permission.
A team policy you can copy
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.
Trial plan for 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.
The buyer's 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.
More Research Notes
SpecificityA 30-second test for spotting vague AI product promises before you waste time on a trial.TrustThe evidence an AI tool should show before you give it files, code, customers, or budget.BudgetEstimate the real cost of AI coding tools beyond the monthly subscription price.Local vs CloudA task-level decision framework for local models, hosted APIs, and hybrid workflows.