Security Controls
Security controls and operational safeguards for PayCovay, LocalOps, BookITnow, and WALO command workflows.
This page summarizes practical controls used to protect accounts, connected services, customer data, and approved automation workflows. No system is perfectly secure, but sensitive paths are designed around least privilege and approval.
1. Access controls
Access is limited to authorized users and service processes. We use account authentication, role-based access where supported, owner-only command paths, least-privilege provider tokens, and connected-account permissions scoped to the workflow being performed.
2. Approval gates
High-impact workflows should preview changes before applying them. DNS changes, code commits, deploys, publishing, campaign sends, payment actions, connected-account changes, and destructive operations should require explicit approval unless the account owner intentionally configures automation.
3. Secrets and token handling
API keys, OAuth secrets, refresh tokens, Stripe keys, database strings, and Cloudflare tokens should be stored in encrypted secrets or provider-managed environment variables. Secrets must not be committed to source control, pasted into public pages, logged, or included in generated site bundles.
4. Tenant separation
Customer and workspace data should be separated by tenant, workspace, or owner identifiers. Backend policies and service checks should prevent one account from reading or writing another account's data.
5. Connected providers and AI processors
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.
6. Security in transit
Public pages, dashboards, API calls, callbacks, and authentication flows use HTTPS/TLS. Sensitive tokens should never be sent over plain HTTP.
7. Change management
Material production changes should be tested, reviewed, and recorded through deploy logs, commit history, audit records, or task records. Rollback paths should be available for production pages, DNS, payments, authentication, or campaigns.
8. Monitoring and logging
Provider logs and application logs are used to diagnose errors, failed authentications, suspicious access, integration failures, and delivery issues. Logs should avoid storing full secrets or unnecessary personal data.
9. Backups and recovery
Critical data should be backed up through the database or hosting provider. Recovery depends on the specific provider and plan used for the product or customer workspace.
10. Responsible testing
Security, DNS, mail, SMTP, search, and website diagnostics should be run only against domains, systems, and accounts you own or are authorized to test.
11. Reporting security issues
Report suspected security issues to pain2hustle1@gmail.com. Do not include secrets in email unless we specifically request a secure exchange method.