Security at Msasa

Security overview

• Cloud-only: Msasa does not operate an on-premises datacenter.
• Least privilege: We restrict access to systems and data based on role and business need.
• Defense in depth: Edge protections, strong authentication, secret management, and continuous monitoring are used across the stack.
• Customer control: You choose which integrations to connect and what data is processed by enabled features.

Architecture and data flow

Msasa uses the following high-level architecture:

• Frontend: Hosted web application for customer access.
• Core platform services: Managed authentication, database, and application APIs.
• Additional processing services: Cloud-based compute used where required.

Internal services are segmented from customer-facing interfaces. Where additional internal processing is required, it is handled through controlled service-to-service communication rather than direct end-user access.

Edge protection and service resilience

Msasa relies on managed protections in front of internet-facing services:

• Customer-facing services are delivered behind managed edge and network protections.
• We use provider-level controls designed to help reduce abuse, unauthorized access attempts, and service disruption.
• Internal services that do not need direct public access are not exposed as public endpoints.

Encryption

• In transit: TLS is used for data transmission between clients, APIs, and third-party integrations.
• At rest: Data stored in managed cloud services is encrypted at rest using cloud-provider controls.

Identity and access management

• Authentication: End-user authentication and session management are handled through managed identity services.
• Authorization: Access to data is scoped by workspace and enforced by backend authorization checks to ensure users only access data for workspaces they belong to.
• Internal access controls: Administrative access to production systems is restricted to authorized personnel and protected by strong authentication methods.

Secrets and key management

• No secrets in code: Credentials and API keys are not committed to source control.
• Centralized secret storage: Production secrets are stored in managed secret and configuration systems with access limited to authorized services and personnel.
• Deployment credentials are managed to reduce long-lived secret exposure where supported by our providers and tooling.

Secure software development lifecycle (SDLC)

Msasa follows a version-controlled software development lifecycle:

• Changes are developed on feature branches and merged via pull requests.
• Pull requests undergo review before release.
• Automated testing and validation checks are used where relevant.
• Deployments are performed through controlled release workflows.
• Changes to infrastructure and application configuration follow review and change management practices aligned with the rest of the platform.

Logging and monitoring

• Service logs and metrics: We use managed logging and monitoring capabilities across our application and infrastructure providers.
• Platform logs: Managed platform components provide service-level operational visibility.
• Logs are used to support operational troubleshooting, performance monitoring, and security investigations.

Sub-processors

Msasa uses vetted sub-processors to provide infrastructure, integrations, and AI capabilities. See: Sub-Processors (legal/subprocessors).

Incident response

Msasa maintains an incident response process to triage, contain, and remediate security incidents. Where required by law or contract, we will provide customer notifications consistent with our obligations.

Vulnerability reporting

If you believe you have found a security vulnerability, please email security@msasa.ai with details. We will acknowledge receipt and work to validate and remediate issues in a timely manner.