MWMS MCR

MWMS AI Permission Gatekeeper Framework

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, Course Absorption System, Newsletter Intelligence, Opportunity System, Dev Console, 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 Permission Gatekeeper Framework.

This framework explains how MWMS controls whether an AI Employee, workflow, command, trigger, tool call, automation, dashboard action, developer handoff, or future client workflow is allowed to proceed.

MWMS must not allow an AI Employee to decide its own permissions.

An AI Employee may request an action.

The Permission Gatekeeper decides whether that action is allowed.

This is critical because AI Employees may eventually request actions such as:

  • reading Gmail
  • writing to Supabase
  • updating WordPress
  • creating tasks
  • routing Brain Room messages
  • creating dashboard items
  • preparing developer handoffs
  • drafting reports
  • applying labels
  • triggering Make.com or n8n workflows
  • using external tools
  • preparing client reports
  • creating future AIBS actions

The purpose of the Permission Gatekeeper is to sit between AI intent and system action.

It ensures that AI actions are checked against:

  • role authority
  • capability stack
  • tool permission
  • workflow stage
  • risk level
  • source completeness
  • context readiness
  • human approval requirement
  • validation status
  • logging requirement
  • stop conditions
  • client safety rules
  • M’s active build boundaries

The Permission Gatekeeper prevents AI power from becoming uncontrolled execution.

Scope

This framework applies to all permission-sensitive AI activity across MWMS.

This includes permission control for:

  • HeadOffice Brain
  • Brain Room
  • AI Manager
  • AI Employee Router
  • Task Executor systems
  • Dev Console
  • Newsletter Intelligence
  • Course Absorption
  • Opportunity System
  • Affiliate Brain
  • Research Brain
  • Experimentation Brain
  • Finance Brain
  • Content Brain
  • Ads Brain
  • Sales Brain
  • Conversion Brain
  • Operations Brain
  • AI Business Systems Brain
  • Gmail workflows
  • Supabase workflows
  • WordPress workflows
  • MCR workflows
  • Make.com workflows
  • n8n workflows
  • Google Sheets workflows
  • dashboard workflows
  • developer handoffs
  • future AIBS client systems

This framework applies before any AI-driven action is treated as approved, executed, written, routed, displayed, sent, published, scheduled, or handed off.

This framework does not authorize development work.

It defines the governance logic for permission checking before operational execution, automation, plugin/UI build, or client deployment.

Core Definition

The AI Permission Gatekeeper is the control layer that decides whether a requested AI action is allowed to proceed.

A permission decision must evaluate:

  • who is requesting the action
  • what action is being requested
  • what tool or system is involved
  • what workflow stage applies
  • what source material supports the action
  • what context is available
  • what permission level is approved
  • what risk level applies
  • whether validation is required
  • whether human approval is required
  • whether logging is required
  • whether stop conditions are triggered

The Gatekeeper is not the same as the AI Employee.

The AI Employee performs or prepares work.

The Gatekeeper checks whether the work is allowed to move forward.

Core Principle

The core principle of this framework is:

AI Employees may request actions, but permission must be checked independently before action.

This protects MWMS from:

  • AI Employees overstepping authority
  • tool access being assumed
  • write actions happening too early
  • external actions bypassing approval
  • developer tasks being created from weak context
  • MCR changes being made from unvalidated output
  • scheduled workflows running without monitoring
  • client-facing reports being delivered without review
  • paid traffic or finance actions moving without approval

The Gatekeeper exists to answer:

Is this action allowed right now, by this role, in this workflow, with this context, under this permission level?

If the answer is no, uncertain, or incomplete, the action must be blocked, downgraded, parked, or escalated.

Permission Gatekeeper Position In The Workflow

The Permission Gatekeeper sits between:

AI Intent → Permission Check → Approved Action Or Blocked Action

The correct sequence is:

  1. Request or trigger occurs.
  2. Task type is identified.
  3. Context is routed.
  4. AI Employee or workflow proposes an action.
  5. Permission Gatekeeper checks the action.
  6. If allowed, action proceeds within approved boundary.
  7. If not allowed, action is blocked, downgraded, parked, or escalated.
  8. Outcome or failure is logged.

The Gatekeeper should appear before:

  • tool calls
  • writes
  • modifications
  • external sends
  • publishing
  • task creation
  • dashboard display
  • developer handoff
  • client delivery
  • scheduled automation
  • cross-Brain routing where risk is medium or higher

Permission Decision Layers

The MWMS AI Permission Gatekeeper uses twelve decision layers.

1. Requesting Role Check

The Gatekeeper first checks who or what is requesting the action.

Possible requesters:

  • AI Employee
  • Brain Room message
  • AI Manager
  • AI Employee Router
  • Task Executor
  • command trigger
  • event trigger
  • scheduled trigger
  • human user
  • HeadOffice
  • M
  • future client operator

Questions:

  • Is the requester known?
  • Is the requester authorized for this workflow?
  • Does the requester have an approved role?
  • Does the requester have the right capability stack?
  • Is this requester allowed to initiate this action?

Rule:

Unknown or unscoped requesters should not trigger operational action.

2. Action Type Check

The Gatekeeper checks what type of action is being requested.

Action types include:

  • read
  • draft
  • analyze
  • classify
  • summarize
  • validate
  • route
  • create internal record
  • update internal record
  • modify status
  • apply label
  • send message
  • publish content
  • trigger automation
  • delete
  • archive
  • approve spend
  • client delivery

Rule:

The permission required depends on the action type.

Reading is lower risk than writing.

Writing is lower risk than external action.

External action is lower risk than irreversible action.

3. Tool Or System Check

The Gatekeeper checks which system or tool is involved.

Systems may include:

  • Gmail
  • Supabase
  • WordPress
  • MCR
  • Brain Room
  • AI Manager
  • Task Executor
  • Make.com
  • n8n
  • Google Sheets
  • Google Ads
  • BeMob
  • dashboards
  • client systems
  • uploaded files
  • external web sources

Questions:

  • Is the tool approved for this workflow?
  • Is the tool permission record defined?
  • Is the tool read-only, draft-only, controlled write, or external action capable?
  • Is the requested action inside the approved boundary?

Rule:

Tool access must be granted by permission records, not by convenience.

4. Workflow Stage Check

The Gatekeeper checks where the action sits in the workflow.

Workflow stages include:

  • input capture
  • input cleaning
  • classification
  • context routing
  • task creation
  • processing
  • validation
  • decision
  • routing
  • handoff
  • logging
  • learning
  • automation
  • client delivery

Rule:

Some actions are only allowed at certain workflow stages.

Example:

  • A draft may be allowed before validation.
  • A routed action should not be created before review.
  • Client delivery should not occur before approval.
  • Developer handoff should not happen before evidence and validation.

5. Context Readiness Check

The Gatekeeper checks whether the action has enough context.

Context may include:

  • current request
  • source material
  • source completeness
  • source of truth
  • current evidence
  • Brain ownership
  • assigned AI Employee
  • relevant standards
  • tool permission boundary
  • risk level
  • human review requirement
  • expected output
  • handoff destination

Rule:

Permission should not be granted when context is starved, stale, polluted, or unclear.

If context is incomplete, the action should be downgraded to draft, clarification, parking, or review.

6. Source Completeness Check

The Gatekeeper checks whether the source is complete enough for the requested action.

Examples:

  • newsletter body must be complete enough before routing
  • developer file path must be known before M handoff
  • offer payout must be known before finance decision
  • current screenshot must be available before troubleshooting
  • client source data must be approved before report drafting

Rule:

Incomplete source may allow drafting, but not final action.

7. Permission Level Check

The Gatekeeper checks the approved permission level.

Recommended permission levels:

  • Level 0 — No 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:

The requested action must not exceed the approved permission level.

If the requested action exceeds permission, it must be blocked or escalated.

8. Risk Level Check

The Gatekeeper checks the risk of the requested action.

Risk levels:

  • Low
  • Medium
  • High
  • Critical

Low-risk actions may proceed with light review.

Medium-risk actions usually require validation.

High-risk actions require human review.

Critical-risk actions require explicit approval and may be forbidden.

High-risk examples:

  • developer handoff to M
  • WordPress/MCR changes
  • Supabase writes
  • paid traffic recommendations
  • finance decisions
  • public content
  • client-facing reports
  • external messages
  • live automation changes

Rule:

Risk level controls validation, approval, logging, and stop conditions.

9. Human Approval Check

The Gatekeeper checks whether human approval is required.

Human approval is required before:

  • MCR canon changes
  • developer handoff to M
  • live system changes
  • paid traffic action
  • finance decision
  • public content
  • client-facing delivery
  • high-risk automation
  • external emails or messages
  • deletion or irreversible action

Rule:

Human approval cannot be replaced by AI confidence.

If human approval is required and not present, the action must stop.

10. Validation Status Check

The Gatekeeper checks whether the output or action has been validated.

Validation statuses may include:

  • Not Validated
  • Light Validation Complete
  • Structured Validation Complete
  • Operational Validation Complete
  • High Risk Validation Complete
  • Critical Validation Required
  • Failed Validation
  • Needs Revision

Rule:

Unvalidated output should not become operational action.

If validation failed, route to failure handling or revision.

11. Logging Requirement Check

The Gatekeeper checks whether the action must be logged.

Logging is required for:

  • database writes
  • status changes
  • automation triggers
  • developer handoffs
  • MCR changes
  • external actions
  • client-facing outputs
  • high-risk reads
  • failed permission attempts
  • blocked actions
  • human approvals

Rule:

Important permissioned actions must leave an audit trail.

If there is no log destination, the action should not expand beyond manual/draft status.

12. Stop Condition Check

The Gatekeeper checks whether any stop condition has been triggered.

Stop conditions include:

  • source incomplete
  • context unclear
  • permission missing
  • risk too high
  • human approval missing
  • validation failed
  • tool schema mismatch
  • M would need to guess
  • client data outside scope
  • duplicate page risk
  • compliance risk
  • finance risk
  • automation not manually proven
  • requested action exceeds capability

Rule:

Stop conditions override workflow momentum.

If a stop condition is triggered, the action must stop, downgrade, park, or escalate.

Gatekeeper Decisions

The Permission Gatekeeper may return one of the following decisions.

1. Allow

The action is allowed within the approved boundary.

Use when:

  • role is authorized
  • context is ready
  • source is complete enough
  • permission level matches action
  • risk is acceptable
  • validation is complete where required
  • human approval is not required or already granted
  • logging path exists

2. Allow As Draft Only

The AI may draft or prepare output, but cannot execute, route, send, publish, or write.

Use when:

  • action is useful but not ready for execution
  • source is partial
  • human review required
  • validation incomplete
  • workflow is manual proof only

3. Allow Read Only

The AI may read approved information but may not write, modify, route, publish, send, or trigger action.

Use when:

  • research is needed
  • source verification is needed
  • tool access must remain low risk
  • workflow is not ready for write access

4. Require Human Review

The action must pause until human approval is provided.

Use when:

  • risk is medium or high
  • output affects MCR, M, money, public content, clients, or live systems
  • current evidence is incomplete
  • decision authority belongs to Martyn or HeadOffice

5. Require Validation First

The action cannot proceed until validation is completed.

Use when:

  • output exists but has not been checked
  • routing depends on validation
  • dashboard display is requested
  • handoff is high-risk
  • client report is being prepared

6. Downgrade

The requested action is too powerful for current permission, but a lower-risk action is allowed.

Examples:

  • write request downgraded to draft
  • external send downgraded to draft email
  • dashboard publish downgraded to review candidate
  • automation trigger downgraded to manual review
  • developer handoff downgraded to evidence request

7. Park

The action is not ready now but may be useful later.

Use when:

  • context is incomplete
  • workflow is not mature
  • manual proof is missing
  • priority is low
  • tool permissions are not ready

8. Block

The action is not allowed.

Use when:

  • permission is missing
  • action exceeds authority
  • stop condition triggered
  • risk is too high
  • requested action is forbidden
  • client safety boundary is violated
  • M’s active build would be affected unsafely

9. Escalate

The action requires review by a higher authority.

Possible escalation destinations:

  • Martyn
  • HeadOffice
  • M
  • Human Review Queue
  • Validation Agent
  • Compliance Or Risk Review
  • Finance Brain
  • Developer Review
  • AIBS Client Review

10. Log Failure

The permission request or attempted action exposed a failure.

Use when:

  • AI attempted forbidden action
  • tool permission was unclear
  • validation failed
  • schema mismatch occurred
  • action was blocked due to missing context
  • trigger fired prematurely

Permission Gatekeeper Record Template

Use this template when a permission-sensitive action is requested.

Permission Check Title

Field:
Permission Check Title:

Date Checked

Field:
Date Checked:

Requesting Role Or System

Field:
Requesting Role Or System:

Requested Action

Field:
Requested Action:

Action Type

Field:
Action Type:

Recommended values:

  • Read
  • Draft
  • Analyze
  • Classify
  • Validate
  • Route
  • Write
  • Modify
  • Label
  • Trigger
  • Send
  • Publish
  • Delete
  • External Action
  • Client Delivery

Tool Or System

Field:
Tool Or System:

Workflow

Field:
Workflow:

Workflow Stage

Field:
Workflow Stage:

Owning Brain

Field:
Owning Brain:

Source Material

Field:
Source Material:

Source Completeness

Field:
Source Completeness:

Context Readiness

Field:
Context Readiness:

Recommended values:

  • Ready
  • Partial
  • Missing
  • Stale
  • Polluted
  • Unknown

Approved Permission Level

Field:
Approved Permission Level:

Requested Permission Level

Field:
Requested Permission Level:

Risk Level

Field:
Risk Level:

Recommended values:

  • Low
  • Medium
  • High
  • Critical

Validation Status

Field:
Validation Status:

Human Approval Required

Field:
Human Approval Required: Yes / No

Human Approval Status

Field:
Human Approval Status:

Recommended values:

  • Not Required
  • Required Not Granted
  • Granted
  • Denied
  • Pending

Logging Required

Field:
Logging Required: Yes / No

Logging Destination

Field:
Logging Destination:

Stop Conditions Triggered

Field:
Stop Conditions Triggered:

Gatekeeper Decision

Field:
Gatekeeper Decision:

Recommended values:

  • Allow
  • Allow As Draft Only
  • Allow Read Only
  • Require Human Review
  • Require Validation First
  • Downgrade
  • Park
  • Block
  • Escalate
  • Log Failure

Decision Reason

Field:
Decision Reason:

Next Action

Field:
Next Action:

Owner Of Next Action

Field:
Owner Of Next Action:

Status

Field:
Status:

Recommended values:

  • Draft
  • Checked
  • Allowed
  • Blocked
  • Parked
  • Escalated
  • Waiting For Human Review
  • Waiting For Validation
  • Logged
  • Closed

Quick Use Version

Permission Check Title:
Date Checked:
Requesting Role Or System:
Requested Action:
Action Type:
Tool Or System:
Workflow:
Workflow Stage:
Owning Brain:
Source Material:
Source Completeness:
Context Readiness:
Approved Permission Level:
Requested Permission Level:
Risk Level:
Validation Status:
Human Approval Required:
Human Approval Status:
Logging Required:
Logging Destination:
Stop Conditions Triggered:
Gatekeeper Decision:
Decision Reason:
Next Action:
Owner Of Next Action:
Status:

Examples

Example 1: Gmail Newsletter Read Permission

Permission Check Title:
Newsletter Signal Extraction Agent Gmail Read Permission Check

Requesting Role Or System:
Newsletter Signal Extraction Agent

Requested Action:
Read newsletter email body.

Action Type:
Read

Tool Or System:
Gmail

Workflow:
Newsletter Intelligence Workflow

Workflow Stage:
Source Intake

Owning Brain:
HeadOffice Brain

Source Material:
Newsletter email.

Source Completeness:
Unknown until body is checked.

Context Readiness:
Partial / Ready depending on body availability.

Approved Permission Level:
Level 2 — Read Only Reference Access

Requested Permission Level:
Level 2 — Read Only Reference Access

Risk Level:
Medium

Validation Status:
Output validation required after extraction.

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

Human Approval Status:
Not Required for read.

Logging Required:
Yes.

Logging Destination:
Make execution history / Newsletter Intelligence record.

Stop Conditions Triggered:
Stop if body is missing, unrelated email appears, or source is incomplete.

Gatekeeper Decision:
Allow Read Only

Decision Reason:
Read action is inside approved newsletter workflow and does not create external action.

Next Action:
Read email, check body completeness, proceed to extraction only if source is usable.

Owner Of Next Action:
Newsletter Signal Extraction Agent

Status:
Allowed

Example 2: Supabase Newsletter Row Write Permission

Permission Check Title:
Newsletter Intelligence Supabase Controlled Write Permission Check

Requesting Role Or System:
Newsletter Signal Extraction Workflow

Requested Action:
Insert structured newsletter intelligence row.

Action Type:
Write

Tool Or System:
Supabase

Workflow:
Newsletter Intelligence Workflow

Workflow Stage:
Structured Record Creation

Owning Brain:
HeadOffice Brain

Source Material:
Extracted newsletter signal.

Source Completeness:
Must be Mostly Complete or Complete.

Context Readiness:
Ready if fields are present and source is usable.

Approved Permission Level:
Level 4 — Controlled Write Access

Requested Permission Level:
Level 4 — Controlled Write Access

Risk Level:
Medium

Validation Status:
Schema and field validation required.

Human Approval Required:
No before internal review row if workflow is approved; yes before downstream action.

Human Approval Status:
Not Required for internal row insert.

Logging Required:
Yes.

Logging Destination:
Supabase row / Make execution history.

Stop Conditions Triggered:
Stop if required fields missing, schema mismatch, source incomplete, or output generic.

Gatekeeper Decision:
Allow

Decision Reason:
Controlled write is allowed only to approved table with required fields and logging.

Next Action:
Insert row, then route to review queue. Do not create downstream action automatically.

Owner Of Next Action:
Newsletter Intelligence Workflow

Status:
Allowed

Example 3: Developer Handoff To M Permission

Permission Check Title:
Developer Brief To M Permission Check

Requesting Role Or System:
Developer Support Agent

Requested Action:
Send or prepare developer handoff for M.

Action Type:
Route / Human Handoff

Tool Or System:
Brain Room / Dev Console / Manual Handoff

Workflow:
Developer Support Workflow

Workflow Stage:
Handoff

Owning Brain:
HeadOffice Brain

Source Material:
Screenshot, file content, user request, current save point.

Source Completeness:
Must be Complete or clearly marked Partial.

Context Readiness:
Ready only if exact evidence, site, file path where needed, and what not to touch are known.

Approved Permission Level:
Draft Creation / Human Review Required

Requested Permission Level:
High Risk Handoff

Risk Level:
High

Validation Status:
High Risk Validation required.

Human Approval Required:
Yes.

Human Approval Status:
Required Not Granted until Martyn approves.

Logging Required:
Yes.

Logging Destination:
Brain Room / Dev Console / task log where applicable.

Stop Conditions Triggered:
Stop if M would need to guess, file path missing, current state unclear, or live risk unresolved.

Gatekeeper Decision:
Require Human Review

Decision Reason:
Developer handoff is high-risk and must be evidence-based before M acts.

Next Action:
Validate brief, confirm evidence, then Martyn approves before sending to M.

Owner Of Next Action:
Martyn / HeadOffice

Status:
Waiting For Human Review

Example 4: MCR Page Save Permission

Permission Check Title:
MCR Page Save Permission Check

Requesting Role Or System:
Course Absorption Agent / Writer Agent

Requested Action:
Save new or replacement MCR page.

Action Type:
Write / Publish

Tool Or System:
WordPress MCR

Workflow:
Course Absorption / MCR Page Creation

Workflow Stage:
MCR Save

Owning Brain:
HeadOffice Brain

Source Material:
Course source, page draft, registry context.

Source Completeness:
Mostly Complete or Complete.

Context Readiness:
Ready only if page title, parent, document type, duplicate status, and registry need are clear.

Approved Permission Level:
Draft Creation only for AI; human performs save.

Requested Permission Level:
Write / Publish

Risk Level:
Medium to High

Validation Status:
Operational Validation required.

Human Approval Required:
Yes.

Human Approval Status:
Required Not Granted until Martyn approves.

Logging Required:
Yes if saved.

Logging Destination:
MCR Change Log / Page Registry update where applicable.

Stop Conditions Triggered:
Stop if duplicate risk, wrong parent, weak content, incomplete source, or registry unclear.

Gatekeeper Decision:
Allow As Draft Only

Decision Reason:
AI may create page output, but MCR save requires human action and validation.

Next Action:
Martyn reviews, checks duplicate/title/parent, then saves manually if approved.

Owner Of Next Action:
Martyn

Status:
Waiting For Human Review

Example 5: Client Report Delivery Permission

Permission Check Title:
AIBS Client Report Delivery Permission Check

Requesting Role Or System:
AIBS Client Reporting Agent

Requested Action:
Deliver client report.

Action Type:
Client Delivery / External Action

Tool Or System:
Client Reporting System / Email / Client Portal

Workflow:
AIBS Client Reporting Workflow

Workflow Stage:
Delivery

Owning Brain:
AI Business Systems Brain

Source Material:
Approved client source data and report draft.

Source Completeness:
Must be Complete and client-approved.

Context Readiness:
Ready only if client scope, report purpose, approval rules, privacy boundary, and validation status are clear.

Approved Permission Level:
Draft Creation only until client workflow is formally approved.

Requested Permission Level:
External Client Delivery

Risk Level:
High / Critical

Validation Status:
High Risk Validation required.

Human Approval Required:
Yes.

Human Approval Status:
Required Not Granted unless approved by HeadOffice/human reviewer.

Logging Required:
Yes.

Logging Destination:
Client audit log / AIBS review archive.

Stop Conditions Triggered:
Stop if client data outside scope, unsupported claim, privacy risk, missing approval, or unclear recommendation.

Gatekeeper Decision:
Block / Require Human Review

Decision Reason:
Client delivery requires strict approval and cannot be autonomous at this stage.

Next Action:
Keep as draft, validate, and route to HeadOffice/client review.

Owner Of Next Action:
HeadOffice / Client Review Owner

Status:
Waiting For Human Review

Permission Gatekeeper Readiness Checklist

Before allowing a permissioned action, check:

  1. Is the requesting role known?
  2. Is the requested action clear?
  3. Is the action type identified?
  4. Is the tool or system named?
  5. Is the workflow known?
  6. Is the workflow stage known?
  7. Is owning Brain clear?
  8. Is source material available?
  9. Is source completeness known?
  10. Is context ready?
  11. Is approved permission level defined?
  12. Does requested permission exceed approved permission?
  13. Is risk level assigned?
  14. Is validation status known?
  15. Is human approval required?
  16. Has human approval been granted if required?
  17. Is logging required?
  18. Is logging destination known?
  19. Are stop conditions triggered?
  20. Is the decision conservative enough?
  21. Could this affect M’s active build?
  22. Could this affect MCR, money, compliance, public content, or clients?
  23. Should the action be downgraded?
  24. Should the action be parked?
  25. Should the action be escalated?

If several answers are unclear, permission should not be granted.

Common Permission Gatekeeper Failure Modes

Permission gatekeeping has failed if:

  1. AI decides its own permissions.
  2. Tool access is assumed.
  3. Write access is granted when read-only would do.
  4. External action happens without human approval.
  5. Developer handoff happens with missing evidence.
  6. MCR save happens without duplicate or parent check.
  7. Client report is delivered without review.
  8. Scheduled workflow runs without monitoring.
  9. Validation status is ignored.
  10. Logging destination is missing.
  11. Stop conditions are ignored.
  12. Permission record does not match capability stack.
  13. Trigger creates action without approval.
  14. Tool output is treated as trusted without validation.
  15. Risk level is not used to control action.

Manual Use Rule

Permission gatekeeping should be manually proven before it becomes technical infrastructure.

Manual use helps MWMS learn:

  • which actions require approval
  • which workflows can stay read-only
  • which writes are safe
  • where AI overreaches
  • which stop conditions matter
  • where validation must happen
  • which permission checks may later become AI Manager or Task Executor logic
  • where client workflows need stricter controls
  • where M developer handoffs need stronger evidence gates

Manual gatekeeping discipline comes before automation.

Future Plugin Or UI Relevance

This framework may later support:

  • AI Permission Gatekeeper module
  • AI Manager permission check layer
  • Task Executor allow/block logic
  • Brain Room action approval gate
  • Dev Console permission checker
  • Supabase write permission rules
  • WordPress/MCR write guardrails
  • Gmail tool permission rules
  • HeadOffice approval dashboard
  • client workflow permission panel
  • audit log and blocked action records

Possible future fields:

  • permission_check_id
  • permission_check_title
  • date_checked
  • requesting_role_or_system
  • requested_action
  • action_type
  • tool_or_system
  • workflow
  • workflow_stage
  • owning_brain
  • source_material
  • source_completeness
  • context_readiness
  • approved_permission_level
  • requested_permission_level
  • risk_level
  • validation_status
  • human_approval_required
  • human_approval_status
  • logging_required
  • logging_destination
  • stop_conditions_triggered
  • gatekeeper_decision
  • decision_reason
  • next_action
  • owner_next_action
  • status
  • created_at
  • updated_at

No technical build is authorized by this framework alone.

Governance Role

HeadOffice owns the MWMS AI Permission Gatekeeper Framework.

HeadOffice is responsible for:

  • defining permission gatekeeping rules
  • ensuring AI Employees do not approve their own permissions
  • ensuring tool access follows permission records
  • ensuring actions do not exceed capability stacks
  • ensuring writes, external actions, and client actions require approval
  • ensuring validation status controls permission
  • ensuring risk level controls permission
  • ensuring logging exists for important actions
  • protecting M’s active build areas
  • protecting MCR source of truth
  • protecting paid traffic, finance, compliance, public content, and client systems
  • deciding when permission gatekeeping is ready for operational copy or plugin/UI transformation

Individual Brains may define local low-risk permission needs, but HeadOffice governs cross-Brain, high-risk, write-enabled, tool-enabled, automation-related, developer, MCR, and client-facing permission decisions.

Relationship To Other MWMS Standards

This framework supports and must align with:

  • MWMS AI Agent Operations Core
  • MWMS AI Context Routing Framework
  • MWMS AI Command And Trigger Framework
  • MWMS AI Multi Agent Role Design Framework
  • MWMS AI Exchange Zone And Dependency Control Framework
  • MWMS AI Ambiguity And Partial Failure Containment Framework
  • MWMS AI Agent Skill Library Framework
  • MWMS AI Plugin Orchestration Framework
  • MWMS AI Documentation Automation Pipeline Framework
  • MWMS Recurring Intelligence And Reporting Pipeline Framework
  • MWMS AI Tool Permission And Access Framework
  • MWMS AI Tool Permission Record Template
  • 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 AI Agent Memory And Context Framework
  • MWMS AI Agent Context Pack 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 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 AI Agent Deployment Readiness Checklist
  • MWMS AI Agent Deployment Readiness Review Template
  • MWMS Brain Routing Rule
  • MWMS Brain To Brain Request Protocol
  • MWMS Supabase Event Schema
  • AI Business Systems Brain Blueprint

This framework adds the independent permission control layer to the MWMS AI Agent Operations Core.

Drift Protection

This framework protects MWMS from:

  1. Allowing AI Employees to approve their own actions
  2. Treating AI confidence as permission
  3. Treating tool availability as tool authorization
  4. Allowing writes before validation
  5. Allowing external action without approval
  6. Allowing MCR changes without human review
  7. Allowing developer handoffs without sufficient evidence
  8. Allowing client delivery without approval gates
  9. Allowing scheduled workflows to bypass checks
  10. Allowing event triggers to create actions too early
  11. Allowing permission creep across Brains
  12. Allowing tool output to bypass validation
  13. Allowing missing logs on important actions
  14. Allowing risk level to be ignored
  15. Allowing automation to outrun governance

Any AI action without gatekeeper approval should remain draft, read-only, parked, blocked, or escalated.

Architectural Intent

The architectural intent of the MWMS AI Permission Gatekeeper Framework is to separate AI thinking from AI authority.

MWMS is building a powerful AI ecosystem.

Power must be controlled.

The long-term goal is that every permission-sensitive action can answer:

  • Who requested this action?
  • What action is requested?
  • What system or tool is involved?
  • What workflow stage applies?
  • Is the context ready?
  • Is the source complete?
  • What permission level is approved?
  • What permission level is requested?
  • What risk level applies?
  • Has validation happened?
  • Is human approval required?
  • Is logging required?
  • Are stop conditions triggered?
  • Should the action be allowed, downgraded, blocked, parked, or escalated?

When MWMS controls permission this way, AI Employees can become more capable without becoming unsafe.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Permission Gatekeeper Framework to define how MWMS checks whether AI Employees, workflows, commands, triggers, tool calls, writes, handoffs, scheduled reports, developer actions, MCR changes, and future client actions are allowed to proceed.

This framework establishes the independent permission gatekeeper layer between AI intent and system action.

It defines permission decision layers, gatekeeper decisions, permission check record templates, examples, readiness checks, failure modes, future plugin/UI relevance, governance role, drift protection, and architectural intent.

It establishes that AI Employees may request actions, but permission must be checked independently before action.