MWMS MCR

MWMS AI Tool Permission Record Template

System: MWMS
Document Type: Operational Template
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 Record Template.

This template is used to define exactly what tools, systems, platforms, files, APIs, databases, dashboards, emails, documents, client records, or external actions an AI Employee is allowed to access or use.

MWMS must not give AI Employees tool access casually.

Tool access creates operational power.

Operational power creates risk.

A tool permission record makes clear:

  • which AI Employee needs the tool
  • why the tool is needed
  • what the AI Employee may do with the tool
  • whether access is read-only, draft-only, write-capable, or external-action capable
  • what the AI Employee must never do
  • whether human approval is required
  • whether validation is required
  • whether logging is required
  • what risk level applies
  • when tool use must stop
  • who owns the permission boundary

This is the practical daily-use version of the MWMS AI Tool Permission And Access Framework.

Scope

This template applies whenever MWMS considers, grants, reviews, limits, expands, or removes tool access for an AI Employee, workflow, automation, Brain process, task system, dashboard process, or future AIBS client workflow.

This includes tools and systems such as:

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

This template may be used manually first.

Later, parts of this template may become fields inside AI Manager, AI Employee Router, Task Executor systems, Brain Room, Supabase permission records, HeadOffice dashboards, or future AIBS client admin systems.

Core Definition

An AI Tool Permission Record is the structured permission profile that defines how an AI Employee may use a tool.

It answers:

  • What tool is being used?
  • Which AI Employee is using it?
  • What is the approved access level?
  • Can the AI only read?
  • Can the AI draft?
  • Can the AI write?
  • Can the AI modify?
  • Can the AI send, publish, trigger, or delete?
  • What requires human approval?
  • What must be validated?
  • What must be logged?
  • What must the AI never do?

A tool permission record protects MWMS from uncontrolled AI action.

Core Principle

The core principle of this template is:

Grant the lowest level of tool access required to complete the task safely.

If read-only access is enough, do not grant write access.

If draft-only access is enough, do not grant external action access.

If human review is required, do not allow autonomous action.

If the workflow has not been proven manually, do not automate tool use.

AI Tool Permission Record Template

1. Permission Record Title

Field:
Permission Record Title:

Purpose:
Gives the permission record a clear name.

Good Examples:

  • Newsletter Signal Extraction Agent Gmail Read Permission
  • Newsletter Signal Extraction Agent Supabase Controlled Write Permission
  • Course Absorption Agent Uploaded File Permission
  • Brain Room Task Builder Agent Task Draft Permission
  • Developer Support Agent Provided File Review Permission
  • AIBS Client Reporting Agent Client Data Read Permission

Bad Examples:

  • Tool Access
  • AI Permission
  • Gmail
  • Supabase
  • Access

Rule:
The title should name the AI Employee, tool, and access purpose.

2. AI Employee Name

Field:
AI Employee Name:

Purpose:
Identifies which AI Employee this permission applies to.

Examples:

  • Course Absorption Agent
  • Newsletter Signal Extraction Agent
  • Brain Room Task Builder Agent
  • HeadOffice Validation Agent
  • Offer Evaluation Agent
  • Research Evidence Collection Agent
  • Finance Break Even Analysis Agent
  • Developer Support Agent
  • AIBS Client Reporting Agent

Rule:
Tool permission must belong to a defined role, not generic AI.

3. Owning Brain

Field:
Owning Brain:

Purpose:
Identifies which Brain owns the AI Employee and the permission boundary.

Examples:

  • HeadOffice Brain
  • Affiliate Brain
  • Research Brain
  • Finance Brain
  • Experimentation Brain
  • Content Brain
  • Ads Brain
  • Operations Brain
  • AI Business Systems Brain

Rule:
Every tool permission must have an owner.

4. Supporting Brains Affected

Field:
Supporting Brains Affected:

Purpose:
Lists any Brains that may be affected by the tool access.

Examples:

  • Newsletter permissions may affect HeadOffice Brain, Ads Brain, Content Brain, Affiliate Brain, Research Brain
  • Offer permissions may affect Affiliate Brain, Research Brain, Finance Brain, Ads Brain, Experimentation Brain
  • Developer permissions may affect HeadOffice Brain, Operations Brain, Dev Console, Brain Room

Rule:
Cross-Brain effects must be visible.

5. Tool Or System Name

Field:
Tool Or System Name:

Purpose:
Names the tool, platform, database, file type, or system.

Examples:

  • Gmail
  • Supabase
  • WordPress
  • MCR
  • mwmsbrain.site
  • mwmsheadofficebrain.site
  • Make.com
  • n8n
  • Google Sheets
  • Google Drive
  • Google Ads
  • BeMob
  • uploaded files
  • web research
  • Brain Room
  • HeadOffice Dashboard
  • client CRM
  • client document repository

Rule:
The tool must be named clearly.

6. Tool Category

Field:
Tool Category:

Recommended Values:

  • Email
  • Database
  • Website
  • MCR
  • Brain Site
  • Automation Platform
  • Spreadsheet
  • File Storage
  • Ads Platform
  • Analytics Platform
  • Dashboard
  • API
  • Uploaded File
  • Web Source
  • Client System
  • Internal Task System
  • Other

Rule:
The category helps assess risk.

7. Permission Purpose

Field:
Permission Purpose:

Purpose:
Explains why the AI Employee needs this tool.

Examples:

  • read newsletter source emails
  • insert structured newsletter intelligence rows
  • review uploaded course transcripts
  • draft Brain Room task records
  • read WordPress page titles for duplicate cleanup
  • prepare developer handoff from provided file content
  • read offer source data
  • create internal validation record
  • prepare client report draft

Rule:
If the purpose is unclear, permission should not be granted.

8. Approved Access Level

Field:
Approved Access Level:

Recommended Values:

  • Level 0 — No Tool Access
  • Level 1 — Provided Input Only
  • Level 2 — Read Only Reference Access
  • Level 3 — Draft Creation Access
  • Level 4 — Controlled Write Access
  • Level 5 — Supervised External Action Access
  • Level 6 — Restricted Autonomous Access

Rule:
Use the lowest level that gets the job done safely.

Access Level Definitions

Level 0 — No Tool Access

The AI Employee may not access tools.

Allowed:

  • think from current instruction
  • provide advisory output
  • draft from provided context

Not allowed:

  • read external sources
  • write records
  • send, publish, trigger, delete, or modify

Level 1 — Provided Input Only

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

Allowed:

  • uploaded files
  • pasted text
  • screenshots
  • user-provided data
  • current conversation context

Not allowed:

  • live system access
  • database access
  • email access
  • web research unless separately approved
  • writes or external actions

Level 2 — Read Only Reference Access

The AI Employee may read approved sources.

Allowed:

  • read Gmail messages
  • read Supabase rows
  • read WordPress page data
  • read Google Sheet rows
  • read dashboard records
  • read approved web sources
  • read uploaded files

Not allowed:

  • write
  • update
  • delete
  • send
  • publish
  • trigger automation

Level 3 — Draft Creation Access

The AI Employee may create drafts for human review.

Allowed:

  • draft email
  • draft task
  • draft report
  • draft MCR page output
  • draft dashboard candidate
  • draft client report
  • draft handoff package

Not allowed:

  • send final
  • publish final
  • write approved records without review
  • execute live actions

Level 4 — Controlled Write Access

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

Allowed:

  • insert approved internal row
  • update low-risk internal status
  • create internal queue item
  • add internal log
  • write validation result

Requirements:

  • schema known
  • required fields known
  • validation rule present
  • logging present
  • human review for downstream action

Not allowed:

  • external action
  • public publishing
  • financial action
  • live code change
  • irreversible delete
  • client final delivery

Level 5 — Supervised External Action Access

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

Allowed:

  • prepare email for approval
  • prepare public content for approval
  • prepare client report for approval
  • prepare Google Ads change recommendation
  • prepare WordPress update for approval

Not allowed without human approval:

  • send
  • publish
  • launch
  • spend
  • modify client systems
  • perform irreversible actions

Level 6 — Restricted Autonomous Access

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

Allowed:

  • apply internal labels
  • format internal records
  • update routine low-risk statuses
  • create internal logs
  • classify low-risk items

Requirements:

  • low risk
  • proven workflow
  • strong logs
  • stop conditions
  • review sampling
  • HeadOffice visibility

Not allowed:

  • high-risk action
  • external communication
  • paid traffic
  • live code
  • financial action
  • client final delivery
  • compliance-sensitive action

9. Access Type Allowed

Field:
Access Type Allowed:

Recommended Values:

  • None
  • Read
  • Draft
  • Write
  • Modify
  • External Action
  • Delete
  • Archive
  • Label
  • Trigger
  • Execute

Rule:
Be specific. “Tool access” is too vague.

10. Read Permission

Field:
Read Permission: Yes / No

Purpose:
Defines whether the AI Employee can view or retrieve information.

If Yes, specify:

  • what it can read
  • from where
  • under what conditions
  • whether current verification is required

Rule:
Read access still creates privacy and source-risk concerns.

11. Draft Permission

Field:
Draft Permission: Yes / No

Purpose:
Defines whether the AI Employee can prepare draft outputs.

Examples:

  • draft report
  • draft email
  • draft MCR page
  • draft task
  • draft dashboard item
  • draft client report

Rule:
Drafts must be clearly marked as drafts until approved.

12. Write Permission

Field:
Write Permission: Yes / No

Purpose:
Defines whether the AI Employee can create new internal records.

Examples:

  • Supabase row
  • task record
  • validation record
  • failure log
  • outcome log
  • queue item

Rule:
Write permission requires validation, logging, and a known schema.

13. Modify Permission

Field:
Modify Permission: Yes / No

Purpose:
Defines whether the AI Employee can update existing content or system state.

Examples:

  • update row
  • change status
  • edit page draft
  • update task status
  • modify dashboard item

Rule:
Modify permission is higher risk than write permission and usually requires human review.

14. External Action Permission

Field:
External Action Permission: Yes / No

Purpose:
Defines whether the AI Employee may affect external people, public systems, paid platforms, or client systems.

Examples:

  • send email
  • publish page
  • launch ad
  • update public content
  • send client report
  • trigger public automation

Rule:
External action requires human approval by default.

15. Delete Permission

Field:
Delete Permission: Yes / No

Purpose:
Defines whether the AI Employee can delete, trash, remove, or permanently alter access to records or content.

Default:
No.

Rule:
AI should park or archive before delete wherever possible.

Delete permission should be rare and human-approved.

16. Archive Or Park Permission

Field:
Archive Or Park Permission: Yes / No

Purpose:
Defines whether the AI Employee may move items to a lower-risk inactive state.

Examples:

  • park weak newsletter item
  • archive low-value input
  • mark offer as parked
  • move failed item to review
  • suggest trashing duplicate page after human review

Rule:
Parking is safer than deletion.

17. Approved Actions

Field:
Approved Actions:

Purpose:
Lists exactly what the AI Employee may do with the tool.

Examples:

For Gmail:

  • read newsletter email content
  • identify sender, subject, date, body
  • pass body to extraction workflow

For Supabase:

  • insert newsletter intelligence row into approved table
  • update internal review status after validation
  • create failure log record

For WordPress:

  • read page title and parent
  • prepare draft update
  • identify duplicate risk

For uploaded files:

  • read course transcript
  • extract relevant frameworks
  • create report

Rule:
Approved actions must be explicit.

18. Forbidden Actions

Field:
Forbidden Actions:

Purpose:
Lists what the AI Employee must never do with the tool.

Examples:

  • do not send external email
  • do not publish WordPress pages
  • do not edit MCR directly
  • do not change Supabase schema
  • do not delete records
  • do not approve ad spend
  • do not launch campaigns
  • do not access unrelated client data
  • do not modify M’s active build
  • do not create downstream high-risk tasks without review
  • do not claim tool access if not actually used

Rule:
Forbidden actions are mandatory for any meaningful tool permission.

19. Human Approval Required

Field:
Human Approval Required: Yes / No

Purpose:
Defines whether human approval is required before using the tool or before acting on tool output.

Human Approval Required For:

  • write access
  • modify access
  • external action
  • deletion
  • MCR canon changes
  • developer implementation
  • financial action
  • paid traffic
  • compliance-sensitive actions
  • client-facing output

Rule:
When risk is medium or higher, human approval should usually be required.

20. Human Approval Stage

Field:
Human Approval Stage:

Recommended Values:

  • Before Tool Use
  • Before Write
  • Before Modify
  • Before External Action
  • Before Delete
  • Before Handoff
  • Before Dashboard Display
  • Before MCR Save
  • Before Client Delivery
  • After Draft Only
  • Not Required For Low Risk

Rule:
State when approval is required, not just that approval is required.

21. Validation Required

Field:
Validation Required: Yes / No

Purpose:
Defines whether the output of tool use must be validated.

Validation May Include:

  • source grounding
  • field completeness
  • schema check
  • Brain routing check
  • risk check
  • duplicate check
  • compliance check
  • developer boundary check
  • human review

Rule:
Tool-enabled outputs should usually require validation.

22. Validation Level

Field:
Validation Level:

Recommended Values:

  • Light Validation
  • Structured Validation
  • Operational Validation
  • High Risk Validation
  • Critical Validation

Rule:
Validation level must match tool risk.

23. Logging Required

Field:
Logging Required: Yes / No

Purpose:
Defines whether tool use must be logged.

Logging Required For:

  • database writes
  • status changes
  • automation actions
  • developer handoffs
  • MCR actions
  • external actions
  • client actions
  • failures
  • high-risk read access
  • permission changes

Rule:
Important tool use should leave an audit trail.

24. Log Destination

Field:
Log Destination:

Examples:

  • Supabase event log
  • task event log
  • failure log
  • outcome log
  • HeadOffice dashboard log
  • Brain Room thread
  • MCR change log
  • Make.com execution history
  • AIBS client audit log
  • manual note

Rule:
Logging must have a destination.

25. Risk Level

Field:
Risk Level:

Recommended Values:

  • Low
  • Medium
  • High
  • Critical

Examples:

Low:

  • read uploaded course file

Medium:

  • read Gmail newsletter or insert internal review row

High:

  • WordPress write, Supabase production write, developer handoff, Google Ads recommendation

Critical:

  • live code change, paid traffic launch, client final delivery, irreversible delete

Rule:
Risk level controls approval, validation, and logging.

26. Stop Conditions

Field:
Stop Conditions:

Purpose:
Defines when the AI Employee must stop using the tool and escalate.

Examples:

  • input missing
  • source incomplete
  • permission unclear
  • validation fails
  • unexpected data appears
  • duplicate record detected
  • schema mismatch
  • human approval required
  • live system impact detected
  • finance/compliance risk appears
  • client data outside scope appears
  • M’s active build affected
  • tool error occurs
  • output confidence low

Rule:
Tool use must stop when risk becomes unclear.

27. Escalation Destination

Field:
Escalation Destination:

Examples:

  • Martyn
  • HeadOffice
  • M
  • Human Review Queue
  • Validation Agent
  • Research Brain
  • Finance Brain
  • Compliance Or Risk Review
  • Developer Review
  • Parking System
  • Tool Owner

Rule:
Tool permission must define who receives the escalation.

28. Review Frequency

Field:
Review Frequency:

Recommended Values:

  • Per Use
  • Daily
  • Weekly
  • Monthly
  • Before Expansion
  • After Failure
  • Before Automation
  • Before Client Use
  • No Scheduled Review Yet

Rule:
Higher-risk tool permissions need more frequent review.

29. Permission Status

Field:
Permission Status:

Recommended Values:

  • Proposed
  • Draft
  • Approved For Manual Use
  • Approved For Assisted Use
  • Approved For Controlled Write
  • Approved With Human Review
  • Restricted
  • Parked
  • Suspended
  • Revoked
  • Deprecated

Rule:
Do not treat proposed permission as approved permission.

30. Related Role Card

Field:
Related Role Card:

Purpose:
Links permission to the relevant AI Employee Role Card.

Rule:
Tool permission should not exist separately from role definition.

31. Related Capability Stack

Field:
Related Capability Stack:

Purpose:
Links permission to the Employee’s Capability Stack.

Rule:
Tool permission must match capability stack.

32. Related Workflow

Field:
Related Workflow:

Examples:

  • Newsletter Intelligence Workflow
  • Course Absorption Workflow
  • Brain Room Task Creation Workflow
  • Offer Evaluation Workflow
  • Developer Support Workflow
  • Validation Workflow
  • Handoff Workflow
  • AIBS Client Workflow

Rule:
Tool permission should support a real workflow.

Quick Use Version

Use this shorter version for practical tool permission setup.

Permission Record Title:
AI Employee Name:
Owning Brain:
Supporting Brains Affected:
Tool Or System Name:
Tool Category:
Permission Purpose:
Approved Access Level:
Access Type Allowed:
Read Permission:
Draft Permission:
Write Permission:
Modify Permission:
External Action Permission:
Delete Permission:
Archive Or Park Permission:
Approved Actions:
Forbidden Actions:
Human Approval Required:
Human Approval Stage:
Validation Required:
Validation Level:
Logging Required:
Log Destination:
Risk Level:
Stop Conditions:
Escalation Destination:
Review Frequency:
Permission Status:
Related Role Card:
Related Capability Stack:
Related Workflow:

Example 1: Newsletter Signal Extraction Agent Gmail Permission

Permission Record Title:
Newsletter Signal Extraction Agent Gmail Read Permission

AI Employee Name:
Newsletter Signal Extraction Agent

Owning Brain:
HeadOffice Brain

Supporting Brains Affected:
Ads Brain, Affiliate Brain, Content Brain, Research Brain, Finance Brain

Tool Or System Name:
Gmail

Tool Category:
Email

Permission Purpose:
Read newsletter source emails so business-relevant signals can be extracted.

Approved Access Level:
Level 2 — Read Only Reference Access

Access Type Allowed:
Read

Read Permission:
Yes — only approved newsletter label/source emails

Draft Permission:
No

Write Permission:
No

Modify Permission:
No, unless separate label update workflow is approved

External Action Permission:
No

Delete Permission:
No

Archive Or Park Permission:
No, unless separate low-risk label workflow is approved

Approved Actions:

  • read sender
  • read subject
  • read date
  • read email body
  • read snippet
  • pass source content into extraction workflow

Forbidden Actions:

  • do not send email
  • do not delete email
  • do not reply
  • do not forward
  • do not access unrelated email
  • do not treat truncated body as complete without checking

Human Approval Required:
No for approved read workflow; yes before downstream action

Human Approval Stage:
Before downstream task creation or dashboard action

Validation Required:
Yes

Validation Level:
Operational Validation

Logging Required:
Yes

Log Destination:
Newsletter Intelligence record / Make execution history / Supabase where applicable

Risk Level:
Medium

Stop Conditions:

  • body is incomplete
  • source email unclear
  • unrelated personal email appears
  • compliance-sensitive issue appears
  • extraction confidence low

Escalation Destination:
HeadOffice

Review Frequency:
After failure or before permission expansion

Permission Status:
Approved For Assisted Use

Related Workflow:
Newsletter Intelligence Workflow

Example 2: Newsletter Signal Extraction Agent Supabase Permission

Permission Record Title:
Newsletter Signal Extraction Agent Supabase Controlled Write Permission

AI Employee Name:
Newsletter Signal Extraction Agent

Owning Brain:
HeadOffice Brain

Supporting Brains Affected:
HeadOffice Brain, downstream Brains through queue review

Tool Or System Name:
Supabase

Tool Category:
Database

Permission Purpose:
Insert structured newsletter intelligence rows into the approved review table.

Approved Access Level:
Level 4 — Controlled Write Access

Access Type Allowed:
Write

Read Permission:
Limited read if needed for validation

Draft Permission:
No

Write Permission:
Yes — approved table only

Modify Permission:
No unless separately approved

External Action Permission:
No

Delete Permission:
No

Archive Or Park Permission:
No unless queue status workflow is approved

Approved Actions:

  • insert newsletter intelligence row
  • include required fields
  • preserve source metadata
  • set review status where approved

Forbidden Actions:

  • do not change schema
  • do not write to unrelated tables
  • do not create downstream tasks
  • do not delete rows
  • do not update production data outside approved workflow
  • do not mark item as final without review

Human Approval Required:
Not before internal row insert if workflow is approved; required before downstream action

Human Approval Stage:
Before routing beyond review queue

Validation Required:
Yes

Validation Level:
Operational Validation

Logging Required:
Yes

Log Destination:
Supabase row / Make execution history / HeadOffice review queue

Risk Level:
Medium

Stop Conditions:

  • required fields missing
  • JSON parse failure
  • schema mismatch
  • duplicate row suspected
  • source body incomplete
  • urgent/high-risk signal detected

Escalation Destination:
HeadOffice

Review Frequency:
After failure or before workflow expansion

Permission Status:
Approved For Controlled Write

Related Workflow:
Newsletter Intelligence Workflow

Example 3: Course Absorption Agent Uploaded File Permission

Permission Record Title:
Course Absorption Agent Uploaded File Review Permission

AI Employee Name:
Course Absorption Agent

Owning Brain:
HeadOffice Brain

Supporting Brains Affected:
AI Business Systems Brain, Operations Brain, relevant specialist Brain

Tool Or System Name:
Uploaded Files

Tool Category:
Uploaded File

Permission Purpose:
Read uploaded course files and extract reusable MWMS system value.

Approved Access Level:
Level 1 — Provided Input Only

Access Type Allowed:
Read

Read Permission:
Yes — uploaded course files only

Draft Permission:
Yes — draft report or full page output

Write Permission:
No

Modify Permission:
No

External Action Permission:
No

Delete Permission:
No

Archive Or Park Permission:
Suggest park/reject only

Approved Actions:

  • read course PDF/transcript/SRT/HTML
  • extract useful frameworks
  • identify what to ignore
  • draft absorption report
  • draft MCR page output when justified

Forbidden Actions:

  • do not save directly to MCR
  • do not create live pages
  • do not absorb weak material
  • do not invent course content
  • do not interfere with M’s active build

Human Approval Required:
Yes before MCR save

Human Approval Stage:
Before page creation or registry update

Validation Required:
Yes

Validation Level:
Operational Validation

Logging Required:
Yes if absorbed

Log Destination:
Course Absorption log / MCR Change Log where applicable

Risk Level:
Medium

Stop Conditions:

  • file expired
  • source incomplete
  • duplicate page risk
  • technical claims require developer validation
  • course conflicts with existing standard

Escalation Destination:
HeadOffice / Martyn

Review Frequency:
Per course block

Permission Status:
Approved For Manual Use

Related Workflow:
Course Absorption Workflow

Example 4: Developer Support Agent Provided File Permission

Permission Record Title:
Developer Support Agent Provided File Review Permission

AI Employee Name:
Developer Support Agent

Owning Brain:
HeadOffice Brain

Supporting Brains Affected:
Operations Brain, Dev Console, Brain Room, relevant technical system

Tool Or System Name:
Uploaded Plugin Files / Screenshots / Provided Code

Tool Category:
Uploaded File / Screenshot

Permission Purpose:
Review provided evidence to prepare exact developer instructions for M.

Approved Access Level:
Level 1 — Provided Input Only

Access Type Allowed:
Read and Draft

Read Permission:
Yes — provided files and screenshots only

Draft Permission:
Yes — developer brief or full file output

Write Permission:
No

Modify Permission:
No live modification

External Action Permission:
No

Delete Permission:
No

Archive Or Park Permission:
No

Approved Actions:

  • review provided file content
  • review visible screenshot evidence
  • identify exact issue
  • draft exact instruction
  • draft full file output where requested
  • include test steps

Forbidden Actions:

  • do not alter live code
  • do not guess file paths
  • do not touch unrelated systems
  • do not give vague search instructions
  • do not ignore current screenshot evidence

Human Approval Required:
Always

Human Approval Stage:
Before sending to M or applying any change

Validation Required:
Yes

Validation Level:
High Risk Validation

Logging Required:
Yes for meaningful development work

Log Destination:
Dev Console / Brain Room / save point note where applicable

Risk Level:
High

Stop Conditions:

  • file path missing
  • file content missing
  • screenshot incomplete
  • current state unclear
  • live system risk detected
  • M would need to guess

Escalation Destination:
Martyn / M / HeadOffice

Review Frequency:
Per developer task

Permission Status:
Approved For Manual Use

Related Workflow:
Developer Support Workflow

Example 5: AIBS Client Reporting Agent Client Data Permission

Permission Record Title:
AIBS Client Reporting Agent Client Data Read Permission

AI Employee Name:
AIBS Client Reporting Agent

Owning Brain:
AI Business Systems Brain

Supporting Brains Affected:
HeadOffice Brain, Operations Brain, client-specific workflow Brain

Tool Or System Name:
Approved Client Data Source

Tool Category:
Client System

Permission Purpose:
Read approved client workflow data to prepare draft management reports.

Approved Access Level:
Level 2 — Read Only Reference Access / Level 3 Draft Creation Access

Access Type Allowed:
Read and Draft

Read Permission:
Yes — approved client data only

Draft Permission:
Yes — client report draft

Write Permission:
No unless separately approved

Modify Permission:
No

External Action Permission:
No

Delete Permission:
No

Archive Or Park Permission:
No

Approved Actions:

  • read approved client records
  • summarize business meaning
  • draft client report
  • identify risk notes
  • recommend action for review

Forbidden Actions:

  • do not access unrelated client data
  • do not mix client contexts
  • do not send final report
  • do not modify client systems
  • do not make legal, financial, or contractual commitments
  • do not make unsupported claims

Human Approval Required:
Yes

Human Approval Stage:
Before client delivery

Validation Required:
Yes

Validation Level:
High Risk Validation

Logging Required:
Yes

Log Destination:
AIBS client audit log / client review queue

Risk Level:
High

Stop Conditions:

  • client data outside scope appears
  • report contains uncertainty
  • sensitive data appears
  • compliance risk appears
  • approval gate missing

Escalation Destination:
HeadOffice / Human Client Review

Review Frequency:
Before client use and after any failure

Permission Status:
Draft / Future Use

Related Workflow:
AIBS Client Reporting Workflow

Tool Permission Quality Checklist

Before approving a Tool Permission Record, check:

  1. Is the permission title clear?
  2. Is the AI Employee defined?
  3. Is the owning Brain clear?
  4. Are affected Brains listed where needed?
  5. Is the tool or system named?
  6. Is the tool category clear?
  7. Is the permission purpose specific?
  8. Is the approved access level the lowest safe level?
  9. Is the access type specific?
  10. Is read permission defined?
  11. Is draft permission defined?
  12. Is write permission defined?
  13. Is modify permission defined?
  14. Is external action permission defined?
  15. Is delete permission defined?
  16. Is archive or park permission defined?
  17. Are approved actions explicit?
  18. Are forbidden actions explicit?
  19. Is human approval requirement clear?
  20. Is approval stage clear?
  21. Is validation requirement clear?
  22. Is validation level appropriate?
  23. Is logging requirement clear?
  24. Is log destination known?
  25. Is risk level assigned?
  26. Are stop conditions listed?
  27. Is escalation destination clear?
  28. Is review frequency defined?
  29. Is permission status honest?
  30. Does this permission match the Role Card and Capability Stack?

If several answers are unclear, permission is not ready.

Common Tool Permission Failure Modes

A tool permission has failed if:

  1. Tool access is granted because the tool exists, not because the workflow needs it.
  2. Write access is granted when read-only would work.
  3. External action is allowed without human approval.
  4. Delete access is granted too casually.
  5. Forbidden actions are missing.
  6. Stop conditions are missing.
  7. Logging destination is unknown.
  8. Permission does not match role card.
  9. Permission exceeds capability stack.
  10. AI claims it used a tool it did not access.
  11. AI assumes current state without verification.
  12. AI writes before validation.
  13. AI accesses unrelated client data.
  14. AI affects M’s active build without approval.
  15. Tool permission expands without HeadOffice review.

Manual Use Rule

This template should be used manually before it becomes technical infrastructure.

Manual use helps MWMS learn:

  • which Employees actually need tools
  • which tools are high-risk
  • where read-only is enough
  • where draft-only is enough
  • where human approval must stay
  • which permissions should never be automated
  • which tool permissions may later become AI Manager or router settings
  • which permission fields may later become Supabase fields

Manual permission discipline comes before automated tool access.

Future Plugin Or UI Relevance

This template may later become:

  • AI Tool Permission Registry
  • AI Employee permission screen
  • AI Manager tool access configuration
  • AI Employee Router permission rules
  • Task Executor tool boundary logic
  • HeadOffice permission dashboard
  • Brain Room action permissions
  • AIBS client permission panel

Possible future fields:

  • permission_id
  • permission_title
  • employee_name
  • owning_brain
  • supporting_brains_affected
  • tool_name
  • tool_category
  • permission_purpose
  • approved_access_level
  • access_type_allowed
  • read_permission
  • draft_permission
  • write_permission
  • modify_permission
  • external_action_permission
  • delete_permission
  • archive_or_park_permission
  • approved_actions
  • forbidden_actions
  • human_approval_required
  • human_approval_stage
  • validation_required
  • validation_level
  • logging_required
  • log_destination
  • risk_level
  • stop_conditions
  • escalation_destination
  • review_frequency
  • permission_status
  • related_role_card
  • related_capability_stack
  • related_workflow
  • created_at
  • updated_at

No technical build is authorized by this template alone.

Governance Role

HeadOffice owns the MWMS AI Tool Permission Record Template.

HeadOffice is responsible for:

  • approving tool permission boundaries
  • ensuring least-privilege access
  • preventing unsafe write access
  • preventing external action without approval
  • preventing delete permission drift
  • ensuring validation and logging exist
  • protecting MCR source of truth
  • protecting M’s active build areas
  • protecting paid traffic, finance, compliance, public content, and client systems
  • deciding when this template is ready for operational copy or plugin/UI transformation

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

Relationship To Other MWMS Standards

This template supports and must align with:

  • MWMS AI Tool Permission And Access Framework
  • MWMS AI Agent Operations Core
  • MWMS AI Employee Capability Stack Framework
  • MWMS AI Employee Capability Stack Template
  • MWMS AI Employee Role Card Standard
  • MWMS AI Employee Role Card Template
  • MWMS Agentic Work Unit Standard
  • MWMS Agentic Work Unit Template
  • MWMS AI Workflow Pipeline Standard
  • MWMS AI Workflow Pipeline Checklist
  • MWMS AI Output Validation Standard
  • MWMS AI Output Validation Checklist
  • MWMS AI Agent Memory And Context Framework
  • MWMS AI Employee Handoff Protocol
  • MWMS AI Employee Handoff Package Template
  • MWMS AI Agent Failure Handling And Escalation Protocol
  • MWMS AI Agent Failure Log Record
  • MWMS AI Agent Outcome Measurement Framework
  • MWMS AI Agent Outcome Log Record
  • MWMS Brain Routing Rule
  • MWMS Brain To Brain Request Protocol
  • MWMS Supabase Event Schema
  • AI Business Systems Brain Blueprint

This template is the practical application of the MWMS AI Tool Permission And Access Framework.

Drift Protection

This template protects MWMS from the following forms of drift:

  1. Giving AI tools because they are available rather than necessary
  2. Allowing tool use without role definition
  3. Allowing write access before workflow maturity
  4. Allowing external action without approval
  5. Allowing delete access without strict control
  6. Allowing tool use without logging
  7. Treating draft creation as execution
  8. Allowing AI to claim tool access it did not have
  9. Allowing AI to assume live system state
  10. Giving one AI Employee too many tools
  11. Allowing client systems to run without permission gates
  12. Allowing M’s active build areas to be affected by unmanaged AI action
  13. Allowing permission expansion without HeadOffice review
  14. Confusing automation capability with safe operation
  15. Letting AI become powerful before it becomes reliable

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

Architectural Intent

The architectural intent of the MWMS AI Tool Permission Record Template is to make AI tool access safe, deliberate, reviewable, and scalable.

MWMS will eventually use AI Employees across many tools and workflows.

That power must be governed.

This template ensures every tool permission can answer:

  • Who is using the tool?
  • Why do they need it?
  • What level of access is allowed?
  • Is read-only enough?
  • Is draft-only enough?
  • Is write access justified?
  • Is external action allowed?
  • Is delete access forbidden?
  • What actions are approved?
  • What actions are forbidden?
  • Is human approval required?
  • Is validation required?
  • Is logging required?
  • What are the stop conditions?
  • Who owns escalation?

When MWMS can answer those questions, it can expand tool-enabled AI safely.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Tool Permission Record Template as the practical operational template for defining AI Employee tool access, permission boundaries, approved actions, forbidden actions, human approval requirements, validation levels, logging requirements, risk levels, stop conditions, escalation destinations, and future plugin/UI relevance.

This template operationalizes the MWMS AI Tool Permission And Access Framework and supports future AI Manager, AI Employee Router, Task Executor systems, Brain Room, Newsletter Intelligence, Course Absorption, Developer Support, Offer Evaluation, HeadOffice dashboards, and AIBS client workflow permissions.