Security baseline

Security Practices

The operational security practices Chorus Local uses for accounts, workspaces, integrations, audit trails, secrets, and incident handling.

Last updated May 6, 2026

Security program

Chorus Local is built around workspace-scoped access, approval-first public workflows, role-based controls, auditability, and careful handling of integrations and billing events.

Security practices are designed to scale with the product and should be reviewed regularly as infrastructure, integrations, subprocessors, and customer requirements evolve.

Access controls

Private product endpoints require authentication and workspace-scoped authorization. Role-based access controls are enforced server-side for billing, approvals, publishing, integrations, settings, and team management.

Platform admin access is separate from customer workspace membership and is intended only for authorized internal operators.

Data protection

Chorus Local uses encrypted transport, managed database controls, object storage controls, secret management, and least-privilege access patterns. Sensitive tokens and credentials should not be exposed to client-side code.

Application hardening includes restrictive browser permission policy defaults, security headers, same-origin or approved-origin checks for mutating requests, server-side role checks, input validation, and DB-backed rate limits for analytics and feedback collectors.

Generated content, approvals, publish actions, billing events, integration events, exports, role changes, deauthorization callbacks, data deletion callbacks, and deletion actions should retain audit trails appropriate to the workflow.

Integrations and secrets

Integration credentials and provider tokens should be stored securely, scoped to the workspace, and used only for approved platform flows. Application-level provider secrets, including Stripe and Meta credentials, are stored in managed secret storage for deployed environments.

Unsupported automation and brittle scraping are not part of the approved security model. Google Business Profile actions should use Google's official OAuth and Business Profile APIs where supported. Facebook and Instagram actions should use Meta's official OAuth and Graph API flows, and sensitive public actions should preserve human approval or manual fallback paths.

Meta deauthorization and data deletion callbacks are verified with the app secret before matching provider identifiers are redacted or integrations are moved back into setup review.

Monitoring and incidents

Operational monitoring should cover application health, queue pressure, integration failures, billing webhooks, AI cost and latency, and unusual security events.

If Chorus Local identifies a security incident that materially affects customer data, it will investigate, contain, remediate, and notify affected customers as required by law and written agreements.

Customer responsibilities

Customers are responsible for using strong account practices, keeping workspace membership accurate, limiting admin and owner roles, reviewing public outputs, and promptly reporting suspected unauthorized access.

Reporting security concerns

Security concerns can be sent to legal@choruslocal.com. Include enough detail to help reproduce and investigate the issue.