MWMS MCR

MWMS AI Automation Security And Risk Checklist

MWMS AI Automation Security And Risk Checklist

System: MWMS
Document Type: Checklist / Governance Framework
Authority Level: MCR Source Of Truth
Status: Active
Version: v1.1
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
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-01
Source / Origin: MWMS AI Automation Security And Risk Checklist v1.0 + AI Automations by Jack — AI Agents / n8n Client Automation Block
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 n8n Operating And Deployment Standard, MWMS Client Communication Automation Framework, MWMS Lead Intake Qualification And Follow-Up Automation Framework, MWMS Client Intelligence Report Automation Framework, MWMS Outbound Lead Enrichment And Cold Outreach Governance Framework, MWMS Market Driven Social Content Production Framework, MWMS Supabase RAG And Vector Memory Framework, MWMS AI Dashboard Capability Framework, MWMS AI Guardrail And Preflight Check Standard, MWMS AI Permission Gatekeeper Framework, MWMS AI Agent Failure Handling And Escalation Protocol, MWMS AI Output Validation Standard, MWMS Source Visibility And Evidence Display Standard, Risk Brain Dependency Exposure Framework, Risk Brain Risk Escalation Framework, Operations Brain Execution Reliability Framework, SIT Brain Canon
Source Evidence: AI Automations by Jack identifies security, API key protection, client data handling, prompt injection, zero trust, data regulations, least privilege, backups, vulnerability scanning, and legal responsibility as major risks in AI automation work. The later AI Agents / n8n Client Automation block adds stronger operational security needs around n8n, Make/n8n bridges, WhatsApp/Unipile, VAPI voice agents, GoHighLevel, Apollo, Appify, Anymailfinder, Fireflies, ElevenLabs, PDF.co, Placid, Gmail, Google Drive, Airtable, Google Sheets, Supabase, webhooks, self-hosted n8n, AI app-builder front ends, client reports, outbound outreach, lead systems, content workflows, and client-facing AIOS delivery.

Purpose

The MWMS AI Automation Security And Risk Checklist defines the minimum security, privacy, governance, compliance, operational, and client-safety checks required before MWMS builds, deploys, sells, connects, scales, or hands over AI automations and AI Operating Systems.

This page exists because AI automation systems can create real business value, but they can also create real business risk.

An automation may touch:

  • API keys
  • private emails
  • CRM records
  • client data
  • payment tools
  • business documents
  • lead records
  • prospect records
  • calendar systems
  • internal dashboards
  • customer conversations
  • WhatsApp messages
  • voice calls
  • transcripts
  • scraped data
  • enriched personal data
  • client reports
  • generated PDFs
  • proposals
  • AI prompts
  • third-party tools
  • external webhooks
  • databases
  • file storage
  • reporting systems
  • public content
  • client-facing dashboards
  • AIOS workflows

If those systems are poorly designed, they can expose MWMS or a client to:

  • data leaks
  • cost spikes
  • legal risk
  • spam complaints
  • broken workflows
  • reputational damage
  • compliance failures
  • operational shutdown
  • incorrect client reports
  • wrong-recipient emails
  • wrong-client data leakage
  • hallucinated proposals
  • unsafe customer responses
  • platform account risk
  • exposed webhooks
  • unplanned external actions

The purpose of this checklist is to make security and risk review a required part of AI automation design, not something added later after a problem appears.

The v1.1 upgrade expands this checklist to cover the more advanced client-facing automation patterns absorbed from the AI Automations by Jack n8n/client automation block.

These include:

  • self-hosted n8n
  • Make/n8n hybrid workflows
  • webhook bridges
  • WhatsApp automation
  • VAPI voice agents
  • lead intake systems
  • cold outreach systems
  • scraping and enrichment systems
  • client report automation
  • proposal generation
  • market-driven content workflows
  • AI app front ends
  • client AIOS delivery paths

Strategic Importance

AI automation security is strategically important to MWMS for five reasons.

1. MWMS Is Building Connected Systems

MWMS is not just creating static content or simple prompts.

MWMS is building connected systems across:

  • WordPress
  • Supabase
  • Make
  • n8n
  • Gmail
  • Google Drive
  • OpenAI
  • Claude
  • task queues
  • dashboards
  • Brain pages
  • AI Employees
  • RAG systems
  • webhooks
  • client reports
  • client communication systems
  • future AIBS packages

The more connected the system becomes, the more important access control, logging, permissions, credential handling, and failure recovery become.

2. Client-Grade AI Systems Require Trust

Future AIBS client systems must be trusted by business owners.

Trust is not built only through impressive demos.

Trust is built through:

  • secure data handling
  • clear permissions
  • visible logs
  • controlled access
  • compliance awareness
  • responsible AI behavior
  • recovery plans
  • professional risk management
  • safe handoff
  • clear responsibility boundaries
  • client data isolation
  • approval gates
  • source traceability

Security can become a sales advantage for MWMS if it is built into the offer from the beginning.

3. AI Automations Can Fail Silently

A normal human mistake may be visible.

An automation mistake may repeat hundreds of times before anyone notices.

Examples:

  • sending the wrong email
  • exposing a private record
  • misclassifying leads
  • burning API credits
  • updating the wrong database
  • sending confidential context to the wrong model
  • triggering the wrong workflow
  • leaking a webhook
  • allowing prompt injection
  • creating bad records at scale
  • sending a PDF to the wrong client
  • replying to the wrong WhatsApp chat
  • using the wrong transcript for a proposal
  • generating false competitor intelligence
  • sending cold outreach without suppression checks

MWMS must therefore design for monitoring, logs, alerts, and containment.

4. Governance Protects Long-Term Scale

MWMS cannot scale serious AI systems if every automation is built differently.

Security and risk rules must become reusable standards.

This checklist helps MWMS create consistent preflight reviews across:

  • internal systems
  • client systems
  • AI Employees
  • automation workflows
  • dashboards
  • RAG systems
  • communication tools
  • outbound systems
  • reporting systems
  • future AIOS packages

5. Client-Facing Automation Has Higher Risk Than Internal Automation

The latest course block confirms that many of the most valuable AIBS products touch live client operations.

Examples:

  • customer communication
  • sales follow-up
  • lead qualification
  • proposal creation
  • competitor reports
  • cold outreach
  • voice AI
  • WhatsApp automation
  • report delivery
  • public content creation

These are commercially useful, but they require stronger guardrails.

MWMS Rule

The closer an automation gets to customers, prospects, client money, public content, personal data, or live systems, the stronger the security and risk review must be.

Core Doctrine

The MWMS security doctrine is:

Security is not a final step.
Security is part of the system design.

A system should not be considered production-ready simply because it works.

A system is only production-ready when it is:

  • useful
  • reliable
  • observable
  • secure
  • governed
  • recoverable
  • permissioned
  • cost-controlled
  • legally responsible
  • operationally responsible
  • client-safe
  • source-aware
  • testable
  • supported

MWMS must assume that automation risk grows as system value grows.

The more valuable the workflow, the more seriously it must be protected.

Definition

AI Automation Security is the discipline of protecting AI workflows, no-code automations, data flows, AI Employees, API credentials, prompts, connected tools, client records, communication systems, generated outputs, and system actions from misuse, exposure, failure, abuse, or uncontrolled behavior.

MWMS Definition

AI Automation Security is:

The set of rules, checks, permissions, logs, recovery plans, approval gates, and governance controls that make AI automations safe enough to use in real business systems.

Scope

This checklist applies to:

  • Make scenarios
  • n8n workflows
  • Zapier workflows
  • OpenAI API workflows
  • Claude API workflows
  • OpenRouter workflows
  • Supabase integrations
  • WordPress plugin automations
  • Gmail automations
  • Google Drive automations
  • Google Sheets automations
  • Airtable workflows
  • CRM automations
  • GoHighLevel workflows
  • form automations
  • lead routing systems
  • outbound enrichment systems
  • cold outreach systems
  • client dashboards
  • internal dashboards
  • AI Employees
  • chatbots
  • WhatsApp automation
  • voice agents
  • RAG systems
  • AI app-builder front ends
  • report generators
  • PDF generators
  • proposal generators
  • content production systems
  • AI Operating Systems
  • future AIBS client systems

It applies to both internal MWMS systems and client-facing systems.

1. API Key Security

API keys must be treated like passwords.

They can give direct access to accounts, models, credits, data, tools, and connected systems.

If exposed, they can be used to burn credits, access private workflows, copy data, or compromise systems.

Required Checks

  • API keys are never shown in screenshots.
  • API keys are never pasted into public chats.
  • API keys are never hardcoded into code.
  • API keys are never stored in plain text inside prompts.
  • API keys are never stored inside shared workflow notes.
  • API keys are never included in exported workflow templates.
  • API keys are stored in secure credential fields where possible.
  • API keys are rotated when exposed.
  • API keys are revoked when unused.
  • API keys are reviewed periodically.
  • API key owner is known.
  • API key purpose is known.
  • API key access scope is limited.
  • API key usage is monitored.

MWMS Rule

No API key should appear in visible page content, screenshots, training files, workflow exports, shared documentation, app-builder prompts, or client handover material.

2. Credential Storage

Credentials should be stored in secure tool credential managers, environment variables, vaults, or platform-approved secure storage.

Credentials should not be placed directly into:

  • code nodes
  • prompt text
  • exported workflow JSON
  • screenshots
  • browser notes
  • uncontrolled documents
  • app-builder prompts
  • client-facing documentation

Required Checks

  • Credentials are stored in the platform credential manager where available.
  • Credentials are not hardcoded in workflow code.
  • Credentials are not included in shared examples.
  • Dummy credentials are used for screenshots or training.
  • Real credentials are removed before export.
  • Credential naming is clear.
  • Credential owner is documented.
  • Credential permissions match the workflow need.

MWMS Rule

If a credential must be shared manually, the system design is probably wrong.

Use controlled access instead.

3. Unused Key Deletion

Unused keys create unnecessary exposure.

Old keys, test keys, abandoned integration keys, and temporary keys should be deleted.

Required Checks

  • Unused OpenAI keys deleted.
  • Unused Claude keys deleted.
  • Unused Make/n8n/Zapier credentials deleted.
  • Old webhook URLs reviewed.
  • Old test credentials removed.
  • Former team member access removed.
  • Old client access removed.
  • Keys linked to abandoned systems revoked.
  • Unused app-builder API keys removed.
  • Old self-hosted n8n credentials reviewed.
  • Old client tool tokens revoked after offboarding.

Review Cadence

For active systems:

  • monthly for internal systems
  • before client handoff
  • after team access changes
  • after suspected exposure
  • after major workflow rebuilds
  • after client offboarding
  • after tool replacement

MWMS Rule

Every active key must have a known reason to exist.

4. Least Privilege

Least privilege means each tool, user, AI Employee, credential, or automation receives only the access it needs to perform its job.

Nothing more.

Required Checks

  • Does this automation need read access only?
  • Does it need write access?
  • Does it need delete access?
  • Does it need admin access?
  • Does it need access to all records or only one table?
  • Does it need access to all files or only one folder?
  • Does it need access to all emails or only labeled emails?
  • Does it need payment access?
  • Does it need client-wide access?
  • Does it need all WhatsApp chats or only one approved chat?
  • Does it need all CRM records or only lead intake records?
  • Does it need all transcripts or only one matched transcript?
  • Can permission be narrowed?

Examples

Bad:

Giving an automation full admin access to a database when it only needs to insert a lead record.

Better:

Giving the automation insert-only permission to the specific lead intake table.

Bad:

Giving an AI Employee access to all Gmail data when it only needs newsletters under a specific label.

Better:

Limiting the workflow to the relevant Gmail label or intake source.

Bad:

Allowing WhatsApp automation to trigger on every incoming message.

Better:

Filtering by approved chat, contact, group, or workflow scope.

MWMS Rule

If the automation does not need the permission, it should not have the permission.

5. Rate Limits And Cost Caps

AI automations can accidentally or maliciously trigger excessive API usage.

This can create unexpected costs.

Required Checks

  • API usage limits are set where possible.
  • Token limits are defined for AI calls.
  • Scenario operation limits are understood.
  • Workflow run frequency is controlled.
  • Infinite loops are prevented.
  • Retry behavior is limited.
  • Error loops do not repeatedly call paid APIs.
  • Cost spikes trigger alerts.
  • Usage dashboards are reviewed.
  • Expensive models are used only when needed.
  • Voice calls have duration/cost controls.
  • Scraping runs have frequency limits.
  • Outreach batch sizes are limited.
  • PDF/report generation is not triggered repeatedly by error loops.

Risk Examples

  • webhook receives repeated spam submissions
  • AI workflow retries repeatedly after failure
  • bad loop calls the model hundreds of times
  • prompt injection causes excessive tool use
  • agent keeps calling external tools unnecessarily
  • scraper pulls too much data too often
  • voice agent stays active too long
  • report generator creates duplicate PDFs
  • cold outreach sequence sends too many emails too quickly

MWMS Rule

Every paid AI workflow must have cost exposure considered before deployment.

6. Data Classification

Not all data should be treated the same.

MWMS systems must classify data before deciding how it should be stored, processed, shared, or passed into AI systems.

Data Categories

Public

Information that can be safely seen by anyone.

Examples:

  • public website copy
  • public product descriptions
  • published blog posts
  • public pricing
  • public social media content

Internal

Information intended only for MWMS internal use.

Examples:

  • internal processes
  • draft frameworks
  • Brain planning notes
  • internal dashboards
  • task logs

Confidential

Sensitive MWMS or client business information.

Examples:

  • strategy documents
  • client context packs
  • unpublished offers
  • revenue numbers
  • private operational plans
  • campaign data
  • client reports
  • internal transcripts

Restricted

High-risk information requiring strong protection.

Examples:

  • API keys
  • passwords
  • payment credentials
  • private customer data
  • personal identifiers
  • health data
  • legal records
  • sensitive client records
  • call recordings
  • private WhatsApp messages
  • prospect records used for outreach

Required Checks

  • What data category is being handled?
  • Is restricted data involved?
  • Does the AI need this data?
  • Can the data be minimized?
  • Can the data be anonymized?
  • Can the data stay out of the LLM?
  • Who can access the output?
  • How long should it be retained?
  • Does the workflow involve client or customer data?
  • Is cross-client leakage possible?

MWMS Rule

Restricted data should not enter AI workflows unless there is a clear reason, permission, and protection method.

7. Client Data Protection

Client data must be handled carefully.

This becomes especially important for future AIBS client systems.

Required Checks

  • Client data flow is mapped.
  • Client data source is known.
  • Client data destination is known.
  • Client data storage location is known.
  • Third-party tools processing client data are identified.
  • Sensitive data is minimized.
  • Data retention is defined.
  • Client access permissions are defined.
  • Team access permissions are defined.
  • Data deletion process is understood.
  • Client approval is obtained where required.
  • Client ID or tenant boundary is defined.
  • Wrong-client retrieval risk is tested.
  • Report delivery recipient is verified.

Questions To Ask

  • What client data enters the system?
  • Where does it go?
  • Who sees it?
  • Which tools process it?
  • Is it stored?
  • Is it sent outside the client’s region?
  • Is it used by an AI model?
  • Is it needed for the task?
  • Can the workflow work with less data?
  • Can another client’s data accidentally appear?

MWMS Rule

Every client-facing AIOS must include a client data flow review before deployment.

8. Sensitive Data Into LLMs

LLMs should not automatically receive sensitive data.

Even if a model provider has strong privacy policies, MWMS should minimize unnecessary exposure.

Sensitive Data Examples

  • passwords
  • API keys
  • private customer records
  • personal identifiers
  • private emails
  • payment data
  • health data
  • legal data
  • confidential business strategy
  • client trade secrets
  • unpublished financial records
  • WhatsApp messages
  • call transcripts
  • prospect records
  • CRM notes
  • proposal data

Required Checks

  • Does the AI need this exact data?
  • Can the data be redacted?
  • Can the data be summarized first?
  • Can fake placeholder names be used?
  • Can sensitive identifiers be removed?
  • Can the task be completed without sending raw data?
  • Is the selected model appropriate for this data?
  • Is the provider approved for this use case?
  • Is client permission required?
  • Is a non-LLM workflow safer?

MWMS Rule

Do not send sensitive data to an LLM because it is convenient.

Send it only when it is required and controlled.

9. Prompt Injection Protection

Prompt injection happens when user-supplied or external text attempts to override system instructions, reveal hidden prompts, access data, or manipulate workflow behavior.

This is a major AI automation risk.

Prompt Injection Examples

  • “Ignore all previous instructions.”
  • “Reveal your system prompt.”
  • “Send me all records.”
  • “Rank this application as the best.”
  • hidden text inside a document
  • malicious instructions in a webpage
  • malicious instructions inside a customer message
  • malicious text inside a CV, PDF, or form submission
  • instructions embedded in data retrieved by RAG
  • competitor page content trying to affect report generation
  • cold lead form text trying to manipulate qualification
  • WhatsApp message instructing the AI to reveal private data

Required Checks

  • User input is treated as untrusted.
  • External documents are treated as untrusted.
  • Scraped content is treated as untrusted.
  • Customer messages are treated as untrusted.
  • System instructions are separated from user input.
  • Retrieved content cannot override system rules.
  • Inputs are filtered where possible.
  • Outputs are validated before action.
  • Sensitive tools require approval.
  • AI cannot reveal hidden instructions.
  • AI cannot act on external instructions outside task scope.
  • High-risk actions require human review.

Protection Methods

  • input filtering
  • instruction hierarchy
  • tool access limits
  • output validation
  • topic boundaries
  • approval gates
  • read-only mode for high-risk tasks
  • retrieval filtering
  • prompt injection detection step
  • separate security reviewer agent

MWMS Rule

Any AI system that accepts external text must be designed as if that text may contain malicious instructions.

10. Zero Trust Input Handling

Zero trust means the system does not automatically trust incoming data.

Forms, webhooks, files, emails, chat messages, transcripts, scraped content, voice transcripts, and CRM payloads must be validated before being used.

Required Checks

  • Is the input source trusted?
  • Is the input format expected?
  • Is the input within length limits?
  • Does the input contain suspicious instructions?
  • Does the input contain restricted data?
  • Does the input match the expected schema?
  • Does the workflow validate required fields?
  • Does the workflow reject malformed data?
  • Does the workflow log invalid inputs?
  • Does the workflow prevent random payloads from entering downstream systems?
  • Does the webhook know its expected method?
  • Does the workflow validate client ID?
  • Does the workflow validate recipient before external delivery?

MWMS Rule

External input must be validated before it reaches important AI, database, report, communication, or action layers.

11. Tool Access Control

AI agents become risky when they have uncontrolled tool access.

The more tools an AI can use, the more important permission design becomes.

Required Checks

  • What tools can the AI access?
  • Does the AI need every tool?
  • Is each tool read-only or write-enabled?
  • Can the AI send emails?
  • Can the AI delete records?
  • Can the AI update databases?
  • Can the AI access payment systems?
  • Can the AI contact customers?
  • Can the AI create public content?
  • Can the AI change system settings?
  • Can the AI access WhatsApp, voice tools, CRM, or outreach tools?
  • Which tool actions require approval?

Tool Risk Levels

Low Risk

  • summarize text
  • classify records
  • draft content
  • generate internal notes
  • retrieve public information

Medium Risk

  • update internal records
  • create tasks
  • draft emails
  • enrich leads
  • update dashboards
  • create report drafts

High Risk

  • send emails
  • send WhatsApp messages
  • publish content
  • modify customer records
  • access payment tools
  • delete records
  • change permissions
  • trigger customer-facing communication
  • place or answer voice calls
  • send cold outreach
  • deliver client PDFs

MWMS Rule

AI can draft freely in many cases.

AI should act directly only when the action risk is low or properly governed.

12. Human Approval Gates

Human approval gates protect important actions.

Not every automation requires approval, but high-risk actions should.

Actions That Usually Require Approval

  • sending customer-facing emails
  • sending cold outreach
  • sending WhatsApp messages beyond approved simple flows
  • launching voice agents
  • publishing public content
  • deleting records
  • changing campaign settings
  • changing budgets
  • accessing restricted client data
  • sending payment-related messages
  • modifying legal/compliance content
  • changing Brain Canon pages
  • routing high-impact tasks
  • making strategic recommendations final
  • sending client reports with recommendations
  • sending proposals
  • sending generated PDFs externally
  • using scraped/enriched personal data for outreach

Approval Questions

  • Who approves this?
  • What exactly are they approving?
  • Can they edit before approval?
  • Is the approval logged?
  • Can they reject with reason?
  • What happens after rejection?
  • What happens if nobody approves?
  • Does approval apply once or to all future actions?

MWMS Rule

If the action can create financial, reputational, legal, compliance, customer, or client harm, add a human approval gate.

13. Logging And Audit Trail

A system cannot be trusted if nobody can see what it did.

Every important AI workflow should create logs.

Logs May Include

  • trigger event
  • timestamp
  • input summary
  • AI model used
  • prompt version
  • source context used
  • output generated
  • action taken
  • user approval
  • rejection reason
  • error message
  • retry count
  • cost estimate
  • system status
  • related task ID
  • tool used
  • recipient
  • client ID
  • report generated
  • file delivered
  • webhook called
  • transcript used
  • WhatsApp chat ID
  • voice call summary

Required Checks

  • Is the workflow logged?
  • Where are logs stored?
  • Are logs readable?
  • Are logs linked to tasks?
  • Are errors captured?
  • Are AI outputs preserved where required?
  • Are human approvals recorded?
  • Can HeadOffice review system activity?
  • Can client-facing actions be traced?
  • Can wrong-recipient or wrong-client incidents be investigated?

MWMS Rule

No important automation should run invisibly.

14. Error Handling

Errors are normal.

Uncontrolled errors are dangerous.

Required Checks

  • What happens when an API call fails?
  • What happens when a tool is down?
  • What happens when the AI output is invalid?
  • What happens when required data is missing?
  • What happens when a database write fails?
  • What happens when the workflow times out?
  • What happens when a webhook receives bad data?
  • What happens when a report cannot be generated?
  • What happens when a PDF is missing?
  • What happens when email delivery fails?
  • What happens when WhatsApp send fails?
  • What happens when voice tool call fails?
  • What happens when Fireflies transcript is not found?
  • What happens when scraper returns no data?
  • Is there a retry rule?
  • Is there a failure alert?
  • Is there a fallback action?
  • Is the error logged?

MWMS Rule

Every production workflow must have a known failure path.

15. Backup And Recovery

AI systems can break, workflows can be deleted, accounts can be compromised, and data can be corrupted.

Backups protect continuity.

Required Checks

  • Workflow exports are backed up.
  • Database backups exist.
  • Critical tables can be restored.
  • Prompt versions are saved.
  • Important context packs are versioned.
  • System configuration is documented.
  • Recovery owner is known.
  • Recovery steps are documented.
  • Backup location is secure.
  • Backup cadence matches system importance.
  • Self-hosted n8n has backup strategy.
  • Client report history is preserved where required.
  • Generated deliverables can be recovered where needed.

Backup Priority

High Priority

  • client systems
  • revenue systems
  • task/event systems
  • Brain data
  • production workflows
  • API credential maps
  • reporting systems
  • lead/prospect systems
  • client communication systems
  • RAG/vector memory systems

Medium Priority

  • prototypes
  • test workflows
  • draft dashboards
  • non-critical automation exports

MWMS Rule

A system is not production-ready if it cannot be restored.

16. Vendor And Tool Risk Review

Every connected tool adds risk.

MWMS must consider whether a third-party tool is reliable, secure, necessary, affordable, and appropriate.

Required Checks

  • What tool is being used?
  • Why is it needed?
  • Is there an existing MWMS tool that can do the job?
  • Does the tool handle sensitive data?
  • Does the tool offer secure credential storage?
  • Does it have access controls?
  • Does it support audit logs?
  • Is it stable?
  • Is it likely to disappear?
  • Is it compliant enough for the use case?
  • What happens if the tool fails?
  • What happens if the price increases?
  • Can MWMS migrate away later?
  • Does the tool create platform/account risk?
  • Is the tool official or unofficial?
  • Does the tool process client/customer data?

v1.1 Tools Requiring Review

  • n8n
  • Make
  • Unipile
  • VAPI
  • GoHighLevel
  • Apollo
  • Appify
  • Anymailfinder
  • Fireflies
  • ElevenLabs
  • PDF.co
  • Placid
  • Gmail
  • Google Drive
  • Airtable
  • Google Sheets
  • Supabase
  • AI app-builder front ends

MWMS Rule

Do not add tools casually.

Every tool becomes a dependency.

17. Self-Hosting Risk

Self-hosting can reduce cost but increase responsibility.

If MWMS or a client self-hosts automation tools, databases, dashboards, or AI systems, MWMS must consider the operational and security burden.

Required Checks

  • Who maintains the server?
  • Who applies updates?
  • Who monitors uptime?
  • Who secures the environment?
  • Who manages backups?
  • Who handles firewall rules?
  • Who manages access?
  • Who responds to incidents?
  • Who checks vulnerability exposure?
  • Is cost saving worth the risk?
  • Is n8n running with PostgreSQL?
  • Are SSL/DNS settings correct?
  • Is Coolify or another deployment layer monitored?
  • Are production and test systems separated?
  • Are client workflows isolated?

MWMS Rule

Self-hosting should not be chosen only because it is cheaper.

It must be chosen only when MWMS can responsibly maintain it.

18. Vulnerability Scanning

Systems should be reviewed for technical weaknesses before production use.

This is especially important for dashboards, web apps, client portals, browser extensions, custom code, webhooks, AI app-builder front ends, and self-hosted systems.

Required Checks

  • Are dependencies up to date?
  • Are third-party libraries safe?
  • Are exposed endpoints protected?
  • Are forms validated?
  • Are API routes permissioned?
  • Are database rules enforced?
  • Are public pages leaking data?
  • Are webhooks exposed unnecessarily?
  • Are admin pages protected?
  • Are debug errors hidden from public users?
  • Are app-builder front ends exposing backend URLs?
  • Are client dashboards protected?
  • Are file download links permissioned?

MWMS Rule

Client-facing or public-facing AIOS interfaces require vulnerability review before launch.

19. Data Regulation And Jurisdiction Review

Data rules vary by location, industry, and data type.

MWMS must consider jurisdiction and compliance risk where relevant.

Relevant Areas

  • Australia privacy obligations
  • Australian Spam Act
  • GDPR / UK GDPR
  • PECR
  • CAN-SPAM
  • CASL
  • US state privacy laws
  • HIPAA for health-related data
  • financial data rules
  • employment data rules
  • children’s data rules
  • platform-specific policies
  • advertising platform policies
  • client contractual obligations

Required Checks

  • What country is the client in?
  • What country are the customers in?
  • What data type is involved?
  • Is personal data involved?
  • Is sensitive data involved?
  • Is health, finance, legal, employment, or children’s data involved?
  • Which third-party tools process the data?
  • Is data leaving the original region?
  • Does the client need to approve this?
  • Is legal advice required?
  • Is outreach involved?
  • Is consent or opt-out required?
  • Is voice recording involved?
  • Is WhatsApp/SMS messaging involved?

MWMS Rule

If the system handles regulated, sensitive, outreach, voice, or customer communication data, compliance review is required before deployment.

20. Data Protection Impact Review

For higher-risk systems, MWMS should perform a simple data protection impact review.

This does not need to be overcomplicated for every prototype, but it becomes important for client-grade systems.

Review Questions

  • What data is collected?
  • Why is it collected?
  • Where is it stored?
  • Who can access it?
  • Which third parties process it?
  • How long is it retained?
  • What could go wrong?
  • What harm could occur?
  • What safeguards exist?
  • Is the data necessary?
  • Can it be reduced?
  • Can it be anonymized?
  • Can the user request deletion?
  • Is client data isolated?
  • Is opt-out/suppression required?
  • Is data used for AI training, retrieval, reports, or outreach?

MWMS Rule

The more sensitive the data, the stronger the data protection review must be.

21. Prompt And Output Validation

AI output should not always be trusted automatically.

Validation is required when AI output drives important action.

Required Checks

  • Is the output in the expected format?
  • Is it complete?
  • Is it grounded in source material?
  • Does it contain unsupported claims?
  • Does it expose sensitive data?
  • Does it follow policy?
  • Does it follow the system prompt?
  • Does it need human review?
  • Does it need a second AI checker?
  • Does it need schema validation?
  • Does it identify source limitations?
  • Does it use the correct client data?
  • Does it create a report, proposal, outreach email, or customer response?

Validation Methods

  • JSON schema validation
  • output checklist
  • source evidence check
  • human review
  • second-pass AI reviewer
  • compliance scan
  • confidence threshold
  • fallback if invalid
  • retry with corrected prompt

MWMS Rule

AI output that triggers real-world action should be validated before execution.

22. Legal And Contract Responsibility

When AI systems are built for clients, the contract must clarify responsibility.

This becomes important if a system fails, leaks data, sends incorrect messages, or affects revenue.

Required Checks

  • Who owns the system?
  • Who maintains the system?
  • Who monitors it?
  • Who approves outputs?
  • Who is responsible for tool costs?
  • Who is responsible for data compliance?
  • What uptime is promised?
  • What happens if the system fails?
  • What happens if third-party tools fail?
  • What is excluded from scope?
  • What requires additional paid support?
  • What risks does the client accept?
  • Who approves outreach?
  • Who approves voice scripts?
  • Who approves customer responses?
  • Who approves generated reports/proposals?

MWMS Rule

Client-grade AIOS work must include clear scope, responsibility, and limitation language.

23. Incident Response

Security issues and system failures need a response plan.

Incident Examples

  • API key exposed
  • workflow sends wrong email
  • client data leaked
  • database records corrupted
  • tool account compromised
  • unexpected cost spike
  • automation loop runs repeatedly
  • prompt injection succeeds
  • AI publishes incorrect content
  • dashboard exposes private data
  • WhatsApp replies to wrong chat
  • client report sent to wrong recipient
  • proposal generated from wrong transcript
  • cold outreach sent to unsubscribed contact
  • voice agent gives unsafe answer
  • scraper collects wrong data
  • webhook abused

Required Response Plan

  • identify issue
  • stop affected workflow
  • revoke exposed keys
  • isolate affected data
  • preserve logs
  • notify responsible owner
  • assess impact
  • inform client if required
  • fix root cause
  • document incident
  • update checklist
  • add prevention rule

MWMS Rule

If an incident occurs, fix the system and update the standard so the same failure is less likely to repeat.

24. Team And Contractor Access

MWMS will increasingly involve M, future employees, contractors, specialists, and possibly client-side operators.

Access must be controlled.

Required Checks

  • Who has access?
  • Why do they need access?
  • Is access role-based?
  • Can access be removed quickly?
  • Are shared accounts avoided?
  • Are credentials personally assigned where possible?
  • Is MFA enabled?
  • Are permissions reviewed after role changes?
  • Are former contractors removed?
  • Are logs available?
  • Is client access separated from MWMS internal access?
  • Is developer access limited to assigned scope?

MWMS Rule

Access should belong to roles and responsibilities, not convenience.

25. Multi-Factor Authentication

Important accounts should use multi-factor authentication.

Required MFA Areas

  • email accounts
  • Google accounts
  • hosting accounts
  • Supabase
  • WordPress admin
  • Make
  • n8n
  • payment tools
  • AI provider accounts
  • domain registrar
  • password manager
  • cloud storage
  • GoHighLevel
  • outreach tools
  • client-facing dashboards
  • self-hosted infrastructure admin panels

MWMS Rule

Any account that can affect MWMS infrastructure, data, money, clients, customer communication, or client systems should use MFA where possible.

26. Public Sharing And Training Material Safety

Screenshots, Loom videos, exported templates, tutorials, workflow JSON, and documentation can leak sensitive information.

Required Checks

Before sharing training material, confirm:

  • no API keys visible
  • no passwords visible
  • no private client names visible
  • no private email addresses visible
  • no webhook URLs visible if sensitive
  • no database secrets visible
  • no internal credentials visible
  • no live customer data visible
  • no hidden pinned test data included
  • no private workflow notes included
  • no client report data visible
  • no prospect lists visible
  • no WhatsApp messages visible
  • no transcripts visible without permission
  • no tool account IDs exposed unnecessarily

MWMS Rule

Training material must be sanitized before sharing.

27. Security By Design

Security should be included from the first design conversation.

It should not be treated as cleanup.

Design Questions

  • What data enters the system?
  • What data leaves the system?
  • What actions can the system take?
  • What happens if someone abuses it?
  • What happens if an API key leaks?
  • What happens if the AI is wrong?
  • What happens if the tool is down?
  • What happens if a client misuses it?
  • What happens if an attacker submits malicious input?
  • What is the safest simple version?
  • What should remain draft-only first?
  • What needs human approval?
  • What should never be automated?

MWMS Rule

Build the system as if it may eventually handle real data, real clients, and real consequences.

28. Webhook Exposure Review

The latest n8n block makes webhook security more important.

Webhooks are system doorways.

They can receive data from forms, apps, CRMs, Make, n8n, dashboards, chatbots, app-builder front ends, Chrome extensions, voice tools, or client systems.

Required Checks

  • What is the webhook purpose?
  • Is this test or production URL?
  • Is the workflow activated?
  • What HTTP method is allowed?
  • Is more than one method allowed?
  • Is each method routed correctly?
  • Is the payload schema defined?
  • Is authentication or a secret used?
  • Is the source system known?
  • Is logging active?
  • Are malformed payloads rejected?
  • Can this webhook trigger external action?
  • Can this webhook be abused?
  • Can it be rate-limited?
  • Does it expose sensitive workflow behavior?

MWMS Rule

A webhook is a doorway.

Do not leave it unguarded.

29. n8n Deployment And Self-Hosted Workflow Review

n8n may become a major MWMS automation layer.

That creates additional review requirements.

Required Checks

  • Is this n8n cloud or self-hosted?
  • Who owns the instance?
  • Are test and production workflows separated?
  • Are credentials stored properly?
  • Is PostgreSQL used where needed?
  • Is workflow export/back-up available?
  • Are webhooks protected?
  • Are workflow calls internal where possible?
  • Are external webhooks avoided when native workflow calls are enough?
  • Are logs readable?
  • Are client workflows isolated?
  • Are error paths defined?
  • Are workflow names clear?
  • Is there a disable/rollback process?

MWMS Rule

n8n is infrastructure when it supports real workflows.

Treat it as infrastructure, not a toy.

30. Make / n8n Hybrid Bridge Review

The Make/n8n sandwich pattern allows workflows to call each other.

This is useful, but it creates cross-platform risk.

Required Checks

  • Which platform triggers the workflow?
  • Which platform receives the request?
  • Is it activation-only or data-rich?
  • What data is sent?
  • What response is expected?
  • Is the bridge logged on both sides?
  • What happens if one platform fails?
  • Are retries controlled?
  • Is sensitive data sent across the bridge?
  • Is the old Make scenario still needed?
  • Is rebuilding unnecessary?
  • Is ownership clear?

MWMS Rule

Bridge Make and n8n when it protects working systems.

Do not rebuild just to change platforms.

31. WhatsApp Automation Risk Review

WhatsApp automation is high-risk because it touches real people and private conversations.

Required Checks

  • Which WhatsApp account is used?
  • Which provider is used?
  • Is the provider official or third-party?
  • Which chat/contact/group is approved?
  • Is group processing permitted?
  • Does automation filter by chat ID or contact?
  • Can the workflow accidentally respond to every incoming message?
  • What message types are allowed?
  • Is human handoff available?
  • Are messages logged?
  • Is sensitive data minimized?
  • Is client permission documented?
  • Is opt-out or stop behavior needed?

MWMS Rule

No WhatsApp automation may trigger broadly across all messages by default.

Scope must be explicit.

32. Voice AI Consent And Call Safety Review

Voice AI is high-risk because interactions happen live.

Required Checks

  • Is the voice agent internal or customer-facing?
  • Is consent/disclosure required?
  • Is the call recorded?
  • Is a transcript stored?
  • Is the script approved?
  • What knowledge can the agent use?
  • What must it not answer?
  • What tools can it call?
  • When does it hand off?
  • What happens if the caller asks for a human?
  • What post-call summary is generated?
  • Who reviews call failures?
  • Can the agent make commitments?
  • Can it discuss pricing, refunds, legal, health, or financial matters?

MWMS Rule

Voice AI requires approved scope, disclosure/consent review, handoff, logging, and post-call review before client use.

33. Cold Outreach Compliance Review

Outbound automation creates legal, reputational, and deliverability risk.

Required Checks

  • Is this B2B or consumer outreach?
  • What jurisdiction applies?
  • What lead source is used?
  • Was the data scraped, enriched, purchased, or permissioned?
  • Is the message truthful?
  • Is the sender clearly identified?
  • Is opt-out included where required?
  • Is suppression list active?
  • Are unsubscribes respected?
  • Are bounced/complained contacts suppressed?
  • Is sending volume controlled?
  • Is the sending domain protected?
  • Are case study claims approved?
  • Is human review active before launch?
  • Is the campaign treated as an experiment with stop conditions?

MWMS Rule

Start with research and reviewed drafts before automated sending.

No cold outreach system should launch without compliance review.

34. Scraping And Enrichment Risk Review

Scraping and enrichment workflows can be valuable, but they create risk.

Required Checks

  • What source is scraped?
  • Is the source public?
  • Are platform terms considered?
  • What data is collected?
  • Is personal data collected?
  • Is collection limited?
  • Is frequency controlled?
  • Is data fresh?
  • Is source timestamp stored?
  • Is enrichment verified?
  • Is data used for outreach?
  • Is retention defined?
  • Is client approval needed?
  • Is opt-out/suppression needed?

MWMS Rule

Scraping and enrichment are not casual research when they involve people, customers, prospects, or client use.

35. Client Report PDF Privacy Review

Client reports can look official and may include sensitive information.

Required Checks

  • Is the report for the correct client?
  • Is the reporting period correct?
  • Is the source data correct?
  • Is the report draft or approved?
  • Are recommendations validated?
  • Is competitor information evidence-based?
  • Does the report include private messages?
  • Does it include personal data?
  • Is the PDF attached to the correct email?
  • Is the Google Drive link permissioned correctly?
  • Is the recipient verified?
  • Is the report logged?

MWMS Rule

PDF generation is not approval.

Generated client reports must be validated before external delivery.

36. Proposal Generation Accuracy Review

Transcript-to-proposal automation is powerful but risky.

Required Checks

  • Is the correct transcript matched?
  • Is the correct client email matched?
  • Are pain points extracted accurately?
  • Are deliverables accurate?
  • Are assumptions marked?
  • Are exclusions included?
  • Are pricing terms approved?
  • Are timelines approved?
  • Are commitments human-reviewed?
  • Is the proposal draft status visible?
  • Is the final send approved?

MWMS Rule

AI may draft proposals.

Humans must approve scope, pricing, commitments, and commercial terms.

37. Lead Intake And Qualification Safety Review

Lead systems can affect sales decisions and customer experience.

Required Checks

  • Is the form payload cleaned?
  • Are required fields validated?
  • Is spam filtered?
  • Is duplicate logic present?
  • Is lead scoring defined?
  • Does qualification include a reason?
  • Is AI confidence considered?
  • Is follow-up matched to lead status?
  • Is consent captured where needed?
  • Is CRM routing correct?
  • Is high-value lead review required?
  • Is the report/lead magnet safe?
  • Is the sales task created?

MWMS Rule

Lead intake should not stop at form capture.

It must create structured, safe, explainable sales action.

38. Market-Driven Content Automation Review

Content workflows can create public risk if they publish without review.

Required Checks

  • What source material is used?
  • Is scraped content used only for insight, not copying?
  • Are customer reviews handled correctly?
  • Are competitor references safe?
  • Is human approval required?
  • Are claims compliant?
  • Is platform format appropriate?
  • Is private data excluded?
  • Is publishing manual or automatic?
  • Is performance logged?
  • Are high-risk claims blocked?

MWMS Rule

Start with reviewed drafts before fully automated posting.

Content must be source-led, not source-copied.

39. AI App Builder Front-End Review

AI app builders such as Lovable-style tools can create useful front ends quickly, but they are not automatically production-safe.

Required Checks

  • Is this a prototype or production system?
  • Does it connect to live workflows?
  • Does it expose backend webhook URLs?
  • Does it handle client data?
  • Is authentication required?
  • Is the generated code reviewed?
  • Is database access controlled?
  • Are users warned if it is a demo?
  • Is M expected to inherit this code?
  • Has SIT reviewed it?

MWMS Rule

AI app-builder front ends are prototypes until hardened, tested, secured, and owned.

MWMS AI Automation Preflight Checklist

Use this checklist before any AI automation moves from test to active use.

A. System Purpose

  • The business problem is clear.
  • The user is clear.
  • The desired outcome is clear.
  • The workflow owner is clear.
  • The system is worth automating.
  • The client or internal use case is defined.

B. Data Handling

  • Data inputs are mapped.
  • Data outputs are mapped.
  • Sensitive data is identified.
  • Unnecessary data is removed.
  • Storage location is known.
  • Retention rules are known.
  • Source of truth is defined.
  • Client data boundary is defined where relevant.
  • Personal data use is justified where relevant.

C. Access And Credentials

  • API keys are hidden.
  • API keys are stored securely.
  • Unused keys are deleted.
  • Least privilege is applied.
  • MFA is enabled where possible.
  • Team access is controlled.
  • Former access is removed.
  • Client access is separated.
  • Tool permission level is known.

D. AI And Prompt Safety

  • System instructions are separated from user input.
  • Prompt injection risk is considered.
  • External content is treated as untrusted.
  • AI output is validated where required.
  • Sensitive data is not passed unnecessarily.
  • The AI cannot access tools it does not need.
  • RAG/retrieved context cannot override governance.
  • Source authority is checked where relevant.

E. Automation Reliability

  • Trigger is clear.
  • Workflow steps are mapped.
  • Failure states are known.
  • Retry behavior is controlled.
  • Errors are logged.
  • Alerts are configured.
  • Fallback path is defined.
  • Duplicate actions are prevented.
  • Item count behavior is tested.

F. External Action Safety

  • External actions are identified.
  • Human approval is added where needed.
  • Recipients are verified.
  • Content is reviewed where required.
  • Suppression/opt-out is active where relevant.
  • Public publishing is controlled.
  • Customer communication is scoped.
  • Client report delivery is validated.

G. Governance

  • Human approval gates are added where needed.
  • Risk level is known.
  • Compliance issues are reviewed.
  • Client responsibility is clear.
  • System owner is clear.
  • Escalation path is defined.
  • Tool owner is known.
  • Client handoff rules are known.

H. Monitoring And Recovery

  • Logs are created.
  • Cost exposure is reviewed.
  • Usage is monitored.
  • Backups exist.
  • Recovery steps are known.
  • Incident response plan exists.
  • Disable/rollback path is known.

I. 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

AI Automation Risk Levels

MWMS should classify automations into risk levels.

Level 1: Low Risk

Examples

  • summarizing public content
  • drafting internal notes
  • classifying non-sensitive records
  • generating brainstorming ideas
  • creating internal task suggestions

Requirements

  • basic logging
  • basic output review
  • no sensitive data
  • no external action

Level 2: Moderate Risk

Examples

  • updating internal task records
  • drafting client emails
  • analyzing campaign data
  • enriching leads
  • creating content drafts
  • updating dashboards
  • generating report drafts

Requirements

  • logging
  • access control
  • output validation
  • human review for external use
  • limited permissions

Level 3: High Risk

Examples

  • sending customer emails
  • sending WhatsApp messages
  • updating CRM records
  • using client data
  • publishing content
  • triggering external communications
  • making recommendations affecting spend
  • creating client-facing reports
  • using scraped/enriched prospect data
  • voice AI customer interactions

Requirements

  • human approval gate
  • data review
  • prompt injection control
  • permission review
  • failure handling
  • audit trail
  • escalation path
  • compliance review where relevant

Level 4: Critical Risk

Examples

  • payment workflows
  • legal workflows
  • health data workflows
  • financial advice workflows
  • deleting records
  • changing budgets automatically
  • modifying production systems
  • client-critical business operations
  • high-volume cold outreach
  • autonomous customer communication without review

Requirements

  • strict human approval
  • compliance review
  • legal/scope review
  • strong access control
  • backup and recovery
  • incident response plan
  • limited automation authority
  • production monitoring

MWMS Approval Rule

The higher the risk level, the stronger the approval gate must be.

Low-risk systems can run with light review.

Critical-risk systems require explicit human control.

Application To MWMS Brains

HeadOffice Brain

HeadOffice owns the overall security posture and decides whether systems are safe to advance.

Responsibilities

  • enforce preflight checklist
  • review risk classification
  • monitor active systems
  • escalate unresolved risks
  • maintain system-wide security standards
  • approve cross-Brain security policy
  • block unsafe client-facing automation when needed

Risk Brain

Risk Brain owns failure scenarios, dependency risk, exposure analysis, and mitigation planning.

Responsibilities

  • classify risk level
  • identify failure modes
  • define fallback paths
  • review dependency exposure
  • recommend mitigation
  • review client-facing operational risk

Compliance Brain

Compliance Brain owns data, policy, jurisdiction, advertising, outreach, privacy, and claims-related risk.

Responsibilities

  • review sensitive data workflows
  • review jurisdiction issues
  • review platform policy concerns
  • review client compliance exposure
  • define approval requirements
  • review cold outreach systems
  • review voice/call consent issues
  • review content claims

Automation Brain

Automation Brain owns workflow safety, triggers, error handling, retries, permissions, and integration stability.

Responsibilities

  • map workflow steps
  • define failure states
  • control retries
  • protect webhooks
  • log automation events
  • test workflow reliability
  • govern n8n/Make workflow structure
  • ensure external actions are controlled

AIBS Brain

AIBS Brain owns client-facing delivery risk.

Responsibilities

  • define client scope
  • define responsibility boundaries
  • ensure client systems are secure enough
  • include safety in productized offer design
  • ensure client onboarding collects security context
  • ensure client systems have approval, logging, support, and handoff

Data Brain

Data Brain owns data structure, data flow, storage, retention, source of truth, and measurement reliability.

Responsibilities

  • classify data
  • map data flow
  • define table access
  • maintain data integrity
  • support auditability
  • protect client isolation
  • define RAG/vector metadata requirements
  • define report and lead/prospect data schema

Operations Brain

Operations Brain owns execution reliability and handoff safety.

Responsibilities

  • define operating procedures
  • maintain support workflows
  • ensure access handoff is controlled
  • ensure recovery steps are usable
  • define routine monitoring procedures

SIT Brain

SIT Brain owns system integrity testing.

Responsibilities

  • test before launch
  • verify checklist completion
  • confirm safe change conditions
  • detect regressions
  • validate production readiness
  • test failure paths
  • test wrong-client and wrong-recipient cases

Sales Brain

Sales Brain owns risk in lead, proposal, outbound, and follow-up systems.

Responsibilities

  • approve qualification logic
  • review proposal outputs
  • define outbound test limits
  • approve sales messaging
  • define handoff and follow-up rules

Customer Brain

Customer Brain owns customer experience safety.

Responsibilities

  • review communication tone
  • define handoff rules
  • identify complaint/escalation triggers
  • review chatbot and voice responses
  • improve FAQs from repeated questions

Content Brain

Content Brain owns public content risk.

Responsibilities

  • review content claims
  • control approval before publishing
  • avoid copied/scraped content misuse
  • ensure platform adaptation
  • log performance and content corrections

Common Failure Modes

Failure Mode 1: API Key Exposure

A key appears in a screenshot, workflow export, prompt, code node, app-builder prompt, or shared document.

Consequence

Unauthorized usage, cost spikes, account compromise, data exposure.

Correction

Revoke the key, create a new one, store securely, update workflow, document the incident.

Failure Mode 2: Over-Permissioned Workflow

The workflow has access to far more data or actions than required.

Consequence

A small error can create major harm.

Correction

Apply least privilege and narrow access.

Failure Mode 3: Sensitive Data Passed Into AI Without Need

Private data is sent to an LLM even though the task could have been completed without it.

Consequence

Privacy risk, compliance risk, client trust issue.

Correction

Redact, summarize, anonymize, or exclude sensitive data.

Failure Mode 4: Prompt Injection

External input manipulates the AI into ignoring instructions, revealing information, or taking unauthorized action.

Consequence

Data leak, workflow abuse, incorrect output, system compromise.

Correction

Separate instructions from input, filter external text, limit tools, validate output, require approval.

Failure Mode 5: No Logs

The automation runs, but nobody can tell what happened.

Consequence

Poor debugging, no accountability, low trust.

Correction

Add event logs, task logs, timestamps, output records, and error records.

Failure Mode 6: No Failure Path

The workflow breaks and silently stops or loops.

Consequence

Missed tasks, cost spikes, broken system, hidden failure.

Correction

Add failure routes, alerts, retry limits, and fallback handling.

Failure Mode 7: Client Data Flow Unknown

Nobody can explain where client data goes.

Consequence

Compliance risk, client distrust, implementation blocker.

Correction

Create a data flow map before deployment.

Failure Mode 8: Tool Dependency Ignored

The system depends on a third-party tool that may fail, change pricing, restrict access, or disappear.

Consequence

System fragility.

Correction

Document dependency risk and backup options.

Failure Mode 9: No Human Approval For High-Risk Action

AI takes an action that should have been reviewed.

Consequence

Wrong email, bad customer experience, legal risk, financial loss.

Correction

Add approval gate.

Failure Mode 10: Security Deferred Until Later

The system is built fast but insecurely.

Consequence

Expensive rebuild, launch blocker, client rejection, serious risk.

Correction

Apply security by design from the first build stage.

Failure Mode 11: Webhook Left Exposed

A webhook can be triggered by anyone or receives malformed/unwanted payloads.

Consequence

Workflow abuse, spam, cost spikes, unauthorized external actions.

Correction

Add authentication, secret, payload validation, logging, and rate controls where possible.

Failure Mode 12: Cold Outreach Sent Without Suppression

Unsubscribed, bounced, or inappropriate prospects are contacted.

Consequence

Compliance risk, deliverability damage, brand damage.

Correction

Implement suppression list and opt-out handling before sending.

Failure Mode 13: WhatsApp Automation Responds Too Broadly

Automation replies to the wrong chat, group, or contact.

Consequence

Privacy breach, customer confusion, client trust damage.

Correction

Filter by approved chat/contact/group and require tested scope.

Failure Mode 14: Voice Agent Gives Unsafe Answer

Voice AI answers outside approved scope or fails to hand off.

Consequence

Customer frustration, misinformation, compliance risk, brand damage.

Correction

Add script boundaries, approved knowledge, handoff triggers, and call review.

Failure Mode 15: Client Report Sent With Wrong Data

PDF or email includes wrong-client, stale, or unsupported information.

Consequence

Client trust damage, compliance risk, business embarrassment.

Correction

Validate report data, recipient, source, client ID, and approval status before delivery.

Failure Mode 16: Proposal Sent Without Commercial Review

AI-generated proposal includes wrong pricing, scope, timeline, or commitments.

Consequence

Revenue risk, client confusion, legal/commercial exposure.

Correction

Human approval required for scope, pricing, commitments, and exclusions.

Client-Grade Security Requirements

Before any AIOS is delivered to a client, MWMS should confirm:

  • client data flow is documented
  • access responsibilities are defined
  • AI access boundaries are clear
  • API keys are secure
  • human approvals are configured
  • logging is active
  • backups are defined
  • system owner is defined
  • support process is defined
  • failure process is defined
  • risk level is known
  • compliance concerns are reviewed
  • contract scope is clear
  • client knows what not to enter into the system
  • client data isolation is tested
  • report delivery is validated
  • external communication scope is approved
  • tool dependency risk is documented
  • handoff path is defined
  • rollback/disable path is known

MWMS Rule

No client-grade AIOS should be delivered without a documented safety and responsibility review.

Security Review Output Format

When reviewing an AI automation, MWMS should produce a short review record.

Review Record

System Name:
Owner:
Brain Owner:
Risk Level:
Data Handled:
Tools Connected:
AI Model Used:
External Actions:
Client Data Involved:
Personal Data Involved:
Human Approval Required:
API Key Review: Pass / Fail
Data Review: Pass / Fail
Prompt Injection Review: Pass / Fail
Webhook Review: Pass / Fail / Not Required
Tool Permission Review: Pass / Fail
Logging Review: Pass / Fail
Backup Review: Pass / Fail
Compliance Review: Pass / Fail / Not Required
SIT Review: Pass / Fail / Not Required
Launch Decision: Safe / Safe With Limits / Not Safe Yet
Required Fixes:
Reviewer:
Review Date:

Implementation Rules

Rule 1: No Production Workflow Without Credential Review

Any workflow using API keys, webhooks, credentials, or connected accounts must pass credential review.

Rule 2: No Client Data Workflow Without Data Flow Map

Any workflow handling client data must map where the data comes from, where it goes, and where it is stored.

Rule 3: No External Action Without Risk Classification

Any workflow that sends, publishes, updates, deletes, contacts externally, or creates client-facing deliverables must be classified by risk level.

Rule 4: No High-Risk AI Action Without Human Approval

High-risk AI actions must have a human approval gate.

Rule 5: No Important Workflow Without Logs

Every important automation must create logs that HeadOffice or the system owner can inspect.

Rule 6: No Sensitive Input Without Minimization

Sensitive data must be minimized, redacted, anonymized, or excluded where possible.

Rule 7: No External Text Without Prompt Injection Awareness

Any workflow accepting external text must consider prompt injection risk.

Rule 8: No Client-Grade System Without Recovery Path

Client-grade systems must have backup, recovery, and support procedures.

Rule 9: No Tool Added Without Dependency Review

Every new tool must justify its use and risk.

Rule 10: No Launch Without Owner

Every deployed AI automation must have an owner responsible for monitoring and maintenance.

Rule 11: No Client Communication Automation Without Handoff

Any workflow that replies to customers, prospects, leads, or clients must include handoff or escalation rules.

Rule 12: No Outbound Outreach Without Suppression And Opt-Out

Cold outreach workflows must include compliance review, suppression logic, opt-out handling, and send limits before launch.

Rule 13: No Client Report Delivery Without Recipient And Source Validation

Generated reports, PDFs, proposals, and client deliverables must be validated before sending.

Rule 14: No Self-Hosted Production System Without Maintenance Owner

Self-hosted n8n, databases, dashboards, or services require maintenance, backup, and monitoring ownership.

Rule 15: No App-Builder Prototype Treated As Production

AI app-builder front ends are prototypes until secured, tested, reviewed, and assigned an owner.

Related Employee Capabilities

AI Automation Security Reviewer

Reviews AI workflows before internal or client deployment.

Responsibilities

  • check credentials
  • classify data risk
  • review tool access
  • identify prompt injection risk
  • confirm approval gates
  • confirm logs
  • confirm recovery path
  • review external action risk

Credential Controller

Manages API keys, tool credentials, access rights, key rotation, and unused key deletion.

Responsibilities

  • maintain key inventory
  • revoke unused keys
  • monitor exposure
  • enforce secure storage
  • confirm least privilege

Data Protection Reviewer

Reviews data flows, sensitive data handling, retention, privacy exposure, and jurisdiction concerns.

Responsibilities

  • classify data
  • map data movement
  • reduce sensitive data exposure
  • flag compliance review needs
  • review client data isolation

Prompt Injection Tester

Tests AI workflows that accept external input.

Responsibilities

  • attempt instruction override
  • test hidden prompt exposure
  • test malicious input handling
  • recommend input filtering and output validation

AIOS Launch Gatekeeper

Approves or blocks AI Operating System launch based on readiness criteria.

Responsibilities

  • verify checklist completion
  • confirm risk level
  • confirm owner
  • confirm monitoring
  • approve launch status

Incident Recorder

Records failures, breaches, unsafe behavior, and corrective actions.

Responsibilities

  • document issue
  • preserve logs
  • record root cause
  • update checklist
  • recommend prevention

Webhook Security Reviewer

Reviews webhook exposure, payload schemas, authentication, and action boundaries.

Responsibilities

  • check endpoint exposure
  • confirm test/production URL
  • validate payload rules
  • review authentication
  • confirm logging and failure path

Outreach Compliance Reviewer

Reviews outbound workflows before launch.

Responsibilities

  • check lead source
  • check opt-out
  • check suppression list
  • review message claims
  • define send limits
  • monitor bounce/complaint risk

Client Report Safety Reviewer

Reviews generated client reports, proposals, PDFs, and deliverables before external delivery.

Responsibilities

  • confirm client identity
  • confirm source data
  • verify recipient
  • check sensitive data
  • check approval state
  • confirm delivery log

Future Expansion

This checklist should later connect to:

  • MWMS AIOS Launch Readiness Checklist
  • MWMS AI Credential Inventory Standard
  • MWMS AI Prompt Injection Protection Standard
  • MWMS Client Data Flow Map Template
  • MWMS AI Incident Response Protocol
  • MWMS AI Security Review Record Template
  • MWMS Vendor Risk Review Framework
  • MWMS AIOS Contract Responsibility Standard
  • SIT Brain AI Automation Security Test Suite
  • Risk Brain AI Automation Exposure Dashboard
  • MWMS Webhook Security Standard
  • MWMS Cold Outreach Compliance Checklist
  • MWMS Client Report Delivery Safety Checklist
  • MWMS Voice AI Consent And Call Safety Framework
  • MWMS n8n Self-Hosting Security Checklist

Potential Future Pages

  • MWMS AI Prompt Injection Defense Framework
  • MWMS API Key And Credential Governance Standard
  • MWMS Client AI Data Handling Protocol
  • MWMS AI Automation Incident Response Framework
  • MWMS AIOS Launch Gate Review Standard
  • MWMS Webhook Security And Exposure Framework
  • MWMS Client Communication Safety Checklist
  • MWMS Outbound Compliance And Suppression Standard

Strategic Summary

The MWMS AI Automation Security And Risk Checklist v1.1 makes security a formal part of automation design and expands the standard for more advanced, client-facing automation systems.

This protects MWMS from common AI automation risks:

  • exposed API keys
  • over-permissioned workflows
  • uncontrolled AI actions
  • client data leakage
  • prompt injection
  • hidden automation failure
  • uncontrolled cost spikes
  • weak logs
  • poor recovery planning
  • unclear legal responsibility
  • unsafe client deployment
  • exposed webhooks
  • cold outreach compliance failures
  • WhatsApp privacy mistakes
  • voice AI customer experience failures
  • wrong-recipient client reports
  • unreviewed proposal delivery
  • scraping and enrichment overreach
  • app-builder prototype risk

This page also strengthens MWMS as a future client-facing AI systems provider.

Most beginner AI automation builders will focus only on what the automation can do.

MWMS must focus on what the automation can do safely, reliably, visibly, and responsibly.

That is the difference between a toy automation and a business-grade AI Operating System.

Final Standard

The MWMS standard is:

If an AI automation touches tools, data, clients, prospects, customers, money, decisions, publishing, communication, reports, proposals, outreach, or business operations, it must pass a security and risk review before production use.

Security is not optional.

Security is part of MWMS system quality.

Change Log

Version: v1.1

Date: 2026-06-01
Author: MWMS HeadOffice

Change:

Updated the MWMS AI Automation Security And Risk Checklist using the AI Automations by Jack — AI Agents / n8n Client Automation block.

Expanded the checklist to cover new client-facing and infrastructure risks introduced by:

  • n8n operating and deployment
  • Make/n8n hybrid orchestration
  • self-hosted n8n
  • webhooks
  • WhatsApp / Unipile automation
  • VAPI voice agents
  • GoHighLevel lead intake
  • Apollo prospect research
  • Appify scraping
  • Anymailfinder enrichment
  • Fireflies transcript workflows
  • ElevenLabs dubbing/voice workflows
  • PDF.co report/file generation
  • Placid proposal/report generation
  • Gmail delivery
  • Google Drive file sharing
  • Google Sheets and Airtable lightweight databases
  • Supabase data and RAG systems
  • AI app-builder front ends
  • client report automation
  • proposal generation
  • outbound cold outreach
  • market-driven content automation

Added new security sections covering:

  • Webhook Exposure Review
  • n8n Deployment And Self-Hosted Workflow Review
  • Make / n8n Hybrid Bridge Review
  • WhatsApp Automation Risk Review
  • Voice AI Consent And Call Safety Review
  • Cold Outreach Compliance Review
  • Scraping And Enrichment Risk Review
  • Client Report PDF Privacy Review
  • Proposal Generation Accuracy Review
  • Lead Intake And Qualification Safety Review
  • Market-Driven Content Automation Review
  • AI App Builder Front-End Review

Expanded existing sections covering API key security, credential storage, least privilege, rate limits and cost caps, data classification, client data protection, sensitive data into LLMs, prompt injection protection, zero trust input handling, tool access control, human approval gates, logging, error handling, backups, vendor/tool risk, self-hosting, vulnerability scanning, data regulation review, legal/contract responsibility, incident response, access control, and security by design.

Expanded the MWMS AI Automation Preflight Checklist to include External Action Safety.

Expanded AI Automation Risk Levels to include WhatsApp, customer communication, client reports, voice AI, scraped/enriched prospect data, and autonomous customer communication.

Expanded Brain responsibilities for Sales Brain, Customer Brain, and Content Brain.

Added additional failure modes covering exposed webhooks, cold outreach without suppression, broad WhatsApp automation, unsafe voice agent responses, wrong client report delivery, and unreviewed proposal sending.

Added new implementation rules covering client communication handoff, outbound suppression and opt-out, client report validation, self-hosted maintenance ownership, and AI app-builder prototype limits.

Added new related Employee capabilities:

  • Webhook Security Reviewer
  • Outreach Compliance Reviewer
  • Client Report Safety Reviewer

Purpose of update:

To strengthen MWMS security and risk governance for advanced n8n/client automation systems that connect AI to communication channels, CRMs, outreach tools, scraping/enrichment systems, voice agents, report generators, proposal systems, app-builder interfaces, client dashboards, and client-facing AIOS workflows.

Version: v1.0

Date: 2026-05-31
Author: MWMS HeadOffice

Change:

Created from AI Automations by Jack — AI Foundations Section 1.

Added AI automation security and risk checklist as a formal MWMS governance page.

Integrated key course risks including API key exposure, credential handling, least privilege, rate limits, client data protection, sensitive data in LLMs, prompt injection, zero trust, backups, vulnerability scanning, and legal responsibility.

Established AI automation risk levels from low risk to critical risk.

Added MWMS AI Automation Preflight Checklist for internal and client-facing workflows.

Added client-grade security requirements for future AIBS Brain systems.

Added security review output format for repeatable MWMS review records.

Mapped responsibilities across HeadOffice Brain, Risk Brain, Compliance Brain, Automation Brain, AIBS Brain, Data Brain, Operations Brain, and SIT Brain.

Added related employee capabilities: AI Automation Security Reviewer, Credential Controller, Data Protection Reviewer, Prompt Injection Tester, AIOS Launch Gatekeeper, and Incident Recorder.

Identified future expansion pages for credential governance, prompt injection defense, client data handling, incident response, launch gate review, and vendor risk.

Purpose of creation:

To make security, privacy, credential safety, client data protection, prompt injection defense, least privilege, backup/recovery, logging, compliance review, and operational risk assessment a formal requirement before MWMS deploys AI automations or AI Operating Systems.

END — MWMS AI AUTOMATION SECURITY AND RISK CHECKLIST v1.1