System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, MWMS Brain, Brain Room, AI Manager, AI Employee Router, Task Executor Systems, Newsletter Intelligence, Course Absorption System, Opportunity System, AI Business Systems Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR

Purpose

The purpose of this document is to define the MWMS AI Tool Permission And Access Framework.

This framework establishes how MWMS governs tool access for AI Employees, agentic workflows, Brain workflows, task systems, automations, reporting systems, and future AIBS client systems.

As MWMS becomes more powerful, AI Employees may eventually interact with tools such as Gmail, Supabase, WordPress, Make.com, n8n, Google Sheets, Google Drive, OpenAI, Claude, Gemini, dashboards, APIs, client systems, and internal databases.

Tool access creates power.

Power creates risk.

Therefore, tool access must be controlled.

An AI Employee should never receive tool access simply because a tool is available.

Tool access must match:

role
task
Brain ownership
authority level
risk level
validation maturity
human review requirement
logging capability
business purpose

This framework exists to make sure MWMS AI Employees use tools safely, deliberately, and within governed boundaries.

Scope

This framework applies to all MWMS AI Employees, workflows, Brains, automations, task systems, dashboards, and future client-facing AI systems that may use tools, integrations, databases, APIs, files, applications, or external systems.

This includes tool access related to:

Gmail
Supabase
WordPress
Make.com
n8n
Google Sheets
Google Drive
Google Calendar
Google Ads
BeMob
OpenAI
Claude
Gemini
web search
uploaded files
local files
dashboards
APIs
internal Brain pages
MCR pages
client systems
future AIBS systems

This framework applies before granting, expanding, automating, or trusting any AI tool access.

Core Definition

AI Tool Permission is the approved boundary that defines what an AI Employee or AI workflow may access, read, write, change, trigger, send, create, delete, or execute.

Tool permission includes:

what tool may be used
what level of access is allowed
whether access is read-only or write-capable
whether human approval is required
whether output must be validated first
whether the action must be logged
whether the tool can affect live systems
whether the tool can affect external parties
whether the tool can affect money, compliance, client data, or public content

Tool permission is not only technical.

It is operational governance.

Core Principle

The core principle of this framework is:

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

This protects MWMS from:

unsafe automation
accidental live system changes
database corruption
wrong emails being sent
dashboard noise
external communication errors
client data mistakes
financial mistakes
compliance issues
hallucinated tool usage
vague developer instructions
AI acting beyond its role
premature autonomous workflows

Tool access must be earned by workflow maturity.

Tool Access Permission Levels

MWMS should classify tool access into permission levels.

Level 0 — No Tool Access

The AI Employee has no access to external tools.

Allowed:

reasoning from provided context
drafting
internal analysis
low-risk advisory work

Examples:

brainstorming
rough planning
internal strategy draft

Use when:

role is early concept
input is provided manually
no external action is needed

Level 1 — Provided Input Only

The AI Employee may use only the material provided in the current task.

Allowed:

uploaded files
pasted text
screenshots
user instructions
supplied data

Not allowed:

web search
database access
Gmail access
WordPress access
external tool use
live system assumptions

Use when:

source material is enough
task is manual
output is draft or advisory

Example:

Course Absorption Agent reviewing uploaded transcripts.

Level 2 — Read Only Reference Access

The AI Employee may read from approved sources but cannot change anything.

Allowed examples:

read MCR page content
read Supabase rows
read Gmail messages
read Google Sheet rows
read dashboard data
read uploaded files
read web sources where approved

Not allowed:

write
update
delete
send
publish
create live records
trigger automations

Use when:

AI needs evidence
current state must be checked
output will be reviewed by a human

Example:

Research Agent reading sources before preparing a report.

Level 3 — Draft Creation Access

The AI Employee may create drafts but cannot execute final actions.

Allowed examples:

create draft report
create draft task
create draft email
create draft MCR page output
create draft dashboard candidate
create proposed Supabase record for review
create proposed developer brief

Not allowed:

send email
publish page
write final database row without review
trigger live automation
approve spend
update live systems

Use when:

AI prepares work for human approval

Example:

Brain Room Task Builder Agent creating a task draft.

Level 4 — Controlled Write Access

The AI Employee may write to approved systems inside a controlled workflow.

Allowed examples:

insert newsletter intelligence row into Supabase
update internal queue status
add low-risk label
create internal task record
update non-public status field
log validation result

Requirements:

approved workflow
required fields
validation rules
logging
failure handling
human review for important downstream action

Not allowed:

irreversible changes
external communication
public publishing
financial approval
client-facing final action
live system code changes

Use when:

workflow has proven stability
write action is low to medium risk
logs are reliable

Example:

Newsletter workflow inserting extracted intelligence into a review table.

Level 5 — Supervised External Action Access

The AI Employee may prepare or trigger external actions only after human approval.

Allowed examples:

prepare email for approval
prepare client report for approval
prepare WordPress update for review
prepare Google Ads change recommendation
prepare task assignment for M
prepare client workflow output

Human approval required before execution.

Use when:

action affects external parties
action affects public systems
action affects client-facing output
action affects business decisions

Example:

AI drafts an email but Martyn approves before sending.

Level 6 — Restricted Autonomous Access

The AI Employee may perform low-risk actions without immediate human approval inside tightly defined boundaries.

Allowed examples:

apply internal labels
format internal records
classify low-risk items
update routine status fields
create internal logs
normalize non-sensitive internal text

Requirements:

low risk
proven workflow
stop conditions
logs
review sampling
clear rollback where possible
HeadOffice visibility

Not allowed:

high-risk decisions
live system changes
external communication
paid traffic action
financial action
compliance-sensitive action
public publishing
client final delivery

Use rarely.

Tool Access Types

MWMS should separate tool access by action type.

1. Read Access

The AI Employee may view or retrieve information.

Examples:

read Gmail
read Supabase rows
read Google Sheet
read WordPress page
read uploaded file
read dashboard data

Risk:

privacy
outdated data
misreading source
overclaiming certainty

Required controls:

source identification
context preservation
freshness check where needed
no write action

2. Draft Access

The AI Employee may prepare something but not send, publish, or save final.

Examples:

draft email
draft MCR page
draft task
draft report
draft developer brief

Risk:

user mistakes draft for final
weak draft becomes operational
missing validation

Required controls:

label as draft
human review
validation state

3. Write Access

The AI Employee may create or update internal records.

Examples:

Supabase insert
queue update
status field update
internal log creation

Risk:

bad data
duplicate records
wrong status
misleading dashboards

Required controls:

schema validation
required fields
logging
failure handling
review path

4. Modify Access

The AI Employee may change existing content or system state.

Examples:

update WordPress page
edit Supabase row
change Google Sheet record
change workflow status

Risk:

overwriting good data
breaking source of truth
damaging live system
losing audit trail

Required controls:

human approval
backup or rollback where possible
event log
validation
exact change record

5. External Action Access

The AI Employee may affect external people, public systems, paid platforms, or clients.

Examples:

send email
publish page
launch campaign
send client report
trigger public automation
update live website content

Risk:

public error
financial loss
compliance issue
reputational damage
client trust damage

Required controls:

human approval
validation
risk review
logging
clear owner

6. Delete Access

The AI Employee may delete, archive, remove, or mark items as no longer active.

Examples:

delete email
archive task
remove row
trash WordPress page
remove file
reject queue item

Risk:

data loss
lost evidence
wrong deletion
audit failure

Required controls:

human approval for anything important
reversible archive preferred over delete
event log
reason required

Default rule:

AI should archive or park before delete whenever possible.

Tool Risk Categories

Tools should be classified by risk.

Low Risk Tools

Examples:

internal draft tools
temporary notes
formatting tools
local analysis of provided input
non-public document drafts

Use:

safe for early AI Employee testing

Medium Risk Tools

Examples:

internal Supabase review tables
internal queues
dashboard candidate records
Google Sheets used for internal tracking
Gmail read access
MCR read access

Use:

allowed with validation and logging

High Risk Tools

Examples:

WordPress write access
Supabase production writes
Gmail send
Google Ads recommendations
client data systems
finance records
M developer task systems

Use:

human review required
strict permission boundaries

Critical Risk Tools

Examples:

live code changes
database schema changes
paid traffic launch
financial transactions
public publishing
external client delivery
legal/compliance-sensitive action
irreversible deletes

Use:

no autonomous access
explicit human approval
named owner
logging required
rollback awareness where possible

AI Employee Tool Permission Record

Every operational AI Employee should eventually have a Tool Permission Record.

AI Employee Name:
Owning Brain:
Authority Level:
Approved Tools:
Access Level Per Tool:
Read Permissions:
Draft Permissions:
Write Permissions:
Modify Permissions:
External Action Permissions:
Delete Permissions:
Forbidden Tools:
Human Approval Required:
Validation Required:
Logging Required:
Risk Level:
Stop Conditions:
Escalation Path:
Review Frequency:

Tool Permission Examples

Example 1: Newsletter Signal Extraction Agent

Approved Tools:

Gmail input
OpenAI processing
Supabase newsletter intelligence table

Access Level:

Gmail: read source email only
OpenAI: process content
Supabase: controlled write to approved review table

Allowed:

extract newsletter signal
create structured row
classify Brain
assign action type
send to review queue

Forbidden:

send emails
create downstream Brain tasks without review
update MCR
update live dashboards outside approved display logic
mark weak signals as urgent without evidence

Human Approval Required:

before downstream action
before new Brain task creation

Logging Required:

Example 2: Course Absorption Agent

Approved Tools:

uploaded files
current conversation context
existing MWMS standards where available

Access Level:

provided input only unless otherwise approved

Allowed:

read course files
extract MWMS value
draft MCR page output
recommend absorb, park, or ignore

Forbidden:

save directly to MCR
create live WordPress pages
modify registries automatically
invent course content
absorb weak material

Human Approval Required:

before MCR save
before registry update

Logging Required:

yes when absorbed

Example 3: Brain Room Task Builder Agent

Approved Tools:

Brain Room message read
task draft creation where workflow permits

Access Level:

read Brain Room
draft task only

Allowed:

classify request
identify owning Brain
create Agentic Work Unit draft
flag risk and review need

Forbidden:

execute task directly
write live system changes
assign to M’s active build without approval
bypass AI Manager
create high-risk tasks without review

Human Approval Required:

medium and high-risk tasks

Logging Required:

Example 4: Developer Support Agent

Approved Tools:

uploaded plugin files
screenshots
file content provided by user
visible WordPress/admin evidence

Access Level:

read/provided input
draft instructions only

Allowed:

prepare exact developer instructions
create full file output where requested
identify file path if provided
define test steps

Forbidden:

change live code directly
guess file paths
instruct vague search-and-replace
ignore screenshots
touch unrelated systems
bypass M review

Human Approval Required:

always

Logging Required:

yes for meaningful dev changes

Example 5: AIBS Client Reporting Agent

Approved Tools:

approved client data source
internal reporting template
client workflow output

Access Level:

read approved client data
draft report

Allowed:

create client report draft
summarize findings
recommend action
flag approval need

Forbidden:

send final report without approval
make unsupported claims
modify client systems
access unrelated client data
make legal or financial commitments

Human Approval Required:

before client delivery

Logging Required:

Tool Permission Checklist

Before granting tool access, check:

Which AI Employee needs the tool?
Which Brain owns the Employee?
What task requires the tool?
Is the tool necessary?
Is read-only enough?
Is draft-only enough?
Is write access actually needed?
Could the same outcome be achieved with lower permission?
What risk does the tool create?
Is human approval required?
Is validation required?
Is logging available?
Are forbidden actions defined?
Are stop conditions defined?
Is escalation path defined?
Does tool use affect live systems?
Does tool use affect external people?
Does tool use affect money or compliance?
Does tool use affect M’s active build?
Is this workflow mature enough for tool access?

Default rule:

Grant the lowest permission level that allows the task to be completed safely.

Tool Permission Failure Modes

MWMS must watch for tool permission failure.

Common failure modes include:

AI claims it checked a tool it did not access
AI assumes live data without verification
AI writes to a system before validation
AI creates dashboard noise
AI sends or prepares external communication without approval
AI suggests modifying WordPress without exact context
AI changes records without logging
AI deletes instead of parking
AI uses tool access outside role boundary
AI accesses sensitive data unnecessarily
AI creates downstream actions without review
AI confuses draft creation with execution
AI recommends automation before tool risk is understood
AI gives M instructions based on guessed file state
AI interacts with client systems without approval gates

Any tool permission failure should be logged if operationally important.

Human Approval Requirements

Human approval is mandatory before AI can:

send external emails
publish public content
edit MCR canon
update live WordPress pages
change plugin code
change Supabase schema
approve paid traffic
launch or change ads
make financial commitments
deliver client-facing reports
perform irreversible deletion
access high-risk client data
change live automation logic
modify M’s active build area
perform compliance-sensitive actions

Human approval may be optional for low-risk internal classification, formatting, drafting, or logging.

Tool Access Stop Conditions

AI tool use must stop when:

required input is missing
confidence is low
source is incomplete
validation fails
risk level increases
tool permission is unclear
action becomes external
action affects live system
action affects money
action affects compliance
action affects client output
action touches M’s active build
unexpected data appears
system error occurs
duplicate records appear
workflow loops
human approval is required but not present

Stop condition rule:

When tool risk becomes unclear, stop and escalate.

Tool Access Logging

Important tool use must be logged.

A Tool Access Log may include:

AI Employee:
Tool Used:
Access Type:
Task:
Source:
Action Taken:
Result:
Validation Status:
Human Approval:
Risk Level:
Error State:
Next Action:
Timestamp:

Logging supports auditability, debugging, and future automation readiness.

Tool Access And M Build Relevance

This framework is highly relevant to M’s future build work.

Later, it may inform:

AI Employee router permissions
task executor permissions
Supabase role design
WordPress plugin access rules
Brain Room action restrictions
AI Manager tool routing
employee capability tables
tool access logs
dashboard permission indicators
client workflow permissions

For now, this is MCR governance.

It should not trigger immediate development changes unless a separate developer brief is created.

Tool Access And AIBS Client Systems

This framework is essential for future client-facing AI Business Systems.

AIBS systems must be able to explain:

what each AI Employee can access
what each AI Employee cannot access
what requires client approval
what is logged
what is automated
what is only drafted
what is reviewed by a human
what happens if something fails

This will be important for client trust.

AIBS rule:

Client AI systems must use permissioned workflows, not open-ended AI access.

Governance Role

HeadOffice owns the MWMS AI Tool Permission And Access Framework.

HeadOffice is responsible for:

defining tool permission levels
approving tool access expansion
preventing unsafe access
ensuring write access is controlled
ensuring external action requires approval
ensuring logs exist for important tool use
protecting live systems
protecting M’s active build areas
protecting client systems
preventing AI Employees from exceeding role boundaries

Individual Brains may request tool access for their AI Employees, but HeadOffice governs cross-system, high-risk, write, external, and client-facing permissions.

Relationship To Other MWMS Standards

This framework supports and must align with:

MWMS AI Agent Operations Core
MWMS Agentic Work Unit Standard
MWMS AI Employee Role Card Standard
MWMS AI Agent Orchestration Framework
MWMS AI Workflow Pipeline Standard
MWMS AI Output Validation Standard
MWMS Messy Input Normalization Framework
MWMS Agentic Reporting Standard
MWMS AI Employee Handoff Protocol
MWMS AI Agent Failure Handling And Escalation Protocol
MWMS AI Agent Outcome Measurement Framework
MWMS AI Agent Operations Core Page Registry
MWMS AI Agent Deployment Readiness Checklist
MWMS AI Employee Capability Stack Framework
MWMS Brain Routing Rule
MWMS Brain To Brain Request Protocol
MWMS Supabase Event Schema
MWMS System Data Flow Map
AI Business Systems Brain Blueprint

This framework defines the permission boundaries required before AI Employees can safely use tools inside those workflows.

Drift Protection

This framework protects MWMS from the following forms of drift:

Giving AI tools because they are available rather than necessary
Allowing AI to write before workflow maturity
Allowing external action without human approval
Allowing tool use without logging
Treating draft creation as execution
Allowing AI to claim tool access it did not have
Allowing AI to assume live system state
Giving one AI Employee too many tools
Allowing client systems to run without permission gates
Allowing M’s active build areas to be affected by unmanaged AI action
Allowing write permissions without validation
Allowing delete actions where parking or archiving is safer
Allowing tool access to expand without governance review
Confusing automation capability with safe operation
Letting AI become powerful before it becomes reliable

Any AI Employee or workflow with unclear tool permissions should remain draft, manual, or read-only.

Architectural Intent

The architectural intent of the MWMS AI Tool Permission And Access Framework is to make AI power controllable.

As MWMS grows, AI Employees will become more capable.

They may read, write, route, report, classify, draft, validate, and eventually execute controlled actions.

That power must be governed.

The long-term goal is that every AI Employee tool interaction can answer:

Why does this Employee need this tool?
What level of access is allowed?
Is read-only enough?
Is draft-only enough?
Is write access justified?
Is human approval required?
Is validation required?
Is the action logged?
What risk does the tool create?
What must the AI never do?
What happens if the tool action fails?
Who owns the permission boundary?

When MWMS can answer those questions, it can safely expand AI capability without losing control.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Tool Permission And Access Framework as the governance framework for controlling AI Employee access to tools, systems, APIs, databases, files, dashboards, email, WordPress, Supabase, Make.com, n8n, Google Sheets, Google Drive, paid platforms, client systems, and future AIBS workflows.

This framework extends the MWMS AI Employee Capability Stack Framework by defining permission levels, access types, tool risk categories, tool permission records, examples, approval requirements, stop conditions, logging, M build relevance, AIBS client relevance, and drift protection.