Claude Tag Has 3 Permission Levels Before You Enable It

By Lazar Milicevic · Published August 9, 2026 · 9 min read

Tagging Claude in Slack looks simple: mention it in a thread, ask for help, and get an answer where the conversation already happened. The problem starts when that same assistant can read customer data, draft a reply, update your CRM, and send the email without anyone checking the final action.

For a small business, the useful question is not “Can Claude work inside Slack?” It is: What is Claude allowed to see, propose, and change?

A 2-minute, 25-second Claude launch video has reached 77,540,570 views. The visible @Claude interaction gets the attention, but the permission model determines whether the workflow saves time or creates cleanup work.

Start with three permission levels: read, draft, execute

Every AI workflow should separate read-only context, draft creation, and external execution into different permission levels. Most small teams should begin at read-only, move to drafts after testing, and require explicit approval before the AI changes a customer record, sends a message, or touches money.

Here is the practical model.

This distinction matters because AI failures are often workflow failures, not language failures.

An AI can write a perfectly polite follow-up email based on stale CRM data. It can correctly summarize an invoice dispute while missing an attachment that changes the answer. It can update a deal stage exactly as instructed, even though the salesperson had already resolved the deal privately.

The model did what it was allowed to do. The system gave it too much authority.

What each level looks like in a real small-business workflow

• Read-only: Pull the last 20 messages from a shared inbox, retrieve the customer’s CRM record, list open invoices, and produce a 6-line summary.
• Draft: Generate a reply with recipients, subject line, message body, attached-file list, and suggested CRM note.
• Execute: Send the approved reply, add the CRM note, assign a follow-up task, and update the customer status.

Do not collapse these into one button labeled “handle this.”

A workflow that says “analyze this support request” is fundamentally different from a workflow that says “issue a refund and email the customer.” The second one needs stricter controls, clearer logs, and defined exceptions.

Level 1 is where you find the useful work safely

Read-only access is the safest starting point because the AI can reduce research and context-switching without changing your systems. It can gather information from Slack, Gmail, your CRM, files, and dashboards, then show a human what matters before any action happens.

This is where Claude Tag can be genuinely useful. The conversation already contains the problem, decisions, links, and people involved. Instead of opening a separate AI tab and manually copying messages, a team member can ask for a structured summary in the same thread.

A support lead might tag Claude with:

Summarize this issue. List the customer’s request, account status, promised next step, missing information, and anything that should block a reply.

The output should not be a vague paragraph. It should be an operational artifact.

Customer: Northwind Design
Issue: Duplicate charge reported for August subscription
Account status: Active, annual plan
Related invoice: INV-10482
Previous promise: Support said billing review would respond within 1 business day
Missing information: Last 4 digits of payment card not confirmed
Recommended next step: Ask billing to verify processor transaction ID before replying
Risk flag: Do not promise refund until duplicate charge is verified

That output saves the operator from searching five tabs. It does not send an email, modify a payment record, or create a refund.

For early workflows, scope the context aggressively. A support agent does not need access to every customer folder. A sales assistant does not need to read accounting data. An invoice-reminder workflow does not need to see payroll files.

Use a task-specific data contract:

workflow: overdue_invoice_review
allowed_sources:
  - accounting.invoices
  - crm.contacts
  - gmail.sent_messages
allowed_fields:
  - invoice_number
  - invoice_total
  - due_date
  - customer_name
  - customer_email
  - payment_status
  - prior_reminder_dates
blocked_fields:
  - bank_account_details
  - tax_identification_numbers
  - employee_records
allowed_actions:
  - summarize
  - flag_missing_data
  - suggest_next_step

The important part is not the YAML. The important part is deciding, before connecting tools, which information the workflow actually needs.

The NIST AI Risk Management Framework describes four core functions: “Govern, Map, Measure, and Manage.” For a five-person agency, that does not require an enterprise governance committee. It means writing down what the agent can access, what can go wrong, and who approves actions that matter.

Level 2 drafts remove repetitive work without removing judgment

Draft mode is usually the highest-return permission level for small teams because the AI completes the first pass while a human keeps control of the final decision. A good draft includes the proposed output, the source data used, and the exact action that would happen if approved.

This is where most teams should spend their first month.

Examples that work well:

• Draft overdue-invoice reminders from invoice status and prior emails
• Draft support replies from a customer’s thread and internal knowledge base
• Draft CRM notes after a sales call transcript
• Draft a daily operations report from inbox, calendar, and task data
• Draft follow-up tasks for leads that have been waiting more than 48 hours

The draft should be reviewable in under 60 seconds. If an operator needs to reopen four tools to verify every detail, your automation has only moved the work around.

Here is an approval payload for a customer email:

{
  "workflow_id": "invoice-reminder-01842",
  "action_type": "send_email",
  "status": "pending_approval",
  "source_records": [
    {
      "system": "accounting",
      "record": "INV-10482",
      "url": "https://accounting.example.com/invoices/INV-10482"
    },
    {
      "system": "crm",
      "record": "Northwind Design",
      "url": "https://crm.example.com/contacts/294"
    }
  ],
  "proposed_action": {
    "to": ["ap@northwinddesign.com"],
    "cc": [],
    "subject": "Reminder: Invoice INV-10482 is overdue",
    "body": "Hi Jamie, ...",
    "attachments": []
  },
  "approval_options": ["approve", "edit", "reject"]
}

That structure does three useful things:

1. It shows the reviewer exactly what will leave the company.
2. It links the source records used to make the draft.
3. It creates a durable log when someone approves, edits, or rejects it.

A plain Slack message saying “Draft ready — looks good?” is not enough for high-value workflows. The person approving needs to see the recipient, destination, current record state, proposed change, and relevant source evidence.

For a CRM update, show the field before and after:

Account: Northwind Design
Field: Deal stage
Current value: Discovery
Proposed value: Proposal sent
Evidence: Proposal PDF shared in Slack thread on Aug 8
Reviewer action: Approve / Edit / Reject

For an invoice, show customer, line items, amounts, tax fields, and total. For a refund, show the original charge, requested amount, reason, and order status.

Draft mode is not “AI with training wheels.” It is the operating model that lets a small team get value before it earns confidence.

Level 3 execution needs policy checks, not blind trust

Execution permission should be granted per action, per system, and per risk threshold—not as a blanket “autonomous agent” setting. Sending an internal task is different from emailing a customer, and emailing a customer is different from issuing a refund or changing an accounting record.

A useful execution policy has four checks:

1. Is this action allowed for this workflow?
2. Is the required source data present and recent?
3. Does the action exceed a financial or customer-impact threshold?
4. Has the right person approved it?

Here is a simple policy example:

def requires_approval(action):
    if action.type in ["send_email", "update_crm", "create_task"]:
        return True

    if action.type == "create_invoice":
        return True

    if action.type == "issue_refund":
        return True

    if action.type == "mark_invoice_paid":
        return True

    return False


def can_execute(action, approval):
    if requires_approval(action) and not approval.is_valid:
        return False, "Missing valid human approval"

    if action.type == "send_email" and not action.recipient_domain:
        return False, "Recipient is missing"

    if action.type == "update_crm" and action.current_value is None:
        return False, "Cannot update a field without current value"

    if action.type == "issue_refund" and action.amount_usd > 0:
        return False, "Refund requires finance approval"

    return True, "Allowed"

This is intentionally conservative. The point is not to create a perfect universal policy engine. The point is to prevent a workflow from treating every tool connection as permission to act.

Actions that should normally stop for approval

• Sending any customer-facing email for the first time in a workflow
• Changing a deal stage, owner, price, or contract status in a CRM
• Creating, editing, voiding, or marking an invoice as paid
• Issuing a refund, discount, credit, or payment request
• Deleting files, contacts, tasks, or records
• Adding external users to systems or changing access permissions
• Publishing content to a public website or social account

There are cases where execution can become automatic later. For example, a workflow may create an internal task every time a qualified lead submits a form. That is low-risk, reversible, and easy to audit.

But “later” matters. First, run it as a draft. Review enough examples to understand failure modes. Then automate the narrow action, not the entire process.

A good rule: automate the boring, reversible step first. Keep the expensive, customer-facing, or irreversible step behind approval.

For financial actions, tax records, invoices, refunds, and payment decisions, use your accounting professional’s guidance and verify current requirements with the relevant authority, such as the IRS. An AI workflow can organize data and prepare drafts; it should not replace professional financial or tax judgment.

Build the approval gate where your team already works

The approval interface should live in the tool your team checks reliably, but the approval record must be stored outside the chat message itself. Slack is one interface option, not the workflow architecture.

A four-person business can run this model through Slack, Microsoft Teams, Gmail, Telegram, a shared inbox, or a lightweight internal dashboard. The location matters less than the approval artifact.

Here is the architecture I use for practical business automation:

Incoming event
      |
      v
Collect minimum required context
      |
      v
AI summary + proposed action
      |
      v
Approval queue
      |
      +--> Approve --> policy check --> execute --> log result
      |
      +--> Edit ----> revised action --> policy check --> execute --> log result
      |
      +--> Reject --> log reason --> close or escalate

The approval queue needs an ID. The execution step should only accept that ID, not a copied Slack message or free-form “yes” reply.

For example:

POST /approvals/apr_01842/approve
{
  "reviewer_id": "user_27",
  "reviewer_role": "operations_manager",
  "approved_at": "2026-08-09T14:32:10Z",
  "approved_action_hash": "sha256:9f3d...",
  "notes": "Verified invoice and recipient"
}

The action hash is useful because it prevents a subtle failure: someone approves one draft, then the workflow changes the email body, recipient, or invoice total before sending.

If the action changes after approval, invalidate the approval and request a new one.

You also need idempotency. If Slack retries a webhook or someone clicks Approve twice, the workflow must not send two emails.

if action.execution_id in completed_execution_ids:
    return {"status": "skipped", "reason": "already_executed"}

execute_action(action)
completed_execution_ids.add(action.execution_id)

This is not advanced engineering. It is basic protection against duplicate actions in systems where retries are normal.

Audit logs turn AI mistakes into fixable workflow bugs

An approval-first workflow should log the input, generated draft, reviewer decision, final action, and result for every meaningful execution. Without that record,

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.