System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Active
Version: v1.6
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, Automation Brain, AIBS Brain, Data Brain, Risk Brain, Compliance Brain, AI Manager, AI Employee Router, Task Executor Systems, Client AIOS Systems
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-20
Source / Origin: MWMS AI Tool Permission And Access Framework v1.4 + AI Automations by Jack — ClaudeOS, NotebookLM, MCP, Persistent Agent, Local Tool And Remote Access Block
MWMS Classification: AI Tool Governance Framework / External Action Permission Standard / Automation Access Control Framework / Client AIOS Tool Risk Layer / Custom Connector Permission Standard / Cross-Workflow Access Standard / MCP Access Governance Standard / Local Credential Custody Standard
Primary Brain: HeadOffice Brain
Supporting Brains: Automation Brain, AIBS Brain, Data Brain, Risk Brain, Compliance Brain, SIT Brain, Operations Brain
Related Pages: MWMS AI Agent Operations Core, MWMS AI Agent Memory And Context Framework, MWMS AI Agent Orchestration Framework, MWMS AI Agent Failure Handling And Escalation Protocol, MWMS Independent Model Review And Rescue Routing Framework, MWMS External Knowledge Engine And Reasoning Agent Separation Framework, MWMS AI Tool Access Browser Automation And MCP Governance Framework, MWMS AI Automation Security And Risk Checklist, MWMS AI Permission Gatekeeper Framework, MWMS AI Plugin Orchestration Framework, MWMS AI Skill Installation And Usage Protocol, MWMS AI Skill Builder And Audit Protocol, MWMS n8n Operating And Deployment Standard, MWMS Automation Architecture And Tool Selection Framework, MWMS Client Context Isolation And Privacy Boundary Standard, MWMS Client Communication Automation Framework, MWMS Outbound Lead Enrichment And Cold Outreach Governance Framework, MWMS Supabase RAG And Vector Memory Framework, MWMS AI Observability Metadata Standard, MWMS AI Usage And Cost Visibility Standard
Source Evidence: The existing v1.4 framework already governs tools, APIs, databases, reusable connectors, custom modules, cross-workflow triggers, endpoints, workflow state, credentials, communication tools, generated files, voice systems, webhooks, personal data, scraping, enrichment, logging, failure handling and revocation.
Purpose
The purpose of the MWMS AI Tool Permission And Access Framework is to define how MWMS controls which AI Employees, automations, workflows, Brains, dashboards, agents and client AIOS systems may access:
tools
APIs
databases
files
communication channels
local command-line interfaces
browser automation
MCP servers
remote MCP endpoints
reusable connectors
custom modules
sub-workflows
external systems
local services
cloud services
persistent agents
scheduled routines
live business actions
This framework exists because AI becomes more powerful when connected to tools.
But tool access creates risk.
An AI Employee without tools may only produce recommendations.
An AI Employee with tools may:
read private data
change records
send communications
publish content
trigger workflows
modify files
deploy systems
access client information
initiate financial action
operate persistently
expose local services remotely
Tool access must therefore be governed as authority.
Connecting a tool does not mean every AI Employee may use it.
Installing a skill does not mean every embedded capability is approved.
Creating an MCP server does not mean every endpoint should be exposed.
Running a service locally does not make it safe.
Placing an agent in the cloud does not give it unrestricted operational authority.
This framework defines:
who may use a tool
what purpose the tool serves
what data may be accessed
what actions may be performed
what endpoints are permitted
what credentials may be used
where credentials are stored
whether access is local or remote
what approval is required
what must be logged
what happens when access fails
how access is revoked
how persistent access is controlled
how client boundaries are protected
how unofficial tools are governed
how remote tunnels and MCP services are secured
Core Principle
The core principle of this framework is:
Tool access must be granted according to role, task, authority, risk and evidence—not merely because the tool is available.
MWMS must operate according to least privilege.
Every AI Employee, workflow, connector, MCP server and automation should receive only the minimum access required to perform the approved task.
Access must be:
purpose-bound
role-bound
task-bound
data-bound
endpoint-bound
time-bound where appropriate
client-bound
observable
revocable
reviewable
Technical capability does not create operational authority.
Tool availability does not create permission.
Scope
This framework applies to:
AI Employees
AI agents
Brain workflows
Brain Room
AI Manager
AI Employee Router
Task Executor systems
persistent agents
scheduled agents
remote command channels
internal automations
client AIOS systems
dashboards
chatbots
voice agents
RAG systems
local applications
cloud applications
custom connectors
MCP servers
browser automation
CLI tools
database systems
file systems
communication systems
publishing systems
paid media systems
financial systems
developer tools
sub-workflows
webhook-triggered workflows
This framework applies whether access is:
manual
assisted
automated
agentic
local
cloud-based
temporary
persistent
direct
connector-based
MCP-based
API-based
browser-based
command-line based
Core Definitions
Tool
A system, application, service, API, command, connector or function that allows an AI Employee or workflow to retrieve information or perform action.
Permission
Explicit authority to use a defined tool capability within approved boundaries.
Access
The technical ability to connect to, read from, write to, change or trigger a system.
Credential
A secret or identity mechanism used to authenticate access.
Examples include:
API keys
passwords
OAuth tokens
session cookies
service-account keys
access tokens
SSH keys
client secrets
bearer tokens
Endpoint
A specific API route, MCP function, webhook path, CLI command or service function through which an action occurs.
MCP Server
A service exposing tools, resources or functions to an AI model or AI interface through the Model Context Protocol.
Local Tool
A tool executed inside a local, private or approved controlled environment.
Remote Tool
A tool accessed through a network endpoint, cloud service, tunnel or remote execution layer.
Tool Surface
The complete set of functions, commands, endpoints, files or data that a connected tool could technically access.
Approved Tool Surface
The limited subset of the Tool Surface that MWMS has explicitly permitted.
External Action
An action that changes a system, sends a communication, publishes content, creates a record, modifies data or affects an external person or business process.
Persistent Access
Tool access that remains available between sessions or allows unattended execution.
Tool Authority Rule
An AI Employee may use a tool only when all of the following are clear:
tool purpose
owning Brain
AI Employee or workflow using it
permission level
permitted data
permitted endpoints
prohibited actions
risk class
approval requirement
logging requirement
credential custody
revocation method
failure-handling method
maintenance owner
If any of these are unclear, access must remain restricted.
Permission Levels
MWMS defines seven permission levels.
Level 0 — No Access
The AI Employee may not use or inspect the tool.
Use when:
the tool is unrelated to the role
risk is too high
authority is absent
credentials are unavailable
governance is incomplete
client permission has not been granted
Level 1 — Discovery Access
The AI Employee may know that the tool exists and inspect approved public documentation.
It may not access private systems or data.
Level 2 — Read-Only Access
The AI Employee may retrieve approved information.
Examples:
reading a file
reading a database row
viewing a dashboard
checking approved records
retrieving calendar availability
searching a knowledge base
Read-only access still requires governance.
Reading sensitive information can create risk even when nothing is changed.
Level 3 — Draft And Prepare Access
The AI Employee may prepare an action but may not execute it.
Examples:
draft an email
prepare a database update
generate a report
create proposed content
prepare a deployment command
produce a task record
Execution requires a separate approval.
Level 4 — Controlled Write Access
The AI Employee may create or update approved records within defined boundaries.
Examples:
update a low-risk task status
create an internal draft
save a classified record
append a non-destructive log
update an authorised knowledge item
Controlled Write Access must define:
permitted records
permitted fields
permitted values
validation
rollback
duplicate prevention
Level 5 — External Action Access
The AI Employee may perform an action affecting an external system or person.
Examples:
send an email
publish content
update a CRM
trigger a client workflow
create a calendar event
submit a form
make a phone call
initiate outreach
This level requires stronger approval, logging and monitoring.
Level 6 — Administrative Or Destructive Access
The AI Employee may perform high-risk actions.
Examples:
delete records
alter permissions
manage credentials
deploy production systems
change infrastructure
modify billing
change schemas
revoke user access
overwrite important data
This level must remain human-controlled unless a specific governed exception exists.
Permission must be assigned at the lowest level sufficient for the task.
Draft Authority Does Not Imply Send Authority
Drafting, preparing, formatting, enriching, scheduling, staging, publishing and sending are separate permissions.
An AI Employee or workflow with Level 3 — Draft And Prepare Access may:
draft an email
prepare a reply
prepare outreach copy
prepare a proposal
prepare a calendar invitation
prepare publishing metadata
prepare an advertisement
prepare a CRM update
prepare a database change
prepare a client deliverable
It may not:
send the email
send the reply
launch the outreach
issue the proposal
create the external calendar event
publish the content
launch the advertisement
commit the CRM update
write the database change
deliver the client asset
unless a higher permission level is separately approved.
Draft Authority Rule
Draft authority does not imply send authority.
Prepare authority does not imply execute authority.
Review authority does not imply approval authority.
Approval authority does not imply technical execution authority.
Execution authority does not imply permission to change scope.
These permissions should remain separated wherever risk, external impact, client exposure, compliance, cost or irreversibility is material.
Minimum Tool Authority Standard
Every connected tool must expose only the minimum functions required for the approved task.
Examples:
A Gmail drafting workflow may receive:
search
read
create draft
update draft
It should not automatically receive:
send
delete
forward
archive
label administration
account settings
A Calendar preparation workflow may receive:
read availability
read event details
prepare proposed event information
It should not automatically receive:
create event
change attendees
cancel events
respond to invitations
A publishing workflow may receive:
create draft
preview
validate metadata
It should not automatically receive:
publish
schedule
delete
change account settings
A database reporting workflow may receive:
read approved views
It should not automatically receive:
insert
update
delete
schema change
administrative access
Minimum Tool Authority Rule
Do not approve a whole application when the task requires only one or two functions.
Connector-level access must be reduced to the smallest practical approved function set.
Where the platform cannot technically restrict functions, operational controls must compensate through:
separate accounts
restricted credentials
human approval
isolated environments
read-only views
allowlisted commands
pre-execution validation
post-action verification
logging
emergency revocation
External Communication Separation
External communication should use the following default stages:
Research
→ Draft
→ Review
→ Approve
→ Send
→ Verify
→ Record
Each stage should preserve:
recipient identity
message purpose
source basis
client boundary
approval owner
current status
duplicate status
send result
reply ownership
External Communication Rule
No AI-generated message should move from draft to send merely because the content appears complete.
The system must confirm:
correct recipient
correct account
correct client
correct message
approved claims
required disclosure
approval state
send timing
duplicate prevention
reply-handling ownership
High-volume or sensitive communication requires stronger review and suppression controls.
Permission Components
Every tool permission must define:
Tool Identity
tool name
provider
version
environment
connector or MCP server
Business Purpose
why access exists
what outcome it supports
what workflow uses it
User Of The Tool
AI Employee
Brain
automation
human operator
client system
Data Boundary
data sources permitted
data fields permitted
client boundary
personal-data boundary
confidential-data boundary
Action Boundary
read
draft
write
send
publish
delete
administer
Endpoint Boundary
endpoint path
function
HTTP method
CLI command
MCP tool
sub-workflow
webhook route
Time Boundary
one-time
session-only
scheduled
persistent
expiry
renewal
Approval Boundary
autonomous
human review
HeadOffice approval
client approval
M approval
compliance approval
finance approval
Observability Boundary
request logging
response logging
action logging
failure logging
cost logging
approval logging
Revocation Boundary
who may revoke
how access is revoked
emergency shutdown
credential rotation
endpoint closure
Tool Risk Classes
Class 1 — Internal Drafting Tools
Examples:
text drafting
internal formatting
note generation
non-sensitive document preparation
Risk:
Low
Default permission:
Draft and prepare only.
Class 2 — Internal Read Tools
Examples:
approved document retrieval
read-only database queries
internal dashboards
approved knowledge bases
Risk:
Low to moderate depending on data sensitivity.
Class 3 — Internal Write Tools
Examples:
task creation
record updates
knowledge-base updates
internal file creation
Risk:
Moderate.
Requires field-level and destination-level controls.
Class 4 — External Communication Tools
Examples:
Gmail
Slack
SMS
support systems
calendar invitations
Risk:
High.
External sending requires explicit communication authority.
Class 5 — Scraping And Enrichment Tools
Examples:
Firecrawl
browser scraping
lead enrichment tools
contact-data providers
social-platform extraction
Risk:
Moderate to high.
Requires source, purpose, data and compliance controls.
Class 6 — File And Report Generation Tools
Examples:
PDF generation
spreadsheet generation
image generation
proposal generation
ZIP creation
video generation
Risk:
Moderate.
Generated outputs may appear official and must be validated before external delivery.
Class 7 — Voice And Call Tools
Examples:
voice agents
telephone systems
call recording
live conversational agents
Risk:
High.
Requires approved scripts, handoff, disclosure, recording and action rules.
Class 8 — AIOS And Automation Infrastructure
Examples:
n8n
Make
Supabase
workflow engines
custom MCP servers
custom connectors
hosted agents
remote execution systems
Risk:
High.
Infrastructure can amplify small permission errors across many workflows.
Class 9 — Public Publishing And Paid Media Tools
Examples:
WordPress publishing
social publishing
advertising platforms
campaign-launch systems
Risk:
High to critical.
Requires human approval unless explicitly governed.
Class 10 — Financial, Billing And Administrative Tools
Examples:
payments
billing
subscription management
refunds
banking
ad-budget changes
access administration
Risk:
Critical.
Human approval is mandatory.
Role-Based Permission Rule
Tool access must be tied to an AI Employee role.
An AI Employee Role Card should define:
permitted tools
prohibited tools
permission level
permitted data
permitted actions
approval rules
escalation path
logging requirements
An AI Employee must not inherit all tools available to the platform.
Examples:
A Research Agent may receive:
web research access
approved document retrieval
read-only source databases
It should not automatically receive:
email sending
WordPress publishing
database deletion
financial tools
A Reporting Agent may receive:
approved data reads
calculation tools
report-generation tools
It should not automatically receive:
source-data modification
client communication
administrative access
A Course Absorption Agent may receive:
uploaded-file access
MCR search access
document-generation capability
It should not automatically receive:
WordPress publication access
development tools
Supabase write access
Task-Bound Permission Rule
Role permission alone is insufficient.
Each material task should define which approved role permissions are active for that task.
A tool permitted for one workflow may remain inactive for another workflow.
Example:
An AI Employee with Gmail draft permission may use Gmail during an approved outreach task.
It must not use Gmail during a course-absorption task.
Rule
Permission must be both role-approved and task-activated.
Credential Custody Standard
Credentials must remain inside an approved execution environment.
Approved credential locations may include:
platform-managed credential stores
environment variables
secrets managers
protected local configuration
approved server-side stores
encrypted system vaults
Credentials must not appear in:
prompts
chat messages
screenshots
portable skill files
public templates
exported workflow examples
source documents
session summaries
ordinary logs
client-facing reports
AI Employees should receive access to a capability, not unrestricted access to the credential itself.
Local Credential Custody Rule
Where an AI interface needs access to a locally authenticated tool:
credentials should remain local
authentication should occur in the approved local environment
the AI interface should call a governed service or MCP function
the tool response should return only the required result
raw credentials should not cross the interface boundary
access should remain revocable at the execution layer
This pattern is preferred over embedding active session cookies or credentials inside reusable skills.
Cookie And Session Token Rule
Active cookies and session tokens are credentials.
They must not be:
hard-coded in portable skills
copied into shared prompts
included in public repositories
sent to unrelated AI models
stored in long-term memory
published in documentation
Where a system depends on session cookies:
the dependency must be documented
expiry behaviour must be known
renewal must occur in the execution environment
unofficial access risk must be declared
revocation must be possible
a safer authentication method should be preferred where available
MCP Permission Governance
MCP allows AI interfaces to access tools and resources.
MCP access must be governed like any other external action surface.
Every MCP server must define:
server name
owner
purpose
environment
transport
tools exposed
resources exposed
credentials used
data accessible
write capability
destructive capability
authentication
client systems allowed
logging
failure handling
revocation
maintenance responsibility
MCP Tool-Level Permission
Permission must be applied at the individual tool or function level.
Connecting to an MCP server does not approve every exposed tool.
Each MCP function should define:
function name
purpose
input schema
permitted values
output schema
risk
approval requirement
rate limit
timeout
failure behaviour
logging
data sensitivity
MCP Resource Permission
Read-access resources must define:
source
scope
owner
client boundary
sensitivity
freshness
authority
retrieval limit
MCP Write Permission
Write-capable MCP functions require:
exact destination
allowed fields
validation
approval
idempotency
rollback
duplicate protection
logging
Local MCP Rule
A local MCP server may be appropriate when:
credentials must remain local
a CLI is already authenticated
files are stored locally
local privacy is required
direct cloud credentials should not be exposed
the capability is needed by several local AI interfaces
A local MCP server must not expose unrestricted:
shell access
file-system access
browser sessions
credential files
environment variables
administrative commands
Remote MCP Rule
A remote MCP service may be appropriate when:
several approved systems require access
the execution environment is persistent
the service can be authenticated
transport is secure
monitoring is available
revocation is practical
Remote MCP must define:
endpoint
authentication
approved clients
IP or network restrictions where appropriate
functions exposed
rate limits
logging
timeout
shutdown method
credential rotation
incident response
MCP does not bypass normal MWMS authority.
Local Service Exposure Rule
A local service may be exposed remotely only when:
the business need is clear
exposure is approved
the minimum necessary functions are exposed
authentication is applied
transport is secure
local files and commands remain restricted
logs are maintained
access can be revoked immediately
the service is monitored
the endpoint is not treated as public merely because it is technically reachable
Tunnel Governance
Cloudflare Tunnel, SSH tunnelling or equivalent technology may connect remote AI interfaces to local services.
Every tunnel must define:
tunnel owner
destination service
public or private endpoint
authentication
allowed users or systems
exposed functions
expected uptime
logs
shutdown method
credential rotation
maintenance owner
incident procedure
A tunnel creates connectivity.
It does not create permission.
Tunnel Prohibitions
MWMS prohibits:
exposing unrestricted local shells
exposing broad file-system access
exposing credential stores
leaving temporary tunnels active without ownership
using unauthenticated public endpoints for private tools
treating obscurity as security
sharing tunnel URLs in public templates
allowing a client to access another client’s service
using remote access without logs
Local CLI Access Rule
Local command-line tools may be useful for:
document processing
media extraction
data transformation
source ingestion
knowledge retrieval
development
file management
CLI access must define:
executable
permitted commands
permitted arguments
working directory
input paths
output paths
environment variables
network access
timeout
resource limits
destructive commands prohibited
logging
approval requirement
A model must not receive unrestricted shell access merely because one approved CLI is required.
Command Injection Protection
Where an AI supplies command arguments:
use structured arguments
avoid unsafe string concatenation
validate file paths
validate URLs
validate identifiers
reject unexpected flags
restrict working directories
escape or isolate untrusted input
use allowlists where practical
log executed commands
Untrusted source text must not become an executable command without validation.
Browser Automation Rule
Browser automation may:
open pages
read content
fill forms
click controls
upload files
submit data
access authenticated systems
Browser access must define:
approved domain
approved account
permitted actions
prohibited actions
submission boundary
payment boundary
external communication boundary
download and upload rules
session storage
screenshot handling
human approval requirement
Reading a page and submitting a form are different permission levels.
Browser automation must not cross from observation to action without approved authority.
API Endpoint Rule
A connector may technically access many endpoints.
MWMS must approve endpoints individually.
For every approved endpoint, define:
endpoint path
method
purpose
permitted input
prohibited input
response data
personal data
client data
rate limit
cost
write effect
approval
error handling
logging
version
A broad API key does not create broad operational permission.
Custom Connector Governance
Custom connectors require:
named owner
business purpose
API documentation
authentication method
endpoint inventory
field schema
input validation
output validation
versioning
test environment
failure behaviour
change management
revocation
maintenance plan
A custom connector must not become permanent infrastructure merely because it worked once.
Sub-Workflow Permission Rule
Reusable sub-workflows may be called by multiple parent workflows.
Each sub-workflow must define:
permitted callers
expected input
output
data boundary
action boundary
client boundary
duplication control
approval state
failure handling
logging
version
A parent workflow must not gain broader access by calling a more privileged sub-workflow.
Cross-workflow triggers must not bypass permissions.
Webhook Governance
Webhooks are workflow entry points.
Every serious webhook must define:
endpoint purpose
allowed method
authentication
expected payload
required fields
allowed source
replay protection
rate limits
duplicate protection
client identity
risk class
downstream actions
approval
logs
shutdown method
A webhook must not execute high-risk action merely because it received syntactically valid data.
Workflow Variable And State Permission Rule
Intermediate workflow values may include:
customer data
record IDs
approval status
calculations
API responses
generated content
file URLs
client identifiers
authentication context
State access must define:
variable purpose
data type
scope
source
downstream use
sensitivity
retention
logging
Temporary workflow state must not automatically become durable memory.
Cross-Client State Rule
Client identifiers must remain attached throughout the workflow.
No sub-workflow, queue, database query or MCP tool may lose the client boundary.
Client identity must be validated before:
retrieval
write action
communication
file delivery
reporting
memory update
knowledge-base access
External Action Rule
External action includes:
sending email
sending messages
publishing content
updating CRM records
changing advertisements
creating appointments
making calls
modifying client data
triggering public workflows
creating financial consequences
Before external action, the system must confirm:
recipient or destination
purpose
content
source knowledge
authority
client
risk
approval
duplicate status
execution timing
logging
rollback or correction path
AI-generated content must not be sent merely because it was generated successfully.
Human Approval Gates
Human approval is mandatory for:
financial transactions
billing changes
refunds
paid media launch or major budget change
public publication where not explicitly delegated
destructive database action
production deployment
permission expansion
credential changes
legal or compliance-sensitive communication
client-facing final delivery where required
high-volume outreach
first-time use of a new external communication route
transition from draft-only to send-capable authority
irreversible action
access to highly sensitive data
actions involving unclear ownership
persistent agent permission expansion
Approval must be recorded.
Approval for one action does not automatically approve future actions.
Communication Tool Rule
Communication tools require stronger governance than internal tools.
Before AI may send or trigger communication, define:
recipient
purpose
message type
approved source knowledge
tone
risk category
human review requirement
opt-out where relevant
escalation path
logging
reply-handling process
AI must not communicate externally unless the communication path is approved.
Drafting and sending are separate permissions.
Draft authority does not imply send authority.
An AI Employee with draft permission must remain technically or procedurally blocked from sending unless send authority is separately assigned.
Scraping And Enrichment Rule
Before scraping or enrichment, define:
source
collection purpose
data collected
data excluded
platform and terms risk
personal-data risk
storage location
retention
client
outreach purpose
opt-out handling
suppression handling
human review
deletion method
Scraping and enrichment are not casual research when they involve identifiable people, prospects, customers or client systems.
Personal Data Rule
Personal data may include:
names
email addresses
phone numbers
social profiles
transcripts
chat messages
customer reviews
CRM records
support tickets
voice recordings
call summaries
prospect records
workflow variables containing personal information
Personal-data use must be:
purpose-limited
minimised
permissioned
client-isolated
access-controlled
retained only as required
logged where appropriate
deletable where required
Client Data Rule
Client data must remain within the approved client boundary.
Tool access must define:
client owner
authorised AI Employees
authorised workflows
approved data sources
permitted outputs
retention
deletion
transfer restrictions
reporting rules
handoff rules
No tool may expose one client’s data to another client’s workflow.
Generated File Rule
Generated files can appear official.
Examples include:
PDFs
proposals
reports
spreadsheets
ZIP files
images
transcripts
videos
client deliverables
Before external delivery, validate:
file content
client identity
recipient
sensitivity
factual accuracy
source basis
approval
filename
version
attachment set
Voice And Call Tool Rule
Voice workflows must define:
assistant role
script scope
approved knowledge
prohibited claims
disclosure
consent
recording policy
handoff trigger
transfer path
tool-call boundary
post-call summary
error handling
memory rules
escalation
Voice AI should launch in controlled mode before autonomous client deployment.
Database Permission Rule
Database access must define:
database
environment
schema
table
view
permitted rows
permitted columns
read or write level
allowed operations
validation
transaction rules
rollback
duplicate control
logging
client boundary
Database Permission Levels
Read-only query
Insert-only
Controlled update
Append-only log
Delete
Schema modification
Administrative access
Delete, schema modification and administrative access require human approval unless a stricter approved automation exists.
File-System Permission Rule
File access must define:
approved root directory
readable paths
writable paths
prohibited paths
file types
size limits
deletion permission
overwrite permission
retention
client ownership
external upload permission
An AI Employee must not receive unrestricted access to the full machine when it only needs one project folder.
Knowledge Tool Rule
Tools connected to external knowledge engines may:
search documents
retrieve sources
add sources
delete sources
create notebooks
generate reports
create audio
create video
create quizzes
create presentations
update knowledge collections
These capabilities must be separated.
A reasoning agent with search permission must not automatically receive:
source deletion
knowledge-base replacement
external sharing
public publication
permanent memory write
destructive notebook administration
Knowledge Write Rule
Adding information to durable knowledge requires:
source identity
owner
destination
validation
authority
duplicate check
status
version
client boundary
provenance
approval where required
Retrieved knowledge and committed knowledge are different permission classes.
Unofficial Tool And API Governance
Unofficial tools, community CLIs, browser wrappers and reverse-engineered APIs may create useful capabilities.
They also create:
authentication risk
maintenance risk
breakage risk
platform-term risk
rate-limit risk
data exposure
silent failure
dependency risk
Before approval, record:
tool owner
repository or source
unofficial status
version
authentication method
permissions requested
data exposed
maintenance activity
failure behaviour
fallback
replacement path
deprecation trigger
Unofficial tools must not be treated as permanent critical infrastructure without review.
Portable Skill Tool Rule
A skill may describe how to use tools.
A portable skill must not include:
active credentials
session cookies
client secrets
private endpoint tokens
unrestricted shell commands
hidden destructive actions
unapproved external-action routes
A skill should declare:
required tools
required permissions
dependencies
setup state
approval requirements
failure behaviour
safe fallback
output destination
logging requirement
Tool Installation and Tool Permission are separate decisions.
Installing a tool does not approve its operational use.
Persistent Agent Access Rule
Persistent agents may operate:
continuously
on schedules
through webhooks
through remote commands
while the initiating user is offline
Persistent access requires:
named owner
defined role
approved tools
approved schedule or trigger
execution limits
cost limits
notification rules
failure threshold
stop condition
shutdown method
revocation
logging
human escalation
A persistent agent must not gain broader permission merely because it runs continuously.
Scheduled Task Rule
A scheduled task must define:
frequency
purpose
data source
action
risk
maximum execution count
duplicate prevention
failure alert
approval
expiry or review date
Unneeded scheduled tasks should be disabled.
Remote Command Channel Rule
Remote command channels may include:
mobile chat
voice command
webhook
secure messaging
cloud task submission
remote agent console
Every remote command channel must:
authenticate the sender
preserve sender identity
validate the command
classify risk
restrict actions
log the command
require approval where necessary
support revocation
prevent unrestricted command execution
A message arriving through an approved channel is not automatically an approved action.
Tool Failure Handling
When a tool fails, the AI Employee must:
Stop repeated identical execution.
Preserve the exact error.
Record the operation attempted.
Identify whether any data changed.
Confirm the last known good state.
Determine whether retry is safe.
Check the failure count.
Route to rescue after the required threshold.
Use an approved fallback only.
Disclose reduced confidence.
Escalate where risk is material.
Validate the final state before resuming.
Tool failure does not authorise:
guessing
silent use of another credential
switching to a less secure path
broadening access
disabling validation
continuing external action
hiding the failure
Repeated Tool Failure Rule
Two materially identical tool failures without verified progress trigger rescue routing.
At the threshold:
the current route stops
attempt history is preserved
a different technical or reasoning path is assigned
the next verification gate is defined
high-risk execution remains blocked
Fallback Tool Rule
A fallback tool may be used only when:
it is approved
its permission level is known
data handling is acceptable
the reduced capability is disclosed
the result can be validated
it does not bypass security
it does not expand access
Availability does not create approval.
Tool Access Logging
Material tool use should record:
tool
version
connector
endpoint or function
user or AI Employee
owning Brain
task
client
timestamp
permission level
input classification
data accessed
action performed
approval
result
failure
cost
external effect
output destination
revocation event where relevant
Sensitive payloads should be redacted.
Logs must contain enough information to reconstruct action without unnecessarily storing private data or credentials.
Observability Requirements
MWMS should be able to answer:
Who used the tool?
For which task?
Under which role?
What permission applied?
What data was accessed?
Which endpoint ran?
Was anything changed?
Was external action taken?
Was human approval required?
Did the tool fail?
Was a fallback used?
What did it cost?
Can access be revoked?
Which client was affected?
Access Revocation Rule
Every material tool integration must have a revocation process.
Revocation may include:
disable connector
revoke OAuth access
rotate key
delete token
close tunnel
disable MCP server
stop agent
remove workflow permission
disable webhook
block client
change role card
remove environment variable
disable scheduled task
Access should be revoked when:
role changes
task ends
client relationship ends
credential exposure occurs
tool is deprecated
repeated failure occurs
permission is abused
system ownership changes
security cannot be verified
maintenance ends
the capability is no longer needed
Emergency Shutdown Rule
High-risk systems must have an immediate shutdown method.
Emergency shutdown should stop:
external communication
financial action
persistent agents
remote commands
destructive writes
scheduled workflows
public publishing
client-facing action
remote tunnels
Emergency shutdown must not depend on the failing AI Employee cooperating.
Permission Review Cycle
Tool permissions should be reviewed:
when a role changes
when a workflow changes
after a failure
after a security incident
before client deployment
before autonomy increases
when a tool version changes
when an endpoint changes
when credentials change
when a client offboards
when an unofficial dependency changes
during scheduled governance review
Dormant access should be removed.
Temporary permissions should expire.
Permission Escalation Rule
AI Employees must not increase their own permissions.
Permission expansion requires:
stated business need
current role
proposed permission
risk assessment
data assessment
approval
testing
logging
review date
rollback
revocation
A tool asking for broader scopes than required should not be approved without justification.
Client AIOS Tool Governance
Every client AIOS must define:
client-owned tools
MWMS-managed tools
client credentials
MWMS credentials
data boundary
permission matrix
approval rules
maintenance owner
failure response
offboarding process
revocation
logs
emergency stop
client reporting
Client credentials must not be reused across unrelated clients.
Client production access must not be used for experimentation without approval.
Client Offboarding Rule
Offboarding must include:
disable workflows
revoke access
rotate shared credentials
close tunnels
disable MCP servers where required
remove client data from active systems
export approved records
preserve required audit history
delete data where required
confirm completion
HeadOffice Responsibilities
HeadOffice owns system-wide tool permission governance.
HeadOffice is responsible for:
defining permission levels
approving high-risk access
resolving cross-Brain conflicts
governing human approval
governing persistent agents
governing remote access
governing permission expansion
ensuring access remains connected to business purpose
protecting MCR and MWMS systems
ensuring tool access is reviewable and revocable
Automation Brain Responsibilities
Automation Brain is responsible for:
workflow-level tool mapping
connector design
trigger control
sub-workflow permissions
retry control
idempotency
duplicate prevention
workflow failure handling
deployment controls
maintainability
AIBS Brain Responsibilities
AIBS Brain is responsible for:
client tool boundaries
client approval rules
client credential separation
client data isolation
client reporting
client offboarding
commercial scope
client AIOS tool design
Data Brain Responsibilities
Data Brain is responsible for:
data classification
database permissions
source identity
retention
deletion
client isolation
provenance
retrieval permissions
knowledge commitment integrity
Risk And Compliance Responsibilities
Risk Brain and Compliance Brain are responsible for:
personal-data risk
scraping risk
outreach risk
platform risk
client-facing risk
legal and policy uncertainty
high-risk communication
financial and regulated action
SIT Brain Responsibilities
SIT Brain may:
inspect tool permissions
block unauthorised actions
verify reviewer independence
detect permission drift
detect unsupported access
test revocation
test emergency shutdown
inspect logs
enforce failure thresholds
verify client boundaries
trigger escalation
require permission reduction
Tool Permission Record
Every material tool integration should have a Tool Permission Record containing:
Tool Name:
Provider:
Version:
Environment:
Connector Or MCP Server:
Owning Brain:
Supporting Brains:
AI Employee Or Workflow:
Business Purpose:
Client:
Permission Level:
Approved Functions:
Approved Endpoints:
Approved Commands:
Approved Data:
Prohibited Data:
Approved Actions:
Prohibited Actions:
External Action Possible:
Draft Authority:
Approval Authority:
Send Or Execute Authority:
Persistent Access:
Remote Access:
Authentication Method:
Credential Storage:
Credential Owner:
Personal Data:
Client Data:
Human Approval:
Compliance Review:
SIT Review:
Input Validation:
Output Validation:
Rate Limit:
Cost Limit:
Duplicate Protection:
Failure Threshold:
Fallback:
Logging:
Monitoring:
Revocation:
Emergency Shutdown:
Maintenance Owner:
Review Date:
Status:
Tool Permission Checklist
Before approving a tool, confirm:
Tool name is known.
Provider is known.
Version is known.
Environment is known.
Business purpose is clear.
Owning Brain is clear.
AI Employee or workflow is known.
Permission level is defined.
Approved functions are defined.
Approved endpoints are defined.
Data accessed is defined.
Client boundary is defined.
Personal-data use is known.
External action is known.
Draft authority is separated from send or execute authority.
Only the minimum required tool functions are enabled.
Persistent access is known.
Remote exposure is known.
Credential location is secure.
Credentials are not inside prompts or skills.
Input validation exists.
Allowed values are defined.
Output validation exists.
Human approval is defined.
Logging exists.
Failure handling exists.
Retry limits exist.
Rescue route exists.
Duplicate protection exists.
Revocation exists.
Emergency shutdown exists.
Maintenance owner exists.
Compliance review is complete where required.
SIT testing is complete where required.
Review date is assigned.
Failure Modes
Failure Mode 1 — Tool Added Because It Is Available
A tool is connected without a clear workflow need.
Correction:
Require purpose, role, permission and outcome before connection.
Failure Mode 2 — Read Access Treated As Safe
Sensitive data is read, exposed or misused.
Correction:
Classify data before granting read access.
Failure Mode 3 — Role Receives Platform-Wide Access
An AI Employee inherits every available tool.
Correction:
Use role-level and task-level activation.
Failure Mode 4 — Credential Embedded In Prompt Or Skill
Portable content exposes secrets.
Correction:
Keep credentials in the execution environment and expose only governed capability.
Failure Mode 5 — MCP Server Exposes Too Much
A useful function is packaged with broad file, shell or administrative access.
Correction:
Approve individual MCP functions and restrict the Tool Surface.
Failure Mode 6 — Tunnel Treated As Security
An obscure endpoint is assumed safe.
Correction:
Apply authentication, transport controls, logs and revocation.
Failure Mode 7 — Local Tool Assumed Safe
A local CLI can access sensitive files or commands.
Correction:
Restrict executable, arguments, directories and environment.
Failure Mode 8 — Endpoint Scope Too Broad
A connector receives broad API permission.
Correction:
Approve endpoints, methods and fields individually.
Failure Mode 9 — Parent Workflow Inherits Privileged Sub-Workflow
Cross-workflow routing bypasses permissions.
Correction:
Validate the caller and enforce sub-workflow boundaries.
Failure Mode 10 — Draft Permission Becomes Send Permission
AI-generated content is transmitted without approval.
Correction:
Separate draft, approve and send stages.
Failure Mode 11 — Workflow State Leaks Across Clients
Client identity is lost between stages.
Correction:
Preserve and validate client identifiers through every call.
Failure Mode 12 — Persistent Agent Runs Without Stop Condition
An agent continues after failure or changing requirements.
Correction:
Define limits, failure threshold, monitoring and emergency shutdown.
Failure Mode 13 — Repeated Trigger Creates Duplicate Action
Webhook, schedule or retry repeats an external action.
Correction:
Use idempotency, deduplication, execution locks and status checks.
Failure Mode 14 — Unofficial API Becomes Critical Infrastructure
A community tool fails or changes unexpectedly.
Correction:
Document unofficial status, maintenance, fallback and replacement route.
Failure Mode 15 — Tool Failure Causes Guessing
The AI fabricates a result after access fails.
Correction:
Disclose failure, use approved fallback or stop.
Failure Mode 16 — Debugging Exposes Sensitive Payloads
Requests and responses are copied into public tools or unapproved channels.
Correction:
Redact, minimise and use approved inspection environments.
Failure Mode 17 — Tool Claims Are Not Verified
AI states that a file, page or database was changed when only a draft was prepared.
Correction:
Separate prepared, executed and verified status.
Failure Mode 18 — Dynamic Memory Write Is Uncontrolled
A chatbot or AI Employee stores unverified user information.
Correction:
Define writable fields, validation, consent, logging and correction.
Failure Mode 19 — Remote Command Becomes Unrestricted Control
A message channel can execute broad system actions.
Correction:
Authenticate, classify, restrict and approve every command type.
Failure Mode 20 — Access Is Never Revoked
Old workflows and agents retain permissions.
Correction:
Use review dates, expiry, offboarding and dormant-access removal.
Failure Mode 21 — Tool Permission Expands During Rescue
A failing agent attempts to solve the problem by accessing more systems.
Correction:
Permission expansion requires separate approval and risk review.
Failure Mode 23 — Draft Authority Silently Becomes Send Authority
A workflow that was approved to prepare content gains the ability to transmit, publish, schedule or commit the action.
Correction:
Separate draft, review, approval, execution and verification permissions. Remove send-capable functions from the connector unless they are explicitly required and approved.
Failure Mode 24 — Whole-Application Access Is Granted For A Narrow Task
A workflow requiring one function receives the complete tool surface.
Correction:
Apply function-level access, restricted credentials, read-only views, allowlists, isolated accounts or compensating approval controls.
Failure Mode 22 — Knowledge Search Permission Becomes Knowledge Administration
An agent that retrieves information also deletes or replaces sources.
Correction:
Separate retrieval, source addition, update, sharing and deletion permissions.
Minimum Compliance Standard
A tool-enabled workflow is compliant only when:
tool purpose is defined
role and task are identified
owning Brain is clear
permission level is assigned
approved functions are defined
data boundary is defined
client boundary is defined
credentials are protected
approval requirements are clear
external action is controlled
logging is enabled
failure handling is defined
retry limits are defined
rescue routing is defined
revocation is possible
emergency shutdown exists where required
maintenance ownership exists
high-risk access has human approval
Drift Protection
This framework protects MWMS from:
tool access without purpose
broad permissions
credential leakage
raw credentials inside prompts
portable skills containing secrets
MCP servers exposing unrestricted systems
tunnels without authentication
local tools with broad shell access
remote agents without stop controls
persistent agents without review
cross-workflow permission escalation
client-data leakage
automated external communication without approval
draft permission silently becoming send permission
whole-application access being granted where only limited functions are required
unofficial APIs becoming hidden dependencies
database writes without field controls
public publication without review
dynamic memory writes without governance
repeated tool retries
permission expansion during failure
logs containing secrets
dormant access remaining active
AI claiming action without verification
connectivity being confused with authority
Any workflow showing these drift signals must be paused and reviewed.
Architectural Intent
The architectural intent of the MWMS AI Tool Permission And Access Framework is to ensure that MWMS gains the operational value of connected AI systems without giving uncontrolled authority to models, agents, automations or client workflows.
MWMS should be able to answer:
What tool is connected?
Why is it connected?
Who may use it?
For which task?
Which Brain owns it?
What data may it access?
Which client does the data belong to?
Which functions are permitted?
Which endpoints are permitted?
Can it write?
Can it communicate externally?
Can it operate persistently?
Is access local or remote?
Where are credentials stored?
What must never be exposed?
What approval is required?
What is logged?
What happens when it fails?
When does rescue routing begin?
How is access revoked?
How is the system shut down?
Who maintains the integration?
When MWMS can answer these questions consistently, tool access becomes a governed operating capability rather than an uncontrolled risk.
Strategic Summary
The v1.5 update strengthens the MWMS AI Tool Permission And Access Framework by adding:
local credential custody
prohibition on credentials and cookies inside portable skills
MCP server and function-level permission controls
local and remote MCP governance
local service exposure controls
tunnel governance
restricted CLI access
command-injection protection
unofficial API governance
portable skill tool declarations
persistent-agent access controls
remote command-channel controls
external knowledge tool permissions
knowledge-write separation
repeated tool-failure rescue routing
stronger revocation and emergency shutdown
draft-only communication authority
minimum tool authority and function-level connector restriction
The key shift is:
A tool should expose a governed capability, not unrestricted access to the underlying system.
Credentials should stay inside the execution environment.
MCP connects AI to capability, but does not create authority.
Remote access creates connectivity, but does not create permission.
Persistent operation increases the need for controls; it does not reduce them.
Final Rule
No AI Employee, automation, dashboard, chatbot, voice agent, RAG system, custom connector, MCP server, remote agent or client AIOS workflow should use a tool unless its permission boundary is clear.
No credential should be placed inside a prompt, portable skill, ordinary log or reusable source file.
No remote tunnel, local service or MCP server should expose more capability than the approved task requires.
No persistent agent should operate without:
bounded authority
monitoring
failure limits
revocation
emergency shutdown
Tool access must remain:
role-bound
task-bound
endpoint-bound
data-bound
client-bound
approval-bound
observable
revocable
Change Log
Version: v1.6
Date: 2026-06-20
Author: HeadOffice
Change:
Updated the MWMS AI Tool Permission And Access Framework using the AI Automations by Jack video transcript block covering Hermes, Claude, Apollo, Gmail, Calendar, MCP connectors and least-privilege tool setup.
Added Draft Authority Does Not Imply Send Authority.
Added explicit separation between:
drafting
review
approval
sending
publishing
scheduling
writing
executing
verification
Added Minimum Tool Authority Standard requiring each connected tool to expose only the smallest practical approved function set.
Added Gmail, Calendar, publishing and database examples showing how draft or read workflows should remain restricted from sending, publishing, deleting, modifying attendees, writing data or administering accounts.
Added External Communication Separation:
Research
→ Draft
→ Review
→ Approve
→ Send
→ Verify
→ Record
Expanded Human Approval Gates, Tool Permission Record, Tool Permission Checklist, Drift Protection and Failure Modes.
Added failure modes covering:
draft authority silently becoming send authority
whole-application access being granted for a narrow task
Change Impact Declaration
This v1.6 update strengthens the existing least-privilege architecture by making draft-only authority explicit and by requiring function-level connector restriction wherever practical.
Pages Created
None
Pages Updated
MWMS AI Tool Permission And Access Framework
Pages Deprecated
None
Standalone Pages Not Created
MWMS Draft-Only Communication Permission Standard
MWMS Minimum Connector Authority Standard
MWMS Gmail AI Permission Framework
MWMS Calendar AI Permission Framework
These concepts were absorbed into the existing tool-permission framework rather than created as separate pages.
Registries Requiring Update
HeadOffice Page Registry
Automation Brain Page Registry
MWMS Canon Index
MWMS Course Absorption Decision Registry
Canon Version Update Required
No
Change Log Entry Required
Yes
Strategic Absorption Result
MWMS gains a clearer separation between preparing and executing external actions. AI Employees may research, read and draft without automatically receiving send, publish, write, delete or administrative authority, reducing communication, client, data and operational risk across connected AI systems.
Version: v1.5
Date: 2026-06-17
Author: HeadOffice
Change:
Updated the MWMS AI Tool Permission And Access Framework using the AI Automations by Jack block covering ClaudeOS, NotebookLM, Pinecone, MCP servers, local CLI tools, Cloudflare Tunnel, persistent cloud agents, remote command channels, portable skills and cross-interface knowledge access.
Added Local Credential Custody Standard.
Added Cookie And Session Token Rule.
Expanded MCP Permission Governance to include server registration, function-level permission, resource permission, write permission, local MCP and remote MCP.
Added Local Service Exposure Rule.
Added Tunnel Governance and Tunnel Prohibitions.
Added Local CLI Access Rule and Command Injection Protection.
Expanded Browser Automation Rule.
Added Knowledge Tool Rule and Knowledge Write Rule.
Added Unofficial Tool And API Governance.
Added Portable Skill Tool Rule.
Added Persistent Agent Access Rule.
Added Scheduled Task Rule.
Added Remote Command Channel Rule.
Expanded Tool Failure Handling with deterministic repeated-failure rescue routing.
Added Fallback Tool Rule.
Expanded Access Revocation and Emergency Shutdown.
Expanded Tool Permission Record and Tool Permission Checklist.
Added new failure modes covering MCP overexposure, tunnels, local CLI access, unofficial APIs, dynamic memory writes, unrestricted remote commands, unrevoked access and permission expansion during failure.
Aligned the framework with:
MWMS Independent Model Review And Rescue Routing Framework
MWMS External Knowledge Engine And Reasoning Agent Separation Framework
MWMS AI Agent Failure Handling And Escalation Protocol
MWMS AI Agent Memory And Context Framework
MWMS AI Agent Orchestration Framework
MWMS AI Tool Access Browser Automation And MCP Governance Framework
MWMS AI Automation Security And Risk Checklist
MWMS AI Observability Metadata Standard
Purpose of update:
To extend MWMS tool governance beyond APIs, automation connectors and workflow modules into local tools, MCP services, remote tunnels, persistent AI agents, cross-interface knowledge access and portable AI skill systems.
Version: v1.4
Date: 2026-06-14
Author: HeadOffice
Change:
Updated the MWMS AI Tool Permission And Access Framework using the AI Automations by Jack Make Workflow Modularity Block.
Added stronger governance for:
reusable connectors
custom Make modules
endpoint permissions
dynamic parameters
workflow state
cross-workflow triggers
API debugging
connector versioning
custom connector ownership
Purpose of update:
To govern reusable modules and custom connectors as operational permission surfaces rather than treating them as ordinary workflow conveniences.
Version: v1.3
Date: 2026-06-01
Author: HeadOffice
Change:
Expanded the framework using the AI Automations by Jack AI Agents And n8n Client Automation block.
Added stronger governance for:
n8n
Make
webhooks
communication systems
scraping and enrichment tools
voice agents
CRMs
file-generation tools
Gmail
Google Drive
Google Sheets
Airtable
Supabase
AI application front ends
Added Tool Risk Classes, Permission Matrix, External Action Rule, Client Data Rule, Personal Data Rule, Scraping And Enrichment Rule, Communication Tool Rule, Generated File Rule, Voice And Call Tool Rule, Webhook Tool Rule, Self-Hosted Tool Rule, Human Approval Gates, Logging Requirements, Tool Failure Handling, Access Revocation Rule, Tool Permission Checklist and expanded failure modes.
Purpose of update:
To strengthen MWMS tool governance for advanced automation workflows connecting AI systems to communication channels, CRMs, prospect databases, scraping tools, voice agents, report generators, file systems, databases, dashboards, webhooks and client-facing AIOS workflows.
Version: v1.2
Date: 2026-05-31
Author: HeadOffice
Change:
Expanded the framework after earlier AI Automations by Jack material, strengthening permission rules for AI Operating Systems, advanced automation workflows, context-aware AI Employees, workflow tools and client-facing automation systems.
Purpose of update:
To align tool governance with the growing MWMS direction toward AI Employees, AIOS systems, automation workflows and client-facing AIBS packages.
Version: v1.0 / v1.1
Date: Prior Drafts
Author: HeadOffice
Change:
Created and refined the original MWMS AI Tool Permission And Access Framework to define how AI Employees and MWMS workflows should access tools, APIs, databases, files and external systems inside governed permission boundaries.
Purpose of creation:
To prevent AI Employees and automations from using tools without role clarity, authority limits, human approval where required, logging and risk controls.
Change Impact Declaration
This v1.5 update expands the framework from workflow, API and connector governance into a complete tool-access architecture covering local credentials, MCP servers, remote service exposure, tunnels, portable skills, persistent agents, knowledge tools and cross-interface AI access.
Pages Created
None
Pages Updated
MWMS AI Tool Permission And Access Framework
Pages Deprecated
None
Standalone Pages Not Created
MWMS NotebookLM MCP Permission Framework
MWMS Cloudflare Tunnel Governance Framework
MWMS Local CLI Permission Standard
MWMS Portable Skill Credential Standard
MWMS ClaudeOS Tool Access Framework
MWMS Persistent Agent Permission Framework
MWMS Remote Command Channel Permission Framework
MWMS Local Service Exposure Standard
Registries Requiring Update
HeadOffice Page Registry
Automation Brain Page Registry
MWMS Canon Index
MWMS Course Absorption Decision Registry
Canon Version Update Required
No
Change Log Entry Required
Yes
Strategic Absorption Result
MWMS gains a stronger tool-access governance layer that keeps credentials inside approved execution environments, limits MCP and local-service exposure, controls remote and persistent access, separates knowledge retrieval from knowledge administration, stops repeated tool-failure loops and preserves revocation and human authority across every connected AI workflow.
END OF FULL FILE OUTPUT