Security and Privacy Controls for the AI Agent Platform

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/DevMauricio03/n8n-whatsapp-ai-agent/llms.txt

Use this file to discover all available pages before exploring further.

​

Immediate Actions

​

Minimum Security Controls

• HTTPS required — all external endpoints must be served over TLS; Caddy handles certificate provisioning automatically.
• Only Caddy exposed to the internet — n8n, Chatwoot, PostgreSQL, and Redis must never have their ports published directly on the host’s public interface.
• SSH via keys with limited access — disable password-based SSH authentication and restrict access to named, authorized keys only.
• Firewall with only required ports — block all inbound traffic except ports 80 (HTTP redirect) and 443 (HTTPS); restrict SSH to known IP ranges where possible.
• MFA for providers and dashboards — enable multi-factor authentication on the Meta Developer Portal, Google Cloud Console, OpenAI, and any other provider that holds credentials for this platform.
• Separate credentials per environment — staging, QA, and production must each use distinct database passwords, API tokens, and encryption keys. Never share credentials across environments.
• Principle of least privilege — grant each service account and human user only the permissions required for their specific role. Create dedicated PostgreSQL users for each database instead of sharing the superuser.
• Encrypted backups with tested restores — encrypt all backup archives at rest and run a full restore drill at least once before go-live to confirm the backups are valid.
• Controlled updates — never apply container image updates automatically in production; test in staging first and pin specific tags or digests.
• Periodic user review — audit the list of active users in Chatwoot, n8n, and infrastructure providers on a defined schedule and revoke accounts that are no longer needed.

​

Personal Data

• phone numbers;
• names and email addresses;
• messages and audio recordings;
• invoice folios, payments, and service results;
• conversation metadata (timestamps, agent assignments, labels).

1. The purpose and legal basis for processing each data category.
2. A privacy notice accessible to end users.
3. A mechanism to obtain and record consent where legally required.
4. A data retention period and the automated or manual process that enforces it.
5. A procedure for handling access, correction, and deletion requests from data subjects.
6. An inventory of third-party providers that receive personal data (OpenAI, Google, Meta, hosting providers).
7. Named individuals responsible for responding to data incidents.
8. A documented incident-response plan covering notification timelines.

​

AI Usage Guidelines

• Send only the context necessary for the model to answer the question. Do not include full conversation histories or unrelated customer records.
• Do not send sensitive data — such as payment details, health information, or government IDs — unless the provider’s terms and your legal basis explicitly permit it and the data is strictly required for the response.
• Do not allow the model to invent business information — use tool nodes backed by real data sources (PostgreSQL queries, Google Drive lookups) rather than asking the model to recall prices, policies, or folio details from memory.
• Validate permissions before revealing a folio — confirm the requesting phone number is authorized to view that record before passing it to the AI context.
• Review the provider’s data retention and processing policy — OpenAI, Google, and Meta each have policies governing how long API inputs are stored and whether they are used for training. Verify the current policy before each major version update.
• Document when a response is automated — if your terms of service or local regulation require transparency about automated decision-making, include a disclosure in the bot’s greeting or first message.

​

Webhook Security

• Use unguessable routes as a secondary defense only — a long, random path segment in the webhook URL reduces accidental discovery but is not a substitute for signature verification.
• Verify signatures or tokens — when the provider (Meta, Chatwoot) includes a signature header or shared secret, validate it in the first node of the workflow before processing the payload.
• Reject unexpected payloads — validate the structure and content type of every incoming request. Discard events that do not match the expected schema rather than attempting to process them.
• Limit size and frequency — configure rate limits and maximum payload sizes at the Caddy layer to prevent resource exhaustion from malformed or malicious requests.
• Do not log authorization headers — strip or omit Authorization and any token-bearing headers before writing request details to logs or n8n execution data.

​

Secrets Management

• .env must never be versioned — .env is listed in .gitignore and must remain there. Commit .env.example with placeholder values only.
• n8n workflow exports must be reviewed before every commit — exported JSON files can contain hardcoded credential values or environment variable names that expose configuration details.
• Never paste tokens into HTTP Request nodes — use n8n credentials or environment variables so values are encrypted at rest and excluded from exports.
• Rotate any secret that may have been exposed — if a secret was committed to Git, logged, or transmitted over an unencrypted channel, treat it as compromised and rotate it immediately.
• Keep N8N_ENCRYPTION_KEY outside the repository — this key protects all n8n credentials at rest. It must be stored in a secrets manager or injected via a secure CI/CD mechanism, never committed.

rg -n -i \
  'bearer |api[_ -]?key|secret|password|token|phoneNumberId|BEGIN .*PRIVATE KEY' \
  . \
  -g '!*.png' \
  -g '!.git/**'

​

Git History Hygiene