Reader persona: a founder, operations lead, marketer, sales manager, or customer success owner who wants to use AI automation but is responsible for avoiding accidental public posts, bad customer messages, or production changes.
Job to be done: turn a proposed automation into a clear permission audit before launch, so a human can approve what the agent may read, write, send, schedule, or change.
Most AI automation failures are not dramatic model failures.
They are permission failures.
An agent had access to too many files.
A workflow could send messages without review.
A scheduled job kept running after the campaign changed.
A draft step quietly became a publish step.
This is why every serious automation needs a permission audit before it goes live.
You do not need to be technical to run the first version. You need a clear brief and a disciplined checklist.
The simple permission audit prompt
Before launching any AI workflow, paste this into your agent:
You are auditing an AI automation before launch.
Do not execute the workflow.
Do not send messages.
Do not publish content.
Do not edit production systems.
Do not create scheduled jobs.
Review the workflow brief below and return a permission audit with:
1. What the agent needs to read
2. What the agent needs to write
3. What the agent might send or publish
4. What systems it can change
5. Which steps require human approval
6. What could go wrong
7. How to make the first version safer
8. A launch/no-launch recommendation
Workflow brief:
[paste your workflow here]The wording matters.
The first four lines stop the agent from treating the audit as permission to act.
Example workflow brief
Use a short brief like this:
Workflow name:
Weekly sales discovery summary
Goal:
Every Friday, summarize sales call notes and produce a list of the top objections, requested features, and follow-up questions.
Inputs:
- call notes in Google Docs
- CRM notes from the past 7 days
- support tickets tagged sales-question
Outputs:
- a markdown summary
- a list of suggested follow-up emails
- a Slack message draft for the sales channel
Desired behavior:
The agent should draft everything and ask a human to approve before anything is posted or sent.This brief is enough for an agent to identify the risky parts.
It can see private customer data, CRM access, support tickets, email drafts, and Slack posting.
What a good audit should return
A useful audit should look like this:
# Permission audit
Launch recommendation: launch only as draft-only v1.
Reads:
- Google Docs call notes: private customer data
- CRM notes: private sales and account data
- support tickets: private customer support data
Writes:
- local markdown summary: safe if stored in approved folder
- follow-up email drafts: safe only as drafts
- Slack message draft: safe only if not posted automatically
External actions:
- sending email: not allowed in v1
- posting to Slack: not allowed in v1
- editing CRM: not allowed in v1
Human approval gates:
- approve data sources before the first run
- approve final summary before sharing
- approve each email before sending
- approve Slack post manually
Main risks:
- exposing customer data in a public channel
- summarizing outdated CRM notes
- generating follow-up emails with unsupported promises
- posting a draft as if it were approved
Safer v1:
- read only exported notes from an approved folder
- write only to a local markdown file
- create email and Slack drafts, not sent messages
- require human approval for every external actionIf the audit does not separate reads, writes, and external actions, ask the agent to redo it.
That separation is the whole point.
The five permission buckets
For non-technical teams, use these buckets.
1. Read permissions
What can the agent see?
Examples:
- customer notes
- sales calls
- invoices
- CRM records
- support tickets
- private docs
- analytics dashboards
Risk question:
Could this input expose private, regulated, or commercially sensitive information?2. Write permissions
What can the agent change?
Examples:
- markdown files
- spreadsheets
- CRM fields
- CMS drafts
- task boards
- database rows
Risk question:
If the agent writes the wrong thing, can we easily undo it?3. Send permissions
What can the agent send to people?
Examples:
- emails
- Slack messages
- Telegram messages
- LinkedIn DMs
- customer support replies
Risk question:
Would a bad message damage trust or create an obligation?4. Publish permissions
What can the agent make public?
Examples:
- blog posts
- X posts
- Dev.to articles
- changelog entries
- product pages
- docs updates
Risk question:
Would this become visible outside the team?5. System-change permissions
What can the agent change in tools or infrastructure?
Examples:
- API settings
- billing settings
- feature flags
- production configs
- scheduled jobs
- access control
Risk question:
Could this affect customers, costs, security, or uptime?A safer first version
For most business workflows, v1 should be draft-only.
That means the agent can:
- read approved input
- create a summary
- write a local draft
- list suggested actions
- ask for review
The agent cannot:
- send messages
- publish content
- update customer records
- delete files
- create recurring schedules
- change production settings
This may feel slower, but it is how you build trust.
Once the draft-only workflow is reliable, add one permission at a time.
Approval gates to require
Use this approval table:
| Action | Approval needed? | Default |
|---|---|---|
| Read approved local files | No | Allow |
| Read private customer systems | Yes | Ask |
| Write local draft files | No | Allow |
| Edit CRM records | Yes | Block in v1 |
| Send customer email | Yes | Block in v1 |
| Post to Slack | Yes | Draft only |
| Publish public content | Yes | Block in v1 |
| Create scheduled job | Yes | Block until manual run works |
| Delete anything | Yes | Block |
This table is simple enough for a non-technical owner to review.
Ask for a failure plan
A permission audit is incomplete without failure cases.
Ask:
For each permission, list:
- what could fail
- how we would notice
- how we would stop the workflow
- how we would undo the action
- who should be notifiedThe answers reveal whether the workflow is ready.
If nobody knows how to stop it, do not launch it.
Where ClawMama fits
ClawMama is designed for this operating style: useful automation with human approval where it matters.
A ready-to-use OpenClaw/Hermes agent can help you:
- turn a vague automation idea into a permission audit
- separate reads, writes, sends, publishes, and system changes
- keep public actions behind explicit approval
- store run history for later review
- test draft-only versions before production
- use the latest ChatGPT model without building your own stack
New users can start with $2 credits, which is enough to run several permission audits before deciding which automations deserve implementation.
The takeaway
Do not ask, “Can AI do this?” first.
Ask:
What is this agent allowed to read, write, send, publish, or change?If the answer is clear, the automation can move forward.
If the answer is fuzzy, keep it in draft-only mode.