System: MWMS
Document Type: Checklist / Governance Framework
Authority Level: MCR Source Of Truth
Status: Active
Version: v1.4
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, Risk Brain, Compliance Brain, Automation Brain, AIBS Brain, Data Brain, Operations Brain, SIT Brain, Client AIOS Systems
Parent Page: HeadOffice
Owner: Martyn
Source Of Truth: MCR
Last Reviewed: 2026-06-21
Source / Origin: MWMS AI Automation Security And Risk Checklist v1.3 Completion And AI Automations by Jack Security Risk Absorption Review
MWMS Classification: AI Automation Security Standard / Risk Governance Checklist / Client System Preflight Framework / Client AIOS Security Standard
Primary Brain: HeadOffice Brain
Supporting Brains: Risk Brain, Compliance Brain, Automation Brain, AIBS Brain, Data Brain, Operations Brain, SIT Brain, Sales Brain, Customer Brain, Content Brain, Research Brain
Related Pages: MWMS AI Tool Permission And Access Framework, MWMS Automation Architecture And Tool Selection Framework, MWMS n8n Operating And Deployment Standard, MWMS Client Communication Automation Framework, MWMS Outbound Lead Enrichment And Cold Outreach Governance Framework, MWMS AI Output Validation Standard, MWMS AI Work Session Persistence Standard, MWMS AI Tool Access Browser Automation And MCP Governance Framework, MWMS AI Guardrail And Preflight Check Standard, MWMS AI Permission Gatekeeper Framework, MWMS AI Agent Failure Handling And Escalation Protocol, MWMS Source Visibility And Evidence Display Standard, MWMS Prompt Architecture And Automation Output Reliability Framework, MWMS Personalised Visual Sales Asset Production And Governance Framework, MWMS Market Driven Social Content Production Framework, Risk Brain Dependency Exposure Framework, Risk Brain Risk Escalation Framework, Operations Brain Execution Reliability Framework, SIT Brain Canon
Purpose
The purpose of the MWMS AI Automation Security And Risk Checklist is to define the minimum security, privacy, governance, reliability and client-safety requirements that must be reviewed before MWMS tests, activates, deploys, scales, publishes, sells or hands over an AI automation or AI Operating System.
This page is the core security gate.
It does not replace specialist operational frameworks.
It defines the mandatory checks that every important automation must pass before it can be trusted.
This checklist exists because AI automations may touch:
credentials
client data
customer data
personal data
databases
files
emails
messages
voice calls
CRM records
reports
proposals
webhooks
APIs
AI models
custom connectors
workflow state
public content
business decisions
financial systems
live client operations
A system that works technically may still be unsafe.
A system is not production-ready merely because it completes the expected task.
It must also be:
permissioned
observable
recoverable
validated
cost-controlled
maintainable
client-safe
compliance-aware
owned
testable
The purpose of this page is to make those requirements visible before harm occurs.
Core Doctrine
The MWMS security doctrine is:
Security is part of system design.
Security is not a final-stage addition.
Every important automation must be designed under the assumption that:
inputs may be wrong
external text may be malicious
credentials may be exposed
tools may fail
APIs may change
users may make mistakes
workflows may repeat
data may be sent to the wrong place
AI may produce false or incomplete output
client boundaries may be crossed accidentally
third-party services may become unavailable
The correct security question is not:
Does the automation work?
The correct security question is:
Can the automation work safely, repeatedly, visibly and recoverably under both normal and failure conditions?
Core Security Standard
An MWMS automation is not ready for production until the following are clear:
business purpose
system owner
data handled
tools connected
permissions granted
external actions possible
risk level
human approval requirements
input validation
output validation
logging
failure handling
cost exposure
backup and recovery
incident response
client responsibility
support responsibility
shutdown and revocation path
Scope
This checklist applies to:
internal MWMS workflows
client AIOS systems
AI Employees
n8n workflows
Make scenarios
WordPress automations
Supabase systems
RAG systems
chatbots
voice agents
lead systems
outreach systems
content systems
reporting systems
proposal systems
customer communication systems
AI app interfaces
webhooks
custom connectors
reusable sub-workflows
API integrations
file generation systems
database workflows
future automated Brain operations
This page governs whether a system is safe enough to proceed.
Detailed tool-specific instructions belong in the relevant specialist framework.
Security Risk Levels
MWMS classifies AI automation risk across four levels.
Level 1: Low Risk
Typical examples:
summarising public information
drafting internal notes
classifying non-sensitive records
generating internal ideas
creating non-operational recommendations
Requirements:
basic logging
basic output review
no sensitive data
no live external action
clear owner
Level 2: Moderate Risk
Typical examples:
updating internal task records
creating report drafts
updating internal dashboards
reading approved internal data
using low-risk internal tools
generating client-facing drafts that still require review
Requirements:
access control
input validation
output validation
logging
limited permissions
human review before external use
known failure path
Level 3: High Risk
Typical examples:
sending emails
sending messages
updating CRM records
using client data
publishing content
triggering external workflows
generating client reports
using enriched prospect data
customer-facing chatbot or voice interactions
shared write-enabled connectors
Requirements:
human approval unless narrowly approved
client data review
permission review
prompt injection controls
duplicate-action protection
audit trail
failure handling
compliance review where relevant
SIT testing
Level 4: Critical Risk
Typical examples:
payment actions
billing changes
record deletion
legal or regulated workflows
health or financial data workflows
budget changes
production infrastructure changes
high-volume outreach
public connectors with powerful write access
autonomous customer communication with material consequences
Requirements:
strict human approval
strong access restrictions
formal compliance or legal review where required
backup and recovery
incident response plan
production monitoring
limited automation authority
explicit executive approval
MWMS Risk Rule
The higher the risk, the narrower the permission and the stronger the review gate.
Mandatory Security Control Areas
Every important automation must be reviewed across twelve control areas.
Purpose And Ownership
Confirm:
the business problem is clear
the automation has a justified purpose
the system owner is known
the Brain owner is known
the maintenance owner is known
the client owner is known where relevant
support responsibility is defined
shutdown authority is defined
MWMS Rule
No automation should operate without a named owner.
Data Classification And Minimisation
Identify whether the system handles:
public data
internal data
confidential data
restricted data
personal data
client data
customer data
financial data
health data
legal data
credentials
Determine:
what data is necessary
what data can be excluded
what data can be redacted
what data can be anonymised
where data is stored
how long data is retained
who can access it
how it can be deleted
MWMS Rule
Do not collect, store or send data merely because the system can.
Use only the data required for the task.
Credential And Secret Protection
Confirm:
API keys are not visible in prompts
API keys are not stored in shared notes
credentials are not hardcoded
secrets are not included in screenshots
secrets are not included in exported templates
secrets are not committed to source control
environment secret files are excluded from Git
Git history is checked after accidental exposure
credentials are stored in approved secure storage
unused keys are revoked
exposed keys are rotated immediately
credential owner is known
credential scope is limited
MWMS Rule
Credentials must be treated as restricted data.
A deleted exposed key should still be considered compromised until revoked.
Least Privilege And Access Control
Confirm:
the system has only the access required
read access is used instead of write where possible
write access is used instead of admin where possible
delete access is blocked unless necessary
client access is isolated
team access is role-based
shared admin accounts are avoided
temporary access expires
connector endpoints are restricted
tool access matches the AI Employee role
MWMS Rule
If the system does not need the permission, it must not have the permission.
Input Validation And Prompt Injection Protection
Treat as untrusted:
form input
webhook input
emails
messages
uploaded files
scraped content
retrieved documents
CRM payloads
mapped variables
external instructions
Confirm:
required fields are checked
data types are checked
allowed values are enforced
length limits exist where needed
URLs are validated
file types are validated
client identifiers are validated
external text cannot override system instructions
high-risk actions cannot be triggered by untrusted text alone
invalid inputs are rejected or routed for review
MWMS Rule
External input must not receive operational authority.
Tool And Action Boundaries
Identify every action the system can perform.
Actions may include:
read data
write data
send communication
create files
publish content
update CRM records
trigger workflows
call APIs
change settings
delete records
spend money
alter infrastructure
For every action, define:
permission level
allowed tool
allowed endpoint
allowed client scope
approval requirement
logging requirement
fallback
MWMS Rule
Tool access is authority.
Authority must be explicit.
External Action Approval
External actions include:
sending email
sending messages
calling customers
publishing content
sending reports
sending proposals
updating client-facing dashboards
triggering customer workflows
changing live client records
sending outreach
External actions must define:
recipient
purpose
approved content type
review level
suppression or opt-out where relevant
escalation path
logging
repeat-action protection
MWMS Rule
If an action can affect money, customers, clients, reputation, compliance or public output, assume approval is required until proven otherwise.
Logging And Observability
Important activity should record:
system name
workflow
tool used
action taken
AI model used where relevant
prompt version where relevant
input summary
output summary
client identifier where relevant
timestamp
approval status
success or failure
error message
retry count
cost where relevant
correlation ID where relevant
next action
MWMS Rule
No important automation should operate invisibly.
Failure Handling And Escalation
Define what happens when:
an API fails
credentials fail
input is missing
AI output is invalid
a tool returns no result
a database write fails
a message cannot be sent
a workflow times out
a second workflow does not respond
a duplicate request occurs
an external service is unavailable
a schema changes
a cost limit is reached
The workflow must:
stop
retry within limits
use an approved fallback
create an alert
escalate to a human
record the failure
MWMS Rule
A system must never pretend success after a failed action.
Duplicate Action Protection
Review whether repeated execution could:
send duplicate emails
send duplicate messages
charge twice
create duplicate records
publish twice
generate duplicate reports
repeat outreach
call expensive APIs repeatedly
change a record more than once
Use where appropriate:
idempotency key
correlation ID
status check
deduplication table
execution lock
timestamp window
approval state
MWMS Rule
A repeated trigger must not create repeated harm.
Cost And Usage Control
Confirm:
API usage is understood
model cost is understood
operation cost is understood
voice or messaging cost is understood
run frequency is controlled
retry limits exist
loops are prevented
batch sizes are limited
cost alerts exist where appropriate
high-cost actions require stronger approval
usage can be reviewed
MWMS Rule
An automation that can create uncontrolled cost is not production-ready.
Backup Recovery And Shutdown
Confirm:
workflow definitions are backed up
important data is backed up
prompt versions are preserved
connector versions are preserved where relevant
recovery steps exist
restore testing occurs
shutdown path is known
credentials can be revoked
webhooks can be disabled
connectors can be withdrawn
client access can be removed
previous safe version can be restored
MWMS Rule
A production system must be recoverable and stoppable.
MWMS AI Automation Preflight Checklist
A. Purpose
Business problem is clear.
Desired outcome is clear.
System owner is named.
Brain owner is named.
Maintenance owner is named.
The workflow is worth automating.
B. Data
Data inputs are mapped.
Data outputs are mapped.
Sensitive data is identified.
Client data boundaries are defined.
Unnecessary data is removed.
Storage location is known.
Retention is defined.
Deletion process is known.
C. Credentials And Access
Credentials are stored securely.
Secrets are excluded from prompts and files.
Unused keys are removed.
Least privilege is applied.
MFA is enabled where possible.
Team access is controlled.
Client access is isolated.
Endpoint access is limited.
D. Input And AI Safety
External input is treated as untrusted.
Prompt injection risk is reviewed.
Required fields are validated.
AI output is validated.
Sensitive data is minimised.
The AI cannot access tools it does not need.
E. Reliability
Trigger is clear.
Workflow steps are mapped.
Failure states are known.
Retry limits are defined.
Errors are logged.
Fallback exists.
Duplicate actions are controlled.
F. External Action
External actions are identified.
Human approval is included where needed.
Recipients are verified.
Customer communication is scoped.
Publishing is controlled.
Suppression and opt-out are active where relevant.
G. Monitoring And Recovery
Logs are active.
Cost exposure is reviewed.
Usage is monitored.
Backups exist.
Recovery steps exist.
Incident escalation exists.
Shutdown and rollback paths are known.
H. Launch Decision
Choose one:
Safe to test
Safe for internal use
Safe for limited client beta
Safe for production
Safe only with human review
Not safe yet
Part 2
Launch Decision Evidence Standard
A launch decision must be supported by evidence.
The evidence should show:
the system tested
the environment tested
the test date
the person who tested it
the risk level assigned
the permissions granted
the data used
the actions performed
the failures observed
the recovery path tested
the approvals obtained
the unresolved risks
the launch limitation
the review date
MWMS Rule
A launch label without supporting evidence is not a valid launch decision.
Safe To Test
Safe to test means:
the system may be tested in a controlled environment
test data is used where possible
live external action is blocked unless explicitly required
permissions are limited
failure is contained
test activity is logged
Safe For Internal Use
Safe for internal use means:
the system may be used by approved MWMS users
client or public output still requires review where relevant
sensitive data controls are active
logging and recovery are operational
the system is not yet approved for unrestricted client production
Safe For Limited Client Beta
Safe for limited client beta means:
the client is identified
the beta scope is narrow
the volume is limited
the risk is disclosed
the client responsibility is clear
human review remains active where required
monitoring is increased
rollback is available
Safe For Production
Safe for production means:
the full checklist has passed
the relevant specialist frameworks have passed
the operating environment is approved
the production permissions are correct
monitoring is active
incident response is ready
support ownership is active
the system can be stopped
Safe Only With Human Review
Safe only with human review means:
the automation may produce a draft, recommendation, proposed action or candidate output
a qualified human must review the output before the relevant external, high-risk or irreversible action
the workflow cannot silently bypass the review
Not Safe Yet
Not safe yet means:
one or more material controls are missing
the system must not proceed beyond controlled diagnostic or repair work
the blocking issue must be recorded
the owner must be identified
the next review must be scheduled
Production Readiness Decision Record
System Name:
System Owner:
Brain Owner:
Client:
Environment:
Risk Level:
Decision:
Permitted Use:
Prohibited Use:
Human Review Requirement:
Approved Tools:
Approved Permissions:
Approved Data:
External Actions Allowed:
Volume Limit:
Cost Limit:
Monitoring Requirement:
Rollback Method:
Shutdown Authority:
Open Risks:
Evidence Location:
Reviewer:
Approval Date:
Next Review Date:
Client Data And Tenant Isolation
Every client system must maintain clear separation between:
client records
client credentials
client files
client prompts
client knowledge
client contact lists
client communications
client reports
client dashboards
client workflow state
client logs
client outputs
Confirm:
client identifiers are present and validated
queries are scoped to the correct client
storage paths are client-specific
vector or retrieval filters are client-specific
credentials do not cross client boundaries
shared templates do not contain client secrets
test data is not mixed with production data
one client cannot access another client’s records
support access is recorded
client export and deletion can be performed
MWMS Rule
Client isolation must be enforced by system design.
A prompt instruction alone is not sufficient isolation.
Environment Separation
Where risk justifies it, separate:
development
testing
staging
production
Confirm:
test credentials are not production credentials
test webhooks are not production webhooks
test records are identifiable
production data is not copied unnecessarily
production sending is disabled during testing
environment variables are environment-specific
deployment changes are recorded
rollback is possible
MWMS Rule
A test workflow must not be able to reach production accidentally.
Webhook And Endpoint Security
Confirm:
webhook URLs are treated as secrets where appropriate
authentication is enabled where supported
signatures are verified where supported
source IP or origin restrictions are applied where practical
payload size limits exist
request methods are restricted
replay risk is controlled
timestamps or nonces are checked where appropriate
rate limits exist
invalid payloads are rejected
error responses do not expose secrets
endpoint activity is logged
unused endpoints are disabled
MWMS Rule
A public endpoint must not become an unreviewed path into a powerful workflow.
API And Connector Risk
For every API or connector, identify:
provider
purpose
data sent
data received
permission scope
rate limit
cost exposure
data retention position
failure behaviour
availability dependency
version dependency
client dependency
revocation path
replacement path
Confirm:
the official or approved connector is used where appropriate
deprecated endpoints are not relied on
API versions are known
schema changes are monitored
connector ownership is known
connector errors do not become false success
credentials can be revoked independently
provider access can be removed
MWMS Rule
A connector is a dependency and a permission surface.
It must be reviewed as both.
Third-Party Provider And Supply Chain Risk
Review:
provider reputation
provider security posture
provider data handling
provider terms
provider geographic storage where relevant
subprocessors where relevant
service availability
vendor lock-in
pricing volatility
API stability
model or tool deprecation
export capability
deletion capability
incident notification
support access
Confirm:
the business can continue or recover if the provider fails
critical records are not trapped
the provider is not given unnecessary data
the provider does not receive permanent broad access without need
MWMS Rule
External convenience must not create invisible operational dependence.
Browser Automation And Scraping Risk
Where browser automation, scraping, remote browser tools or MCP-style tools are used, confirm:
the target is approved
the account used is approved
the session is isolated
cookies and tokens are protected
downloaded files are treated as untrusted
page instructions are treated as data
destructive actions are blocked
navigation scope is limited
login state is controlled
rate limits are respected
site rules and legal constraints are reviewed where required
captured data is minimised
screenshots do not expose secrets
browser history and temporary files are handled appropriately
MWMS Rule
A webpage is not a trusted operator.
Text displayed in a browser must not receive tool authority.
File And Document Security
For uploaded, generated, downloaded or processed files, confirm:
allowed file types are defined
file size limits exist
malware risk is reviewed
macros or executable content are blocked where appropriate
embedded links are treated as untrusted
document instructions are treated as data
metadata exposure is reviewed
client identifiers are preserved
storage location is approved
retention is defined
deletion is possible
public links expire or are avoided
generated files are validated before delivery
MWMS Rule
A readable file is not necessarily a safe file.
Database And Record Security
Confirm:
table access follows least privilege
row-level isolation exists where required
write operations are scoped
delete operations are restricted
schema changes are controlled
sensitive fields are protected
logs do not expose restricted fields
backups are available
restore procedures are tested
record history is preserved where required
duplicate writes are controlled
bulk actions are restricted
manual correction is possible
MWMS Rule
Database write access must be narrower than database read access.
Retrieval And RAG Security
For retrieval systems, confirm:
approved knowledge sources are defined
client or workspace filters are enforced
retrieved content is treated as evidence, not authority
prompt injection from retrieved text is controlled
source identity is retained
source date is available where relevant
stale content is handled
restricted content is excluded
conflicting sources are surfaced
insufficient evidence creates a safe result
retrieval logs do not expose unnecessary confidential text
MWMS Rule
Retrieved content may inform an answer.
It must not rewrite the system’s authority.
AI Model And Provider Security
For each AI model or provider, confirm:
approved use case
data classification permitted
retention setting where available
training-use setting where available
regional or client restrictions
model identifier
provider identifier
fallback model
cost profile
context limit
tool capability
structured-output capability
known failure pattern
model change risk
Confirm:
sensitive data is not sent to an unapproved model
fallback does not weaken privacy or permission controls
model upgrades are tested
provider changes are logged
output is validated independently of provider confidence
MWMS Rule
Changing the model may change risk, behaviour, cost and output quality.
A model change is a controlled system change.
Prompt And Instruction Security
Confirm:
system instructions are separated from external content
trusted context is identified
untrusted input is labelled
prompt variables are bounded
unknown values are not invented
high-risk instructions require approved authority
external content cannot request secrets
external content cannot change recipients
external content cannot change tool permissions
external content cannot remove approval
prompt versions are recorded
prompt changes are tested
MWMS Rule
Prompt injection is not solved by asking the model to ignore prompt injection.
Workflow and permission controls must also prevent harmful action.
Visual And Synthetic Media Security
This control area applies to:
generated images
generated video
avatar video
voice synthesis
voice cloning
personalised visual sales assets
social media creative
ad creative
thumbnails
presentation visuals
synthetic spokesperson content
other AI-generated media
Confirm:
asset purpose is defined
recipient or audience is defined
brand or company is correct
logo permission is explicit
likeness permission is explicit
voice permission is explicit where applicable
required disclosure is defined
reference asset source or rights are recorded
external or scraped content is treated as untrusted
fixed prompt elements are separated from dynamic variables
only approved variables can populate automatically
prohibited elements are defined
negative instructions are defined
required text is validated
logos are validated
claims are validated
multiple candidates are tracked where generated
selected candidate is identified
human review is included where required
approval status is explicit
delivery or publication authority is separate from generation authority
prompt version is recorded
template version is recorded
model and provider are recorded
final asset is traceable to its inputs
MWMS Rule
Successful generation does not mean safe, accurate, permitted or approved output.
Visual Prompt Variable Control
Dynamic visual variables may include:
recipient name
company name
location
industry
campaign
offer
approved message
approved call to action
approved logo reference
approved scene element
Every dynamic variable must define:
source
allowed value
validation
missing-value behaviour
trust level
approval requirement where relevant
Website and scraped content must not be allowed to:
alter fixed prompt instructions
add a new claim
grant logo permission
grant likeness permission
grant voice permission
remove a disclosure
change the recipient
change the sending destination
authorise publication
MWMS Rule
Dynamic personalisation must remain inside approved variable boundaries.
Generated Text And Logo Validation
Text inside generated media must be checked for:
spelling
recipient name
company name
product name
offer
price
date
location
URL
phone number
call to action
disclosure
claim wording
legibility
completeness
Logos must be checked for:
correct company
approved source
current version
shape
spelling
proportions
distortion
unauthorised alteration
confusion with another brand
MWMS Rule
A logo that looks close is not an accurate logo.
Generated text that looks readable is not validated text.
Reference Asset And Originality Risk
Confirm:
reference asset source is known
ownership or rights status is known
permitted use is known
confidential assets are protected
the output is not a deceptive copy
the output does not imply false endorsement
the output does not reproduce restricted material without authority
the output meets the relevant originality criteria
MWMS Rule
A reference asset may guide composition or pattern.
It does not automatically grant copying rights.
Likeness Voice And Identity Protection
The system must not infer permission to use:
a person’s face
a person’s body
a person’s name in a synthetic endorsement
a person’s cloned voice
a person’s simulated voice
a synthetic spokesperson presented as a real customer
Confirm:
the person is identified
permission status is recorded
source of permission is recorded
permitted use is recorded
campaign scope is recorded
expiry or limitation is recorded where relevant
disclosure is included where required
revocation path exists
MWMS Rule
Prompt automation cannot grant likeness or voice permission.
Claims Disclosure And Representation Risk
Confirm:
claims are approved
evidence exists
visual implication does not exceed the approved claim
testimonials are genuine and authorised
simulations are identified where required
affiliate or sponsorship disclosure is included where required
AI or synthetic-media disclosure is included where required
the asset does not imply false endorsement
the asset does not present generated results as real results
MWMS Rule
A technically accurate sentence may still create a misleading visual impression.
Candidate Selection And Approval Security
Where multiple outputs are generated, confirm:
candidate count is known
candidate identifiers are recorded
rejected candidates cannot be sent accidentally
selection criteria are defined
the selected candidate is recorded
the selected candidate passes validation
the selected candidate receives required human approval
post-selection edits trigger revalidation where material
only the approved candidate can reach delivery or publication
MWMS Rule
Generated, shortlisted and selected are not the same as approved.
Outbound And Recipient Security
For outbound email, messaging, proposals, reports, personalised assets or outreach, confirm:
recipient identity is validated
recipient contact details are validated
client ownership is clear
suppression lists are checked
opt-outs are respected
do-not-contact status is respected
frequency limits exist
duplicate sends are prevented
personalisation fields are validated
attachments or links are correct
claims are approved
sender identity is correct
reply handling is defined
bounce handling is defined
complaint handling is defined
sending domain or account is approved
MWMS Rule
Automation must not turn weak data into confident outreach.
Public Publishing Security
Before publishing, confirm:
channel is correct
account is correct
client is correct
content is approved
asset is approved
claim review is complete
disclosure is present
links are correct
scheduled time is correct
duplicate publication is blocked
rollback or removal path exists
publication result is confirmed
MWMS Rule
Drafting authority does not create publishing authority.
Voice Agent And Live Conversation Risk
For voice agents or live conversational systems, confirm:
identity disclosure is defined
recording disclosure is defined where required
consent handling is defined
call purpose is limited
knowledge scope is controlled
restricted topics are defined
handoff to human is available
emergency or high-risk escalation is defined
the agent cannot make unapproved commitments
the agent cannot change pricing
the agent cannot accept legal terms
the agent cannot collect unnecessary sensitive data
call logs and transcripts are protected
retention is defined
voice permission is recorded
MWMS Rule
A natural-sounding voice must not be mistaken for unrestricted authority.
Financial Legal Health And Regulated Risk
Systems involving financial, legal, health, employment, insurance, credit, identity, children, regulated claims or other sensitive decisions require specialist review.
Confirm:
the system does not present itself as a qualified professional where it is not
required disclaimers are present
human review is mandatory
source evidence is visible
uncertainty is explicit
high-impact decisions are not made solely by AI
sensitive data handling is approved
jurisdiction is considered
record retention is appropriate
appeal or correction is possible where relevant
MWMS Rule
Automation convenience does not reduce professional, legal or compliance responsibility.
Human Approval Gate Design
A human approval gate must define:
what is being approved
who may approve
what evidence the reviewer sees
what risk level applies
what actions follow approval
what happens on rejection
whether edits require reapproval
how approval is recorded
how long approval remains valid
Confirm:
the approver cannot approve an unknown output blindly
the workflow cannot bypass approval
approval status cannot be invented by the model
approval is tied to a specific output version
approval expires where circumstances change
MWMS Rule
Approval must be specific, informed and traceable.
Security Logging Minimum Record
System Name:
Workflow Name:
Environment:
Client ID:
Task ID:
Correlation ID:
Trigger:
Input Record IDs:
Data Classification:
Prompt Version:
Template Version:
Model:
Provider:
Tools Used:
Permissions Used:
Action Requested:
Approval Status:
Action Result:
Output Record ID:
Selected Asset ID Where Applicable:
Validation Result:
Error:
Retry Count:
Fallback Used:
Cost:
Timestamp:
Reviewer:
Final Status:
Incident Detection Signals
Potential incident signals include:
unexpected data access
wrong-client output
unexpected recipient
duplicate external action
credential failure
credential exposure
unusual usage spike
cost spike
large output volume
repeated retries
unauthorised tool call
unapproved publication
missing approval
invalid output sent externally
prompt injection success
untrusted input changing workflow behaviour
data appearing in the wrong workspace
unknown connector
unknown webhook activity
unexpected deletion
unexpected database writes
generated asset using unauthorised likeness, voice or logo
missing required disclosure
deceptively copied reference asset
MWMS Rule
An unusual result must be treated as a signal until explained.
Incident Severity Levels
Severity 1: Minor
Contained issue with no external harm and no sensitive exposure.
Severity 2: Material
Internal operational impact, limited client impact or recoverable incorrect action.
Severity 3: Major
Sensitive data exposure, wrong-client action, public error, repeated external harm or significant operational disruption.
Severity 4: Critical
Large-scale exposure, financial loss, destructive action, legal or regulatory risk, widespread client impact or active compromise.
MWMS Rule
Incident severity should reflect impact, scope, reversibility and ongoing risk.
Incident Response Sequence
- Detect
Identify the event and preserve evidence.
- Contain
Stop the workflow, disable the trigger, revoke access or isolate the affected component.
- Assess
Determine scope, data, client, action, cost and continuing risk.
- Notify
Notify the owner, HeadOffice and relevant client or specialist reviewer where required.
- Recover
Restore the last safe state and correct affected records or actions where possible.
- Review
Identify root cause, control failure and required framework or workflow changes.
- Close
Record the outcome, remaining risk and approval to return to service.
MWMS Rule
Containment takes priority over preserving automation uptime.
Incident Record
Incident ID:
Date And Time:
System:
Client:
Environment:
Detected By:
Severity:
Description:
Data Involved:
Tools Involved:
Credentials Involved:
External Actions:
Affected Records:
Affected Recipients:
Containment Action:
Credential Revocation:
Workflow Disabled:
Rollback Performed:
Notifications:
Recovery Action:
Root Cause:
Control Failure:
Corrective Action:
Owner:
Return To Service Approval:
Close Date:
Post Incident Review
After an incident, review:
why the control failed
why detection did or did not work
whether permissions were too broad
whether the workflow should have stopped earlier
whether approval was bypassed
whether logging was sufficient
whether recovery was effective
whether the incident can repeat
whether other systems share the same weakness
whether client communication is required
whether a Canon or framework update is required
whether retraining is required
whether the provider or connector remains approved
MWMS Rule
An incident is not closed merely because the workflow is running again.
Security Change Management
Security review is required when changing:
tools
connectors
credentials
permissions
model
provider
prompt
template
schema
database
webhook
recipient logic
external action
volume
schedule
client
data source
storage location
retention
fallback
approval gate
visual prompt variables
logo use
likeness use
voice use
disclosure logic
publication path
Confirm:
change is documented
risk is reassessed
tests are rerun
permissions are reviewed
rollback exists
approval is obtained
production monitoring is increased where appropriate
MWMS Rule
A working system may become unsafe after a seemingly small change.
Periodic Security Review
Review frequency should match risk.
Level 1
At material change or scheduled low-frequency review.
Level 2
At material change and periodic operational review.
Level 3
At material change, regular scheduled review and after significant failure.
Level 4
At material change, frequent scheduled review, after every incident and under executive oversight.
Periodic review should examine:
permissions
credentials
logs
cost
failures
provider changes
connector changes
model changes
prompt changes
data scope
client access
human approvals
incident history
recovery readiness
unused access
retention
deletion
visual and synthetic-media permissions where relevant
MWMS Rule
Security approval expires when the system materially changes.
Client Handover Security
Before client handover, confirm:
the client understands the system purpose
the client understands system limitations
the client understands human-review requirements
the client understands data responsibilities
the client understands account responsibilities
the client knows who owns credentials
the client knows how to revoke access
the client knows how to stop the system
the client knows how to report an incident
the client knows what support includes
the client knows what support excludes
the client has the correct documentation
the client has approved the production scope
the client has accepted remaining risks
MWMS Rule
A client handover is incomplete until operational and security responsibility is clear.
Client Handover Security Record
Client:
System:
Production Scope:
Risk Level:
Client Owner:
MWMS Owner:
Credentials Owner:
Data Owner:
Support Owner:
Human Review Owner:
Incident Contact:
Shutdown Method:
Revocation Method:
Backup Method:
Recovery Method:
Known Limitations:
Known Risks:
Client Approval:
Handover Date:
Review Date:
System Decommissioning And Access Revocation
When a system is retired, paused or transferred, confirm:
triggers are disabled
webhooks are disabled
schedules are disabled
credentials are revoked or transferred
API keys are removed
service accounts are removed
team access is removed
client access is removed where appropriate
data retention obligations are followed
unnecessary data is deleted
exports are delivered where required
logs are preserved where required
public links are disabled
domains or sending accounts are disconnected
documentation is updated
the system is marked inactive
MWMS Rule
A retired automation must not remain an active attack or cost surface.
Security Exception Process
An exception may be considered only when:
the business reason is documented
the risk is understood
the affected control is identified
the temporary duration is defined
compensating controls exist
the owner is named
HeadOffice approval is obtained
client approval is obtained where relevant
the exception is logged
the expiry date is recorded
MWMS Rule
Convenience is not a security exception.
Security Exception Record
System:
Control Exception:
Reason:
Risk:
Compensating Control:
Owner:
Client Impact:
Approval:
Start Date:
Expiry Date:
Review Date:
Closure:
Final Production Security Checklist
Before production, confirm:
Purpose And Ownership
business purpose is clear
system owner is named
Brain owner is named
maintenance owner is named
client owner is named where relevant
shutdown authority is named
Data
data classification is complete
data minimisation is applied
client isolation is enforced
storage is approved
retention is defined
deletion is possible
Credentials
secrets are protected
credentials are scoped
unused credentials are removed
revocation is possible
MFA is enabled where possible
Access
least privilege is applied
read and write permissions are separated where possible
delete authority is restricted
team access is role-based
client access is isolated
Inputs
required fields are validated
external content is treated as untrusted
prompt injection is controlled
URLs and files are validated
invalid input stops or routes for review
Prompts And Models
prompt version is recorded
model and provider are approved
fallback is approved
sensitive data use is approved
output validation is active
model changes require retesting
Tools And Actions
tools are approved
actions are mapped
endpoints are approved
external actions have approval rules
tool success requires confirmation
duplicate actions are controlled
Visual And Synthetic Media Where Applicable
fixed and dynamic prompt elements are separated
only approved variables populate automatically
generated text is validated
logos are accurate and permitted
reference assets are governed
likeness permission is recorded
voice permission is recorded
disclosure is defined
candidate selection is recorded
selected output is approved
delivery authority is separate from generation authority
Reliability
failure states are known
retry limits exist
fallback exists
timeouts exist
loops are controlled
cost limits exist
shutdown path exists
Observability
logs are active
task and correlation IDs are used where relevant
approval status is recorded
errors are recorded
cost is visible
selected output is traceable where relevant
Incident And Recovery
incident severity is defined
incident contacts are known
containment is possible
backups exist
rollback is possible
restore has been tested where required
return-to-service approval is defined
Client Handover
client responsibilities are clear
support scope is clear
security documentation is provided
revocation and shutdown are explained
remaining risks are accepted
Launch
risk level is confirmed
launch evidence is recorded
production scope is explicit
prohibited use is explicit
review date is scheduled
Final Security Decision
Choose one:
Approved For Controlled Test
Approved For Internal Use
Approved For Limited Client Beta
Approved For Production
Approved Only With Human Review
Approved With Temporary Exception
Blocked Pending Remediation
Rejected
Final Security Decision Record
System:
Version:
Environment:
Client:
Risk Level:
Decision:
Scope:
Conditions:
Human Review:
Temporary Exception:
Open Risks:
Remediation Required:
Evidence:
Security Reviewer:
System Owner:
HeadOffice Approval:
Client Approval Where Required:
Decision Date:
Expiry Or Review Date:
Application To HeadOffice
HeadOffice owns:
system-wide security posture
risk acceptance
cross-Brain security governance
critical exception approval
production approval for material systems
incident escalation
return-to-service authority for major incidents
Application To Risk Brain
Risk Brain owns:
risk classification
risk escalation
dependency risk
concentration risk
residual risk visibility
incident severity support
Application To Compliance Brain
Compliance Brain owns:
policy review
regulated workflow review
disclosure requirements
consent requirements
retention requirements
jurisdiction-sensitive controls
Application To Automation Brain
Automation Brain owns:
workflow security design
trigger security
connector control
retry and fallback safety
duplicate-action protection
shutdown and rollback
runtime logging
Application To AIBS Brain
AIBS Brain owns:
client AIOS security design
client responsibility mapping
client handover security
client access boundaries
client-facing production risk
Application To Data Brain
Data Brain owns:
data classification
schema integrity
record access
client isolation
storage
retention
deletion
backup and restore integrity
Application To Operations Brain
Operations Brain owns:
operational ownership
support coverage
incident procedure
maintenance schedule
change coordination
service continuity
Application To SIT Brain
SIT Brain supports:
independent security testing
failure testing
permission testing
prompt-injection testing
client-isolation testing
recovery testing
high-risk launch review
Application To Content Brain And Ads Brain
Content Brain and Ads Brain must apply this checklist to:
automated publishing
generated claims
brand assets
visual generation
synthetic media
logo use
reference assets
personalised creative
candidate approval
public output
Application To Sales And Customer Brains
Sales Brain and Customer Brain must apply this checklist to:
outreach
lead enrichment
proposals
customer messages
voice agents
personalised visual assets
CRM updates
follow-up automation
suppression and opt-out controls
Future AI Employee Ideas
AI Automation Security Reviewer
Primary Brain: HeadOffice Brain / Risk Brain
Purpose:
Reviews automation security, permissions, data, external actions, recovery and launch evidence.
Credential Exposure Auditor
Primary Brain: Risk Brain / Automation Brain
Purpose:
Detects exposed keys, hardcoded secrets, over-broad credentials and incomplete revocation.
Client Isolation Auditor
Primary Brain: Data Brain / AIBS Brain
Purpose:
Tests client boundaries across storage, retrieval, prompts, credentials, records and outputs.
Prompt Injection And Untrusted Input Tester
Primary Brain: SIT Brain / Prompting Framework
Purpose:
Tests whether external content can alter authority, tools, recipients, approval or workflow behaviour.
External Action Safety Reviewer
Primary Brain: Automation Brain / Compliance Brain
Purpose:
Reviews sending, publishing, CRM changes, customer actions and duplicate-action protection.
Visual And Synthetic Media Risk Reviewer
Primary Brain: Risk Brain / Content Brain / Ads Brain
Purpose:
Reviews logo, likeness, voice, reference assets, disclosures, generated text, candidate selection and approval.
Incident Response Coordinator
Primary Brain: Operations Brain / HeadOffice Brain
Purpose:
Coordinates containment, evidence, notification, recovery, review and return to service.
AI Provider And Connector Risk Analyst
Primary Brain: Risk Brain / Automation Brain
Purpose:
Tracks provider dependency, API change, data handling, cost risk, access and replacement options.
Security Drift Signals
“The workflow works, so it is safe.”
“The model will ignore malicious instructions.”
“The webhook URL is too obscure to be found.”
“The connector only has admin access because it was easier.”
“The client data is probably separated.”
“The fallback can use any available model.”
“The file opened successfully, so it is safe.”
“The website text can be trusted.”
“The AI chose the recipient.”
“The logo looks close enough.”
“The person is public, so likeness permission is not needed.”
“The voice is synthetic, so consent is not needed.”
“The image generated successfully, so it is approved.”
“The first candidate is fine.”
“The tool probably completed.”
“The client knows how it works.”
“We can document recovery later.”
“We deleted the key from the file, so the exposure is fixed.”
“We do not need logs because the workflow is simple.”
“We can leave the old webhook active.”
MWMS Rule
When these signals appear, stop and return to the relevant security control.
Drift Protection
This checklist protects MWMS from:
unowned automation
excessive permissions
cross-client data leakage
credential exposure
hardcoded secrets
prompt injection
untrusted content gaining authority
unsafe browser automation
unsafe scraping
unvalidated files
uncontrolled webhooks
wrong-recipient sending
duplicate external action
false tool-success reporting
uncontrolled cost
silent failure
unrecoverable workflows
provider dependency
unsafe model fallback
unapproved publication
unapproved outreach
misleading generated claims
unauthorised logo use
unauthorised likeness use
unauthorised voice use
missing disclosure
deceptive reference-asset copying
untracked visual candidates
unapproved synthetic media
incomplete client handover
inactive systems retaining access
exceptions without expiry
incidents closed without root-cause correction
Final Standard
The MWMS final security standard is:
Every important AI automation, AI Employee, client AIOS, workflow, connector, public endpoint, model integration, data workflow, communication system, content system, visual-generation system and external action must pass a risk-appropriate security review before production use.
A production-ready system must be:
purpose-defined
owned
data-minimised
client-isolated
credential-secure
least-privileged
input-validated
prompt-injection resistant
tool-bounded
approval-controlled
output-validated
duplicate-protected
observable
cost-controlled
recoverable
stoppable
incident-ready
maintainable
client-safe
compliance-aware
traceable
A technically successful run is not proof of safety.
A generated output is not proof of approval.
A prompt cannot grant system authority.
A model cannot grant permission.
External text cannot become operational authority.
A fallback cannot bypass governance.
A client handover cannot transfer undefined responsibility.
That is the MWMS AI Automation Security And Risk Standard.
MWMS System Change Log
Version
v1.4
Date
2026-06-21
Author: HeadOffice
Change
Completed the previously unfinished MWMS AI Automation Security And Risk Checklist v1.3 page and updated it to v1.4.
Preserved the complete existing v1.3 framework.
Removed the incomplete CONTINUE WITH PART 2 marker and added the missing second half covering:
launch-decision evidence
production readiness records
client and tenant isolation
environment separation
webhook and endpoint security
API and connector risk
third-party provider risk
browser automation and scraping risk
file and document security
database security
retrieval and RAG security
AI model and provider security
prompt and instruction security
visual and synthetic-media security
visual prompt variable control
generated-text and logo validation
reference-asset and originality risk
likeness, voice and identity protection
claims and disclosure risk
candidate selection and approval security
outbound recipient security
public publishing security
voice-agent risk
regulated and high-impact workflow risk
human approval gate design
security logging
incident detection
incident severity
incident response
post-incident review
security change management
periodic review
client handover security
system decommissioning
security exceptions
final production security review
Brain ownership
future AI Employee ideas
drift protection
Added focused security intelligence from the latest AI Automations by Jack block establishing that:
fixed prompt structure must be separated from dynamic variables
only approved variables may populate automatically
websites and scraped content must be treated as untrusted
generated text must be validated
logos must be checked for accuracy and permission
reference assets must not be copied deceptively
successful generation does not mean approved output
multiple candidates must be tracked and the selected candidate must be approved
prompt, template, model, provider, inputs and selected output must be traceable
visual prompt changes must be versioned
visual and synthetic-media assets must pass relevant asset governance before delivery
prompt automation must not authorise likeness, voice, logo, disclosure, claims, external sending or publication
Change Impact Declaration
This is a completion and focused additive security-governance update.
It preserves all existing v1.3 controls.
It does not replace specialist permission, validation, visual-asset, outreach, communication, deployment, incident or compliance frameworks.
It completes the core security gate so it can function as a full production preflight, launch, incident, handover and decommissioning checklist.
Pages Created
None.
Pages Updated
MWMS AI Automation Security And Risk Checklist updated from v1.3 to v1.4.
Pages Deprecated
None.
Standalone Pages Not Created
MWMS Visual Automation Security Checklist
MWMS Synthetic Media Security Framework
MWMS Webhook Security Checklist
MWMS AI Provider Risk Checklist
MWMS Client AIOS Security Handover Checklist
MWMS Prompt Injection Security Checklist
These were not created because the controls belong inside this core security gate and the existing specialist frameworks.
Registries Requiring Update
HeadOffice Page Registry
MCR Page Registry
MCR Copy Map where the framework version is recorded
MWMS Course Absorption Decision Registry
Canon Version Update Required
No immediate HeadOffice Canon, Risk Brain Canon, Compliance Brain Canon, Automation Brain Canon or AIBS Brain Canon version update is required unless it directly records this framework version or contains conflicting security rules.
The completed v1.4 controls should be included during the next scheduled Canon alignment review for the affected Brains.
Change Log Entry Required
Yes.
The v1.4 completion and update must be recorded in:
MWMS System Change Log
HeadOffice Page Registry change history where applicable
MCR Page Registry change history where applicable
MWMS Course Absorption Decision Registry
Strategic Absorption Result
The incomplete AI Automation Security And Risk Checklist has been converted into a complete production security gate without creating duplicate tool-specific or visual-security pages.
MWMS now has one consolidated checklist governing the full automation security lifecycle from purpose, data, credentials, permissions, inputs and tools through visual and synthetic-media risk, external action, deployment, incident response, client handover, periodic review and decommissioning.
The resulting framework now prevents MWMS from treating technical success as safety and establishes that every production automation must be permissioned, isolated, validated, observable, recoverable, stoppable, traceable and explicitly approved for its intended risk level.
END OF FULL FILE OUTPUT