Most teams I talk to get the agent demo working before anyone writes down what it can do in production.
Not the model. Not the prompt. The operating permissions - what account it runs as, what it can touch, what it can spend, and who has to approve.
That gap is where the surprises live.
The table that should exist before the agent goes live
For any agent touching real tools, I would want a single table that answers:
- which account it runs as
- what it can read
- what it can change
- what it can send externally
- what it can spend
- what it can deploy or break
- what requires human approval
- what gets logged
- how to turn it off fast
Nine columns. One row per connected tool. That is the whole artifact.
“Read-only” is not the safe answer you think it is
The uncomfortable bit is that “read-only” still matters.
A read-only agent may see source code, support tickets, invoices, Slack channels, customer records, logs, or internal docs. That is a real blast radius even if it never writes a byte.
And a write-capable agent needs verbs, not labels. “Write access to GitHub” is not a permission. These are:
- comment
- merge
- refund
- invite
- export
- deploy
- delete
The label tells you nothing. The verbs tell you everything.
A default rule set I would start from
This is the boring, working starting point. Tighten or loosen per tool, but start here:
- Outbound to humans: draft-only for anything that leaves the company - email, Slack DMs to customers, social, support replies. A human ships the final.
- Code: PRs allowed, merges approved.
- Money: read-only billing lookups, refunds approved.
- Cloud: inspection allowed, resource changes approved.
- Logs: every run shows trigger, tool call, object touched, result, and human approval if one was required.
- Kill switch: one obvious off-switch per connected tool. Not a config flag buried in a repo. A button or a single command.
The point is not that these rules are correct for every team. The point is that some version of this exists in writing before the agent becomes production infrastructure.
What this is not
A few things to be honest about:
- This is not a security audit. It is a map.
- It is not a compliance review, not a pentest, not an IAM audit.
- It does not make any agent “safe” or “least-privileged” or “production-ready.” Those words do a lot of work that the table does not do.
- It does not replace your provider’s own controls - org policies, role scopes, OAuth scopes, MCP allow-lists. It tells you which of those you actually need to set.
The table is the first artifact, not the last one.
The boring summary
- Write the permission map before the agent touches a real tool, not after.
- One row per connected tool. Nine columns: account, read, change, send-external, spend, deploy-or-break, approvals, logs, kill switch.
- Treat “read-only” as a real surface area, not a free pass.
- Describe write access in verbs (comment, merge, email, refund, invite, export, deploy, delete), not labels.
- Drafts for anything that leaves the company. Approvals for money, merges, and resource changes.
- One kill switch per tool, obvious enough to use at 2am.
The table does not need to be fancy. It just needs to exist.
— Rich
Frequently asked questions
What is an agent permission map? A single table, one row per connected tool, that records which account the agent runs as, what it can read, what it can change, what it can send externally, what it can spend, what it can deploy or break, what requires a human’s approval, what gets logged, and how to turn it off fast. It is a written description, not a scanner.
Is “read-only” access actually safe for an AI agent? No. Read-only access can still expose source code, support tickets, invoices, Slack history, customer records, logs, and internal docs. The map should treat read-only as a real blast radius and decide whether the agent really needs it.
What is a kill switch for an AI agent? One obvious off-switch per connected tool that a human can use at 2am. A revoked OAuth token, a disabled GitHub App, a paused Zapier/Make scenario, a removed Slack app, or a single command that disables the agent’s outbound calls. Not a config flag buried in a repo.
Do I need a security audit, an IAM audit, or this map? The map is the cheaper first artifact and almost always the missing one. It is not a security audit, an IAM audit, a compliance review, or a penetration test. If you eventually need any of those, the map makes them shorter and cheaper because the scope is already written down.
Want a written permission-map review?
This lane is in private validation. If you are connecting an agent to GitHub, Gmail, Slack, Stripe, AWS, MCP servers, support tools, or a deploy path and you want a fixed-scope, async, written permission-map review, email support@richgibbs.dev with the tool the agent touches and the riskiest verb it can do.
What you get back in this window is the checklist and the report template I am working from, not a free review of your stack. No public price during the validation window. The QuickCheck site lists the related paid offers that already exist for AI/API cost rescue, inbox/DNS, and one-host server hygiene; the Agent Permission Map is a separate lane that is not yet a productized QuickCheck.
I will not ask for credentials, OAuth grants, or admin access. I cannot accept regulated data (health, financial-account, payment-card, student, children’s, HR).
Advisory checklist for operators. Not legal advice, not a security audit, not an IAM audit, not a compliance review, not a penetration test, and not a certification. No affiliation with or endorsement by GitHub, Google, Slack, Stripe, AWS, OpenAI, Anthropic, Microsoft, Cloudflare, or any other vendor named above. The author will not ask for credentials, OAuth grants, or admin access, and cannot accept regulated data (health, financial-account, payment-card, student, children’s, HR).