MWMS AI Tool Permission And Access Framework

System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Version: v1.3
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, Automation Brain, AIBS Brain, Data Brain, Risk Brain, Compliance Brain, AI Manager, AI Employee Router, Task Executor Systems, Client AIOS Systems
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-01
Source / Origin: MWMS AI Tool Permission And Access Framework v1.2 + AI Automations by Jack — AI Agents / n8n Client Automation Block
MWMS Classification: AI Tool Governance Framework / External Action Permission Standard / Automation Access Control Framework / Client AIOS Tool Risk Layer
Primary Brain: HeadOffice Brain
Supporting Brains: Automation Brain, AIBS Brain, Data Brain, Risk Brain, Compliance Brain, SIT Brain, Operations Brain, Sales Brain, Customer Brain, Content Brain, Research Brain, Product Brain
Related Pages: MWMS AI Agent Operations Core, MWMS AI Agent Memory And Context Framework, MWMS n8n Operating And Deployment Standard, MWMS Client Communication Automation Framework, MWMS Lead Intake Qualification And Follow-Up Automation Framework, MWMS Client Intelligence Report Automation Framework, MWMS Outbound Lead Enrichment And Cold Outreach Governance Framework, MWMS Market Driven Social Content Production Framework, MWMS Supabase RAG And Vector Memory Framework, MWMS AI Dashboard Capability Framework, MWMS AI Automation Security And Risk Checklist, MWMS Advanced AI Capability Activation Registry, MWMS Automation Build Planning Framework, MWMS Automation Client Demo And Handover Framework
Source Evidence: The latest absorbed course block introduced or strengthened workflows using n8n, Make, WhatsApp/Unipile, VAPI voice agents, GoHighLevel, Apollo, Appify, Anymailfinder, Fireflies, ElevenLabs, PDF.co, Placid, Gmail, Google Drive, Google Sheets, Airtable, Supabase, webhook bridges, self-hosted n8n, and AI app-builder front ends. These workflows require stronger tool permission rules because they can send messages, enrich personal data, scrape sources, generate client reports, create PDFs, access transcripts, run voice agents, trigger webhooks, and interact with customer/client data.

Purpose

The purpose of the MWMS AI Tool Permission And Access Framework is to define how MWMS controls which AI Employees, automations, workflows, Brains, dashboards, agents, and client AIOS systems may access tools, APIs, databases, files, communication channels, external systems, and live business actions.

This framework exists because AI becomes more powerful when connected to tools.

But tool access creates risk.

An AI Employee without tools can produce weak text.

An AI Employee with tools can:

send messages
email customers
update databases
access files
scrape websites
enrich prospect data
trigger workflows
generate PDFs
call voice agents
retrieve transcripts
update CRMs
post content
query Supabase
access client knowledge
create reports
influence sales decisions
affect customer experience
expose sensitive information

Therefore, MWMS must not treat tool access casually.

Tool access is authority.

This framework defines how that authority is granted, limited, reviewed, logged, escalated, and revoked.

Core Doctrine

The MWMS doctrine is:

AI Employees may only use tools that match their role, task, authority level, risk level, permission boundary, and approved business outcome.

A tool should not be connected just because it is available.

A tool should be connected only when:

the workflow requires it
the AI Employee role allows it
the data access is appropriate
the risk is known
the action is permitted
the output is logged
the failure path is defined
human review exists where needed
client data boundaries are protected

The stronger the tool, the stronger the permission rule.

Core Definition

Tool permission refers to the approved scope of access an AI Employee, automation, workflow, Brain, dashboard, agent, or AIOS system has to external systems, internal databases, APIs, files, communication channels, data sources, or execution actions.

Inside MWMS, tool access may include:

reading data
writing data
sending messages
generating files
creating reports
retrieving context
calling APIs
triggering workflows
updating CRM records
scraping public data
enriching prospect data
accessing transcripts
using voice tools
posting content
sending email
uploading files
downloading files
querying vector memory
creating dashboard items
routing tasks
calling another automation

MWMS Definition

An MWMS tool permission is:

A governed access boundary that defines what tool may be used, by whom, for what purpose, under what conditions, with what data, at what risk level, and with what logging, review, and failure controls.

Permission Hierarchy

MWMS recognises six permission levels.

Level 0: No Tool Access

The AI Employee may only reason or draft.

It cannot call tools, access databases, send messages, or trigger workflows.

Use For

brainstorming
early drafts
low-risk summaries
planning
internal thinking
non-operational writing

Rule

Default new AI Employees to Level 0 until tool need is proven.

Level 1: Read-Only Access

The AI Employee may retrieve or read approved information but cannot change anything.

Examples:

read approved MCR page
read Supabase record
retrieve RAG context
view CRM lead record
read Google Sheet row
read transcript
read dashboard data
inspect automation log

Rule

Read-only does not mean risk-free.

Reading sensitive data still requires permission.

Level 2: Draft-Only Output

The AI Employee may prepare content, reports, messages, proposals, emails, or records, but cannot send, publish, or write to live systems without human approval.

Examples:

draft email
draft proposal
draft report
draft social post
draft lead follow-up
draft WhatsApp response
draft client PDF
draft outbound email

Rule

Draft-only is the safest starting mode for client-facing AI.

Level 3: Controlled Write Access

The AI Employee or workflow may write to approved internal systems but not external customers or public channels.

Examples:

create Supabase task
update internal dashboard status
save draft report
write to Airtable/Google Sheet
create internal CRM note
store transcript summary
create approval queue item

Rule

Controlled writes require schema, owner, and rollback awareness.

Level 4: External Action With Approval

The workflow may prepare or queue external actions, but human approval is required before execution.

Examples:

send client report after review
send proposal after approval
send cold outreach after review
publish content after approval
respond to customer after human check
trigger voice campaign after approval
send PDF to client after review

Rule

Use Level 4 for high-value or high-risk external actions until the workflow is proven.

Level 5: Approved Autonomous External Action

The workflow may perform approved external actions without per-action human approval, but only inside a narrow, tested, logged, low-to-medium-risk scope.

Examples:

appointment reminder
approved FAQ chatbot answer
low-risk confirmation email
approved report notification
internal recurring digest
status update to approved client dashboard
simple approved WhatsApp confirmation

Rule

Level 5 requires proven workflow reliability, logging, fallback, and narrow scope.

Level 6: Restricted / Prohibited Without Executive Approval

The tool or action is too sensitive for normal automation.

Examples:

spending money
changing ad budgets
deleting records
sending high-volume cold outreach
issuing refunds
making legal/financial/medical claims
accessing credentials
modifying live infrastructure
publishing high-risk content
changing client billing
impersonating humans
accessing unrelated client data

Rule

Level 6 actions require explicit human authority and should usually remain blocked.

Default Permission Rule

The default MWMS permission state is:

No tool access unless the task requires it and the role is approved for it.

AI Employees must not gain tool access by default.

Access must be granted deliberately.

Tool Access Decision Questions

Before granting access, answer:

What tool is needed?
Why is the tool needed?
Which AI Employee or workflow needs it?
What Brain owns the workflow?
Is access read-only or write/action?
What data will be accessed?
Is client data involved?
Is personal data involved?
Is sensitive data involved?
Can the tool send external messages?
Can the tool change live systems?
Can the tool cost money?
Can the tool create reputation risk?
Is human approval needed?
What is logged?
What happens if the tool fails?
How is access revoked?

Rule

If these questions cannot be answered, tool access is not ready.

Tool Risk Classes

MWMS classifies tools by risk.

Class A: Low-Risk Internal Drafting Tools

Examples:

internal document draft generation
internal summarization
low-risk planning tools
local non-sensitive files

Risk

Low.

Rule

Still requires output review before becoming MCR or client-facing.

Class B: Internal Data Read Tools

Examples:

MCR retrieval
Supabase read-only query
dashboard read
approved Google Sheet read
approved Airtable read
RAG retrieval

Risk

Low to medium.

Rule

Check authority, freshness, and data sensitivity.

Class C: Internal Write Tools

Examples:

Supabase task creation
dashboard status update
internal report storage
Airtable/Google Sheet row update
MCR draft staging
workflow event logging

Risk

Medium.

Rule

Requires schema, ownership, and logging.

Class D: External Communication Tools

Examples:

Gmail
WhatsApp/Unipile
SMS tools
VAPI voice agents
chatbot responses
CRM email
GoHighLevel follow-up messages

Risk

High.

Rule

External communication requires approval, scope, tone, source knowledge, and logging.

Class E: Data Collection / Scraping / Enrichment Tools

Examples:

Apollo
Appify
Anymailfinder
LinkedIn/company data tools
Google Reviews scraping
website scraping
search scraping
lead enrichment tools

Risk

High.

Rule

Requires compliance review, source limits, data minimization, retention rule, and opt-out/suppression where outreach is involved.

Class F: File / Report Generation Tools

Examples:

PDF.co
Placid
Google Docs
Google Drive
file converters
PDF generators
ZIP/image tools
proposal generators

Risk

Medium to high.

Rule

Generated files can look official. Validate content and recipient before delivery.

Class G: AI Voice / Call Tools

Examples:

VAPI
voice agents
call transcription systems
call recording systems
ElevenLabs voice/dubbing where communication-related

Risk

High.

Rule

Requires consent/disclosure review, script boundaries, handoff, call logging, and post-call review.

Class H: AIOS / Automation Infrastructure Tools

Examples:

n8n
Make
webhooks
Coolify
self-hosted n8n
PostgreSQL
Supabase
API gateways
workflow-call systems

Risk

Medium to high.

Rule

Infrastructure tools require credential control, environment separation, logging, and deployment review.

Class I: Public Publishing / Paid Media Tools

Examples:

social schedulers
WordPress publishing
YouTube uploads
ad platforms
email broadcast tools
public-facing content systems

Risk

High.

Rule

Public outputs require compliance, brand, claim, and approval controls.

Class J: Financial / Billing / Spend Tools

Examples:

Stripe
PayPal
ad spend changes
client billing
refunds
payment systems

Risk

Very high.

Rule

Financial tools require explicit human approval and are blocked from normal autonomous AI use.

Tool-Specific Governance Updates From v1.3

The latest course block strengthens tool governance around the following tools and categories.

n8n

n8n is now treated as an advanced automation operating layer.

Allowed Uses

advanced workflow orchestration
AI agent workflows
webhook routing
Supabase/RAG workflows
report generation
client AIOS backend workflows
workflow-to-workflow calls
Make↔n8n bridges

Risks

exposed webhooks
credential leakage
client data mixing
workflow complexity
self-hosting maintenance
external actions
AI tool drift

Permission Rule

n8n workflows must define trigger, owner, tool access, data access, action boundary, logging, and failure path.

Make

Make remains approved for fast visual automations.

Allowed Uses

simple-to-medium workflow automation
existing working scenarios
visual client demos
fast operational workflows
webhook intake

Risks

scenario sprawl
weak logging if not designed
duplicate logic with n8n
hidden tool actions
accidental over-automation

Permission Rule

Do not rebuild working Make workflows into n8n unless n8n provides a real operational advantage.

Bridge first where safer.

Webhooks

Webhooks are system doorways.

Allowed Uses

form intake
app builder front-end calls
Make↔n8n bridging
chatbot messages
dashboard actions
CRM events
AIOS workflow triggers

Risks

unauthorized requests
spam
malformed payloads
prompt injection
workflow abuse
external action triggers

Permission Rule

Every serious webhook must define source, payload schema, method, authentication/secret, logging, and failure response.

WhatsApp / Unipile

WhatsApp automation is powerful but high-risk.

Allowed Uses

approved client inquiry workflow
support routing
approved group intelligence reports
lead follow-up where permission exists
appointment confirmation

Risks

responding to wrong chat
group privacy breach
unofficial provider dependency
account/session risk
personal data exposure
customer trust damage

Permission Rule

WhatsApp automation must filter by approved chat, contact, group, or workflow scope.

No automation may respond to every incoming WhatsApp message by default.

VAPI / Voice Agents

Voice tools are high-risk client communication systems.

Allowed Uses

AI receptionist prototypes
approved FAQ voice assistant
appointment confirmation
lead qualification
post-call intelligence
internal voice demos

Risks

consent/recording requirements
hallucinated spoken answers
poor escalation
customer frustration
sensitive data
brand trust damage

Permission Rule

Voice agents require approved scripts, knowledge sources, handoff logic, call logging, and risk escalation before customer use.

GoHighLevel

GoHighLevel may be used for forms, CRM, lead intake, and follow-up.

Allowed Uses

form intake
lead qualification workflows
CRM record creation
follow-up sequences
client sales workflows

Risks

noisy payloads
wrong field mapping
incorrect follow-up
consent issues
CRM pollution
client data exposure

Permission Rule

GoHighLevel payloads must be cleaned before AI qualification or follow-up actions.

Apollo

Apollo may be used for B2B prospect research where permitted.

Allowed Uses

target prospect research
job-title filtering
company list building
decision-maker identification

Risks

overcollection
cold outreach compliance
inaccurate data
platform terms
spam misuse

Permission Rule

Apollo data should be used only inside a defined target market, with compliance review before outreach.

Appify

Appify may be used for scraping and extraction workflows.

Allowed Uses

public business data extraction
competitor monitoring
review scraping
market research
source collection

Risks

platform terms
scraping failure
stale data
personal data collection
overcollection
unreliable actors

Permission Rule

Appify workflows require source review, collection limits, storage rules, and freshness timestamps.

Anymailfinder

Anymailfinder may be used for B2B email enrichment where appropriate.

Allowed Uses

finding missing business email
completing prospect research records
verified email enrichment

Risks

wrong email
personal data handling
deliverability risk
cold outreach compliance

Permission Rule

Email enrichment must include verification status, source record, and suppression/opt-out handling before outreach.

Fireflies

Fireflies may be used for meeting transcript retrieval.

Allowed Uses

sales call summaries
proposal drafting
client discovery analysis
onboarding notes
internal meeting intelligence

Risks

transcript privacy
consent
sensitive business data
incorrect proposal scope
wrong client transcript matching

Permission Rule

Transcript-to-proposal workflows require human approval before sending proposals, pricing, scope, or commitments.

ElevenLabs

ElevenLabs may be used for dubbing, voice output, or audio generation.

Allowed Uses

multilingual video repurposing
internal audio assets
client content localization
approved voice assets

Risks

voice rights
content translation accuracy
copyright/source content issues
misleading voice use
client approval

Permission Rule

Dubbing and voice outputs require source rights, language review, and client/public-use approval.

PDF.co

PDF.co may be used for PDF conversion, image conversion, PDF generation, or file utilities.

Allowed Uses

PDF report generation
PDF to image conversion
document utilities
client report production

Risks

sensitive files
wrong attachment
generated report appearing official
third-party file handling
file storage/privacy

Permission Rule

PDF workflows must validate file content, recipient, and sensitivity before external delivery.

Placid

Placid may be used for designed proposal or report generation.

Allowed Uses

proposal PDFs
branded client reports
image/report templates
designed deliverables

Risks

wrong client data in template
official-looking unapproved report
template errors
sensitive data exposure

Permission Rule

Designed deliverables require review before client send.

Gmail

Gmail may be used for email delivery.

Allowed Uses

internal notifications
approved client reports
approved proposal delivery
lead follow-up where consent exists
workflow alerts

Risks

wrong recipient
sensitive attachment
unapproved message
compliance breach
domain reputation damage

Permission Rule

External Gmail sends require recipient validation, content review where needed, and logging.

Google Drive

Google Drive may be used for file storage and retrieval.

Allowed Uses

report storage
generated file storage
transcript/document storage
course files
client deliverables
workflow file outputs

Risks

wrong sharing permissions
client data leakage
stale files
sensitive data storage
broken links

Permission Rule

File sharing permissions must be checked before sending links externally.

Google Sheets / Airtable

Sheets and Airtable may be used for lightweight databases and workflow staging.

Allowed Uses

lead records
prospect research
content ideas
report staging
approval queues
prototype databases
group chat IDs
client demo data

Risks

weak permissions
wrong row updates
stale records
client data mixing
unstructured scaling

Permission Rule

Sheets/Airtable are acceptable for prototypes and lightweight workflows, but serious AIOS data should move toward governed database structure.

Supabase

Supabase is a strategic MWMS data layer.

Allowed Uses

structured records
tasks/events
RAG/vector memory
client AIOS data
dashboards
workflow logs
knowledge retrieval

Risks

schema errors
wrong client data
RAG leakage
database writes without validation
source-of-truth confusion
sensitive data exposure

Permission Rule

Supabase access must define table, operation, client scope, schema, and logging.

AI App Builders / Lovable-Style Front Ends

AI app builders may be used for prototypes and front-end interfaces.

Allowed Uses

dashboards
intake forms
micro-apps
client demos
app prototypes
front-end workflow triggers

Risks

weak security
public endpoints
prototype mistaken for production
direct database exposure
unreviewed code
client data leakage

Permission Rule

AI app builder front ends must not connect to live client workflows without security, webhook, and data access review.

Permission Matrix

Tool / Category	Default Permission	Risk	Human Review Needed
Internal drafting	Level 0–2	Low	Before official use
MCR/RAG read	Level 1	Medium	If source conflict exists
Supabase read	Level 1	Medium	If sensitive/client data
Supabase write	Level 3	Medium-High	For schema/client changes
Gmail send	Level 4–5	High	Yes unless approved low-risk
WhatsApp send	Level 4–5	High	Yes until proven
Voice agent response	Level 4–5	High	Yes for launch
GoHighLevel update	Level 3–5	Medium-High	For live clients
Apollo/Appify/Anymailfinder	Level 1–4	High	Before outreach
Fireflies transcript	Level 1–2	Medium-High	Before proposal send
PDF/Placid generation	Level 2–4	Medium	Before delivery
n8n workflow trigger	Level 3–5	Medium-High	Depends on action
Public content publish	Level 4–5	High	Yes until proven
Financial/billing tools	Level 6	Very High	Always

External Action Rule

Any tool that sends information outside MWMS is an external action.

External actions include:

sending email
sending WhatsApp message
calling a customer
publishing content
sending report
sending proposal
posting to social media
updating client-facing dashboard
triggering customer-facing workflow
sending cold outreach

Rule

External actions require permission, logging, and review level appropriate to risk.

Client Data Rule

Any tool that accesses client data must define:

client owner
client ID or boundary
source system
allowed fields
allowed workflow
retention rule
human review requirement
cross-client isolation
deletion/offboarding process

Rule

Client data must never be casually shared across workflows, Brains, tools, or AI Employees.

Personal Data Rule

Personal data may include:

names
emails
phone numbers
LinkedIn URLs
transcripts
chat messages
customer reviews
CRM records
support tickets
voice recordings
call summaries
prospect records

Rule

Personal data use must be purpose-limited, minimized, permissioned, and logged where appropriate.

Scraping And Enrichment Rule

Tools that scrape or enrich data require special care.

Before use, define:

source
reason for collection
data collected
data excluded
terms/platform risk
storage location
retention period
outreach purpose if any
opt-out/suppression handling
human review requirement

Rule

Scraping and enrichment are not casual research when they involve people, prospects, customers, or client use.

Communication Tool Rule

Communication tools require stronger governance than internal tools.

Before AI can send or trigger communication, define:

recipient
purpose
message type
approved source knowledge
tone
risk category
review requirement
opt-out where relevant
escalation path
logs

Rule

AI must not communicate externally unless the communication path is approved.

Generated File Rule

Generated files can look official.

This includes:

PDFs
proposals
reports
ZIP files
images
transcripts
dubbed videos
client deliverables

Rule

Before external file delivery, validate file content, client identity, recipient, sensitivity, and approval state.

Voice And Call Tool Rule

Voice tools are high risk because the interaction happens live.

Voice workflows must define:

assistant role
script scope
approved knowledge
prohibited claims
consent/disclosure rule
call recording policy
handoff trigger
tool call boundary
post-call summary
error handling

Rule

Voice AI should launch in controlled mode before autonomous client deployment.

Webhook Tool Rule

Webhooks are workflow entry points.

Every serious webhook must define:

endpoint purpose
allowed method
source system
payload schema
authentication/secret
rate limits if possible
logging
error response
action boundary
test vs production URL

Rule

A webhook is a doorway.

Do not leave it unguarded.

Self-Hosted Tool Rule

Self-hosted infrastructure creates operational responsibility.

Self-hosted tools may include:

n8n
PostgreSQL
Coolify apps
future internal services
private AI tools

Before self-hosted deployment, define:

owner
VPS/domain
SSL/DNS
backup
update process
access control
monitoring
credentials
recovery path
data stored
client impact

Rule

Self-hosted tools are infrastructure and require maintenance discipline.

Human Approval Gates

Human approval is required before:

sending cold outreach
sending proposals
sending client reports with recommendations
publishing public content
launching voice agents
sending WhatsApp messages beyond approved simple flows
changing CRM pipeline rules
deleting records
changing financial/billing data
sending high-volume emails
using scraped/enriched personal data for outreach
connecting new client data sources
launching client-facing AIOS workflows

Rule

If an AI action can affect money, customers, reputation, compliance, or live systems, assume human approval is required until proven otherwise.

Logging Requirements

Tool use should be logged when it affects:

external communication
client data
workflow status
reports
proposals
lead records
prospect records
RAG retrieval
voice calls
WhatsApp messages
CRM updates
public content
generated files
dashboard actions
Supabase writes

A log should include:

tool used
workflow
AI Employee / automation
input
output
timestamp
client/user if relevant
success/failure
human approval state
source record
next action

Rule

Important tool use should leave an audit trail.

Tool Failure Handling

Tools fail.

A workflow must know what happens when a tool fails.

Failure may include:

API timeout
invalid credential
missing data
wrong payload
no matching record
webhook failure
email send failure
PDF generation failure
transcript retrieval failure
scraping failure
RAG no-result
voice tool call failure
WhatsApp send failure
file upload failure

Rule

Tool failure must not cause the AI to pretend success.

If a tool fails, the workflow must stop, retry, escalate, or use an approved fallback.

Access Revocation Rule

Tool access should be removed when:

workflow is retired
client offboards
employee role changes
tool is no longer needed
credential is exposed
abuse is detected
risk level changes
duplicate workflow is removed
project ends

Rule

Access that is no longer needed should not remain open.

Application To AI Employees

Each AI Employee role card should define:

approved tools
forbidden tools
read/write permissions
external action permissions
client data access
human review requirements
escalation rules
logging rules
failure behavior

Rule

No AI Employee should gain tools outside its role card.

Application To Automation Brain

Automation Brain must apply this framework to every serious automation.

Automation Brain owns:

tool mapping
workflow access boundaries
webhook access
API calls
credentials
workflow action risk
automation logs
failure paths

Automation Rule

A working automation is not complete until tool permissions are clear.

Application To AIBS Brain

AIBS Brain must apply this framework to all client systems.

AIBS systems may include:

communication tools
lead tools
client reporting tools
dashboard tools
CRM tools
outreach tools
voice tools
RAG tools
file/report tools

AIBS Rule

Client AIOS systems must be permissioned before they are sold, deployed, or scaled.

Application To Risk And Compliance Brain

Risk and Compliance Brain must review tools involving:

personal data
client data
external communication
scraping
enrichment
cold outreach
voice/calls
financial data
public content
sensitive claims
regulated industries
cross-client data
automated decisioning

Risk Rule

Tool access risk increases when the tool touches real people, real customers, real money, or real public output.

Application To Data Brain

Data Brain governs data access.

Data Brain should define:

tables
fields
schemas
client IDs
retention
source metadata
read/write access
data sensitivity
RAG retrieval permissions
dashboard data permissions

Data Rule

Tools that read or write data must follow data governance.

Application To SIT Brain

SIT Brain should test tool access.

SIT should test:

approved use
blocked use
wrong client
missing data
failed API
malformed webhook
wrong recipient
duplicate send
permission failure
no-answer fallback
sensitive data leakage
logging
human approval path

SIT Rule

Tool permission must be tested, not assumed.

Tool Permission Checklist

Before approving a tool, confirm:

Tool name
Workflow name
Owning Brain
AI Employee / automation using it
Purpose
Data accessed
Read/write/action level
Client data involved
Personal data involved
External action possible
Risk class
Human approval requirement
Credential storage method
Logging method
Failure handling
Revocation process
Compliance review required
SIT testing required
Owner assigned

Failure Modes

Failure Mode 1: Tool Added Because It Is Available

A tool is connected without a clear workflow need.

Correction:

Require purpose and permission level before connecting.

Failure Mode 2: Read Access Treated As Safe

AI reads sensitive data and leaks or misuses it.

Correction:

Classify data sensitivity before read access.

Failure Mode 3: AI Sends External Message Without Approval

AI sends email, WhatsApp, or voice response without proper review.

Correction:

External action requires permission level and logging.

Failure Mode 4: Wrong Client Data Used

Tool retrieves or writes to wrong client record.

Correction:

Add client ID filters and isolation testing.

Failure Mode 5: Scraping Becomes Overcollection

Workflow collects more personal/business data than needed.

Correction:

Apply source limits and data minimization.

Failure Mode 6: Generated PDF Looks Official But Is Wrong

AI-generated report/proposal is sent without review.

Correction:

Require validation before delivery.

Failure Mode 7: Webhook Exposed

External requests trigger workflow abuse.

Correction:

Add authentication, secrets, schema checks, and logs.

Failure Mode 8: Tool Failure Hidden

AI claims it retrieved or sent data when the tool failed.

Correction:

Tool failure must stop, retry, escalate, or fallback.

Failure Mode 9: Credentials Exposed

Secrets appear in prompts, screenshots, exports, or logs.

Correction:

Credential handling must be protected.

Failure Mode 10: Permission Drift

Tool access expands over time without updating role cards or standards.

Correction:

Review tool permissions after workflow changes.

Strategic Summary

The v1.3 update strengthens the MWMS AI Tool Permission And Access Framework for the more advanced client automation systems absorbed from AI Automations by Jack.

The latest block introduced many tools that can create real business value, but also real risk:

n8n
Make
WhatsApp/Unipile
VAPI
GoHighLevel
Apollo
Appify
Anymailfinder
Fireflies
ElevenLabs
PDF.co
Placid
Gmail
Google Drive
Airtable
Google Sheets
Supabase
webhooks
AI app-builder front ends

These tools are not just integrations.

They are authority layers.

They can access data, send messages, generate client deliverables, influence sales, affect customer experience, and expose sensitive information.

Therefore MWMS must treat tool access as governed permission.

The more powerful the tool, the stronger the boundary.

Final Standard

The MWMS standard is:

Tools are authority.
Authority must be permissioned.
Permission must match role, task, Brain, data, risk, and business outcome.
External actions require review, logging, and failure handling.
Client data requires isolation.
Scraping and enrichment require compliance review.
Generated files require validation.
Voice and messaging require handoff.
Webhooks require protection.

No AI Employee, automation, dashboard, chatbot, voice agent, RAG system, or client AIOS workflow should use a tool unless its permission boundary is clear.

Change Log

Version: v1.3
Date: 2026-06-01
Author: MWMS HeadOffice

Change:

Updated the MWMS AI Tool Permission And Access Framework using the AI Automations by Jack — AI Agents / n8n Client Automation block.

Expanded tool permission governance to cover newly absorbed or strengthened tool categories including:

n8n
Make
webhooks
WhatsApp / Unipile
VAPI / voice agents
GoHighLevel
Apollo
Appify
Anymailfinder
Fireflies
ElevenLabs
PDF.co
Placid
Gmail
Google Drive
Google Sheets
Airtable
Supabase
AI app builders / Lovable-style front ends

Added six permission levels:

Level 0: No Tool Access
Level 1: Read-Only Access
Level 2: Draft-Only Output
Level 3: Controlled Write Access
Level 4: External Action With Approval
Level 5: Approved Autonomous External Action
Level 6: Restricted / Prohibited Without Executive Approval

Added Tool Risk Classes A–J covering internal drafting tools, internal data read tools, internal write tools, external communication tools, scraping/enrichment tools, file/report generation tools, AI voice/call tools, AIOS/automation infrastructure tools, public publishing/paid media tools, and financial/billing tools.

Added tool-specific governance sections for n8n, Make, webhooks, WhatsApp/Unipile, VAPI, GoHighLevel, Apollo, Appify, Anymailfinder, Fireflies, ElevenLabs, PDF.co, Placid, Gmail, Google Drive, Google Sheets/Airtable, Supabase, and AI app-builder front ends.

Added permission matrix, External Action Rule, Client Data Rule, Personal Data Rule, Scraping And Enrichment Rule, Communication Tool Rule, Generated File Rule, Voice And Call Tool Rule, Webhook Tool Rule, Self-Hosted Tool Rule, Human Approval Gates, Logging Requirements, Tool Failure Handling, Access Revocation Rule, Tool Permission Checklist, and expanded failure modes.

Mapped responsibilities across AI Employees, Automation Brain, AIBS Brain, Risk Brain, Compliance Brain, Data Brain, and SIT Brain.

Purpose of update:

To strengthen MWMS tool governance after absorbing advanced n8n/client automation workflows that connect AI systems to communication channels, CRMs, prospect databases, scraping tools, enrichment tools, voice agents, report generators, file systems, Supabase, dashboards, webhooks, and client-facing AIOS workflows.

Version: v1.2
Date: 2026-05-31
Author: MWMS HeadOffice

Change:

Expanded the MWMS AI Tool Permission And Access Framework after earlier AI Automations by Jack material, strengthening tool permission rules for AI Operating Systems, advanced automation workflows, context-aware AI Employees, workflow tools, and client-facing automation systems.

Purpose of update:

To align tool governance with the growing MWMS direction toward AI Employees, AIOS systems, automation workflows, and client-facing AIBS packages.

Version: v1.0 / v1.1**
Date: Prior Drafts
Author: MWMS HeadOffice

Change:

Created and refined the original MWMS AI Tool Permission And Access Framework to define how AI Employees and MWMS workflows should access tools, APIs, databases, files, and external systems inside governed permission boundaries.

Purpose of creation:

To prevent AI Employees and automations from using tools without role clarity, authority limits, human approval where required, logging, and risk controls.