This page summarizes security controls WALO uses to protect business data, customer data, connected accounts, and automation workflows. No system is perfectly secure, but these controls describe our current operating approach.
WALO restricts administrative access to authorized personnel and service accounts that need access to operate or support the service. Access is intended to follow least-privilege principles. Sensitive operational actions are limited to trusted environments and accounts.
WALO is designed as a multi-tenant system. Business data is scoped by tenant/workspace so one business should not access another business's data. Database policies, application routing, tenant IDs, and owner authorization checks are used to separate customer records.
WALO uses authenticated sessions for dashboards and owner-gated endpoints. WhatsApp owner commands are restricted to approved owner phone numbers for each tenant. Sensitive commands are routed through owner-only paths instead of customer-facing concierge paths.
WALO requires HTTPS/TLS for web and API traffic. Cloudflare security headers are applied to reduce common browser risks, including HSTS, clickjacking protection, content sniffing protection, referrer controls, and content security policy controls.
API keys, OAuth client secrets, and service tokens are stored as platform secrets, not in public site files. Connected-account tokens are stored server-side and are encrypted at rest where WALO's token vault is used. OAuth scopes are kept as narrow as practical for the features enabled.
WALO is built around approval gates for sensitive actions such as sending customer-facing messages, changing DNS, applying email authentication records, committing code, changing connected accounts, scheduling events, or making deployment-related changes. The system should show what will change before applying actions that materially affect a business.
Production changes are developed, checked, and deployed through controlled tooling. Code changes are tested locally where practical before deployment. Deployment tools keep version IDs and logs so changes can be tracked and rolled forward or corrected.
WALO keeps operational logs and diagnostic events to troubleshoot errors, investigate abuse, verify deliveries, monitor automations, and support security review. Logs are intended to avoid exposing secrets and are retained only as needed for operations, security, and legal purposes.
WALO relies on infrastructure providers such as Cloudflare and database/storage providers for platform availability, redundancy, and backup capabilities. We design important workflows to fail closed where possible, especially around authentication, connected-account actions, and message sending.
We review security reports, dependency issues, exposed-secret risks, authentication failures, and data-access findings as they arise. If a secret is suspected to be exposed, the safe response is rotation and redeployment. If we identify a security incident affecting users, we will investigate and notify affected users as required by law.
Customers are responsible for keeping their own accounts secure, using strong passwords, protecting connected third-party accounts, limiting team-member access, reviewing AI outputs, maintaining required customer messaging consent, and promptly telling us about suspected unauthorized access.
WALO treats AI-driven automation as a controlled workflow, not a blank check. Users remain in control of connected apps, customer-facing outputs, code changes, DNS changes, payment actions, and public posting. Where available, WALO can limit which AI providers or app lanes are enabled for a workspace.
WALO workflows are designed to favor resilience, conservative retries, and clear failure states. Reliability depends partly on connected providers, but WALO should avoid silently losing work when a provider is slow, rate-limited, down, or changing an API.
WALO can support enterprise-style app controls when a workspace or owner needs stricter rules. These controls are designed to keep AI useful while limiting where it can read, write, send, or act.
Connected services such as Cloudflare, Google, Microsoft, Yahoo, GitHub, Vercel, Meta/WhatsApp, Stripe, Resend, Supabase, AI model providers, and browser verification tools are limited by OAuth scopes, provider permissions, stored-token controls, approval gates, and tenant separation where supported. Users can disconnect accounts or request token rotation when needed.
Public AMH network pages such as Nothing Unseen, Apiary, Service Pricer, SEO Grow, and public WALO articles may be used for source-backed research, public context, backlinks, examples, and AI-readable references. They are not private storage. Customer secrets, OAuth tokens, private customer data, approval receipts, and tenant logs should stay in controlled WALO systems or authorized provider accounts.
Please report suspected vulnerabilities, exposed credentials, unauthorized access, or abuse to [email protected]. Include the affected domain, endpoint, account email if relevant, and enough detail for us to reproduce or investigate.
Back to WALO