> For the complete documentation index, see [llms.txt](https://musenai.gitbook.io/musenai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://musenai.gitbook.io/musenai/community-and-trust/security-policy.md). # Security Policy Version 4.0.0 | Effective 4 September 2026 Canonical address:

Security is an ongoing responsibility, not a guarantee.

This policy describes the controls and commitments that are supportable today. It deliberately avoids exposing defensive mechanics or claiming certifications, testing coverage or operational maturity that have not been verified.

| Service operator | Fabio Senna | | ------------------ | ---------------------------------------- | | Trading name | musen | | Operator address | 483 Green Lanes, N13 4BS, United Kingdom | | Security contact | | | Privacy controller | Fabio Senna | ## 1. Purpose, scope and status This Security Policy explains the approach taken to protect the current public musen service and the information processed through it. musen is a trading name operated by Fabio Senna. musen is not a separate legal entity. The operator identity and contact details in this Policy match the musen Privacy Policy and Terms and Conditions. The current public consumer service is an authenticated Live Radio service available through the musen applications for iPhone and Android. An internet connection is required. The current service allows people to make Requests using text, recorded speech or a picture. It may also provide optional synthetic AI Host speech between existing recordings and jingles. musen does not currently provide public generated music. The production website currently provides marketing, policy and support information. This policy does not describe it as a generally available web version of the authenticated consumer application. Dormant, experimental or future AI DJ, Segment, creator, payment, social, public broadcasting, developer and enterprise functionality is not described as currently available merely because code or technical architecture exists. This public policy does not disclose confidential architecture, catalogue information, rights information, evidence systems, Runtime mechanisms or defensive control mechanics. This policy is intended to provide meaningful transparency. It does not guarantee absolute security, uninterrupted availability or immunity from every incident. ## 2. Security principles and governance We take a risk based approach to protecting the confidentiality, integrity and availability of the service and the information processed through it. Security measures are selected with regard to the nature of the service, the information involved, reasonably foreseeable threats, implementation costs, current technical capabilities and applicable legal requirements. Our security programme is informed by the outcome based structure of the NIST Cybersecurity Framework 2.0 and relevant OWASP application and mobile security guidance.

No certification claim

These references do not mean that the service is certified under those frameworks, has completed an independent audit against them, conforms to every control or has reached a particular maturity tier.

Security is an ongoing engineering and governance responsibility. We review and improve controls as the service, threats, suppliers, processing activities and legal requirements change. · Understand the systems, information, suppliers and risks relevant to the current service. · Apply proportionate safeguards to accounts, applications, infrastructure and information. · Detect and assess potentially harmful activity. · Respond to and contain security incidents. · Restore affected services and learn from incidents where appropriate. · Limit access and information use to legitimate operational purposes. · Avoid public claims that exceed verified implementation. ## 3. Identity, authentication and access control ### 3.1 User authentication Access to the current consumer service is tied to an authenticated account. The applications support account credentials and supported external sign in providers. Authentication methods may change as the service evolves. Session credentials are sent to service endpoints using bearer authentication. On supported mobile platforms, authentication tokens and relevant account state are stored using operating system protected storage. Sessions may be refreshed. Invalid, rejected or expired sessions may be ended, and users may be required to authenticate again. We do not publish the precise structure, lifetime, signing method, validation logic, refresh conditions or revocation mechanics of authentication credentials. ### 3.2 Administrative and service access Administrative and service access is intended to be limited to authorised people and systems according to operational need. Permissions, secrets and privileged access methods vary across the systems and service providers used by musen. We do not claim that one role model or one technical access mechanism applies universally. Access should be granted according to the function being performed, reviewed when responsibilities change and removed when it is no longer required. We maintain records for relevant privileged accounts and service identities, including ownership and operational need, and apply offboarding, access review and stronger authentication controls for relevant administrative accounts according to system capability and risk. ### 3.3 Secrets Secrets used for deployment and service operation should be kept outside application source where the relevant platform supports that approach and supplied through controlled deployment or service provider facilities. Public documentation does not identify secret names, locations, values, rotation schedules, emergency access methods or recovery procedures. No statement in this policy means that every system uses the same secrets manager, key management service or rotation mechanism. ## 4. Application and mobile security The musen applications use security and privacy functions provided by iOS and Android where appropriate. · Platform permission mechanisms are used for functions such as microphone access, speech recognition, camera access, photo selection, notifications and tracking related choices. · Android application configuration disables cleartext network traffic for the application. · iOS App Transport Security configuration does not allow arbitrary network loads. · Authentication tokens and relevant account state use protected device storage on supported mobile platforms. · Device capabilities are intended to be requested when needed for a relevant feature, with user controls remaining available through platform settings. Requests may contain text, recorded speech converted for use as a Request, or a picture. These inputs may pass through musen service boundaries and specialist service provider boundaries. Their purposes, recipients and data processing terms are governed by the Privacy Policy and match verified production behaviour. Mobile security design is informed by relevant areas of the OWASP Mobile Application Security Verification Standard, including storage, cryptography, authentication, network communication, platform interaction, code, resilience and privacy. This does not constitute a claim that the applications have completed formal MASVS verification or satisfy every MASVS control. ## 5. Infrastructure, network and data protection ### 5.1 Encryption in transit We use HTTPS and other encrypted transport mechanisms for supported connections between musen applications, websites and service endpoints. Reviewed configuration includes HTTPS termination for relevant deployment components, secure WebSocket configuration, disabled Android cleartext traffic and restricted iOS transport settings. Some communications are handled by third party platforms under their own security controls. Different media delivery paths, internal service connections and provider connections may use controls appropriate to their context, so this policy does not make a universal claim about every transmission path. No internet transmission method is completely secure. This policy does not claim end to end encryption. ### 5.2 Stored information and encryption at rest Stored information is protected using access controls and the storage protections made available by the relevant platform or service. Encryption at rest may be applied by the service operator or by service providers, depending on the system, provider, configuration and type of information involved. We do not claim that every item is encrypted at rest, that every item uses a separately managed key or that all encryption keys are exclusively controlled by the service operator. Encryption and key responsibility are recorded internally for relevant production datastores, object stores, device stores, log stores and backup systems. Public documentation does not disclose confidential key identifiers, locations or operational handling. ### 5.3 Network and infrastructure protection Infrastructure and service boundaries are configured according to operational need and risk. Network boundaries, host configuration, traffic controls, service isolation and defensive settings are confidential operational information. Current evidence does not support a public claim that every system uses formal network segmentation, a particular firewall architecture, universal traffic filtering or a uniform rate limiting system. Any public statement about these controls remains general unless the relevant control has been verified across the full scope to which the statement applies. ## 6. Secure development, change and dependency management Code is maintained in version controlled repositories. Reviewed repository configuration includes automated tests and linting for parts of the system, static analysis for common Rails security vulnerabilities, dependency vulnerability checking and automated dependency update proposals for one reviewed backend service. Reviewed deployment workflows use scoped repository permissions, controlled secret inputs and deployment environments. These controls are not currently evidenced as uniform across every repository and component. We use version control, automated tests and security checks in parts of the development and release process. Reported and detected vulnerabilities are assessed according to risk and remediation is prioritised accordingly. Exact checks vary by component.

What this policy does not claim

We do not claim that every change receives independent peer review, every dependency is continuously scanned, every vulnerability is corrected immediately, every release passes the same security gate, every repository has equivalent automated coverage or every system follows one universal patch deadline.

Patches and dependency updates may require testing, compatibility assessment, service provider action or coordinated deployment. Remediation priority should consider exploitability, exposure, affected information, service impact and available mitigations. ## 7. Logging, monitoring and abuse resistance We collect operational, diagnostic, security and usage information needed to operate, troubleshoot, understand and protect the service. Reviewed configuration includes application logging with request identifiers, filtering of common sensitive parameter names, crash reporting through Sentry, and analytics and measurement integrations described in the Privacy Policy. Logs and diagnostic records may contain account, device, network, event, request or error context. Access and retention should be limited according to purpose, risk and applicable obligations. · Investigate errors and service failures. · Identify potentially unauthorised or abusive activity. · Protect accounts, systems and service availability. · Investigate security reports and incidents. · Meet legal and accountability requirements. · Improve the reliability and security of the service. We do not publicly disclose exact event schemas, alert thresholds, detection rules, investigation queries, rate limits, block lists, traffic fingerprints, response triggers or evasion indicators. This policy does not claim continuous human monitoring, universal real time alerting, comprehensive intrusion detection or immediate detection of every incident. ## 8. Third party and supply chain security We rely on third parties for functions that may include cloud hosting, authentication, analytics, crash reporting, advertising measurement, AI processing, speech processing, vision processing and mobile application distribution. The exact providers, roles, processing locations, subprocessor status and production configurations are maintained in an internal provider register and aligned with the musen Privacy Policy and verified production systems. Service providers are selected and managed with regard to the nature of the service, the information involved and the risks presented. Where appropriate, we consider contractual terms, security information, privacy commitments, access scope, incident obligations, deletion arrangements and available assurance materials. Third party services remain responsible for the security of their own systems. The service operator remains responsible for provider selection, configuration, access decisions, information sharing decisions, contractual and regulatory duties, and response to incidents affecting the musen service. No supplier assessment can guarantee that a provider will never experience a vulnerability, outage or security incident. This policy does not transfer all responsibility to service providers and does not exclude responsibility merely because an incident originated in a third party system. ## 9. Incident response, breach handling and recovery We maintain procedures to assess, contain, investigate and remediate suspected security incidents, preserve relevant information, coordinate with affected service providers and restore service where appropriate. The response depends on the nature, scope, severity and impact of the event. Measures may include restricting access, ending sessions, rotating credentials, changing configuration, isolating affected components, preserving evidence, notifying providers, correcting vulnerabilities and communicating with affected parties. When an incident involves personal data, the responsible controller assesses notification duties under applicable law.

GDPR breach timing

Where the GDPR applies, an eligible personal data breach is notified to the competent supervisory authority without undue delay and, where feasible, within 72 hours after the controller becomes aware of it, unless the breach is unlikely to result in a risk to people's rights and freedoms. High risk breaches are communicated to affected people without undue delay where required by law.

Information may be provided in phases where permitted and where complete information is not available at the same time. The controller documents personal data breaches as required by applicable law. This wording does not mean that every security event is a personal data breach, that every personal data breach requires notification or that every relevant fact will be known within 72 hours. ## 10. Backups, recovery and availability We seek to restore affected services and information where appropriate following operational or security incidents. The use, scope and configuration of backups and other recovery mechanisms may differ by system and provider. We do not currently make a public commitment to a specific recovery time objective, recovery point objective or guaranteed level of availability. We do not claim that every system is backed up, that every backup is independently encrypted, that every restore path has been tested or that recovery will always be possible without loss or delay. Any future public recovery objective will be supported by documented system coverage, backup frequency, retention, access controls, encryption responsibility, restoration procedures and appropriate restoration testing. ## 11. Data retention and deletion interaction Security related records are retained only for as long as reasonably needed for their operational, security, legal and accountability purposes, subject to system capabilities and applicable retention requirements. Account deletion and other privacy rights may not require immediate deletion of narrowly retained security, fraud prevention, legal or incident records where continued retention is permitted or required. Information may remain temporarily in backups, provider systems or technical logs according to applicable deletion cycles and system capabilities. Exact retention periods, deletion behaviour, backup retention and provider deletion windows align with the Privacy Policy and verified production systems. A general statement that retention is limited is not a substitute for an internal retention schedule, assigned ownership and functioning deletion procedures. ## 12. Vulnerability reporting and good faith research ### 12.1 Reporting a security concern If you believe you have found a security vulnerability affecting the current public musen service, please report it to . Please include, where reasonably possible: · The affected application, endpoint or service. · A clear description of the suspected vulnerability. · Reproducible steps or a limited proof of concept. · The potential impact. · Relevant dates, versions and technical context. · Your contact details if you want a response. Do not include unnecessary personal data, credentials or confidential information belonging to other people. ### 12.2 Good faith research expectations To remain within this policy, researchers should: · Test only the current public musen service and accounts or information they are authorised to use. · Make a good faith effort to avoid privacy harm, information loss and service disruption. · Stop testing and report promptly if personal data, credentials or confidential information are encountered. · Access only the minimum information needed to demonstrate the issue. · Avoid modifying, copying, retaining or sharing information that is not their own. · Give the service operator reasonable time to investigate and remediate before public disclosure. · Comply with applicable law. Researchers must not: · Conduct denial of service or resource exhaustion testing. · Use automated high volume scanning. · Degrade service performance or availability. · Conduct social engineering, phishing or physical security testing. · Test third party systems that are not operated by the service operator. · Introduce malware or persistent access. · Alter or delete other people's information. · Access accounts without authorisation. · Use extortion, threats or demands for payment. · Publicly disclose an unresolved issue before a reasonable remediation period has passed. ### 12.3 Safe harbour If you conduct research in good faith, follow this policy, avoid privacy harm and service disruption, and give us reasonable time to investigate and remediate, we will not initiate legal action against you solely for that research. This commitment does not authorise conduct prohibited by law, access to third party systems, demands for payment or activity outside this policy. If you are unsure whether a test is permitted, contact us before proceeding. This safe harbour applies only to claims that the service operator has authority to control. It cannot bind third parties or prevent independent action by regulators, law enforcement or other rights holders. ### 12.4 No bug bounty musen does not currently operate a formal bug bounty programme. Submitting a report does not create a right to payment, reward, employment, contract or public acknowledgement. Any future bounty programme will be governed by separate published terms. ### 12.5 Response expectations We aim to acknowledge credible reports, assess their scope and risk, and communicate when it is reasonable and safe to do so. We do not promise a particular response or remediation time unless a separate published programme specifies one. We may limit information shared about an investigation where disclosure could create security, privacy, legal or operational risk. ## 13. User security responsibilities Users should take reasonable steps to protect their accounts and devices. · Protect devices and account credentials. · Use a strong, unique password where password login is available. · Keep the musen application and device operating system current. · Review unexpected authentication or account activity. · End sessions or change credentials if compromise is suspected. · Contact musen promptly about suspected unauthorised account access. · Avoid sharing session credentials or authentication links. · Avoid attempting to bypass or interfere with service protections. The service operator is not responsible for security choices that only a user or device operator can control. This does not reduce duties that remain with the service operator under applicable law. ## 14. Limits, transparency and confidential disclosure boundary ### 14.1 Limits No technical or organisational measure can eliminate all risk. Security depends partly on third party platforms, user devices, telecommunications networks, service providers and evolving threats. This policy describes our approach at a high level. It does not guarantee that an incident, outage, information loss or unauthorised access will never occur. We do not use broad phrases such as industry standard security as a substitute for identifying supported controls. We do not claim certification, audited framework conformance, penetration testing, continuous security operations, zero trust architecture, end to end encryption, universal data residency, tamper proof logging, tested recovery objectives or guaranteed availability without current evidence. ### 14.2 Information that may be disclosed publicly · The scope of the current public service. · High level security principles. · Supported authentication methods in general terms. · Use of encrypted transport in qualified terms. · Use of protected mobile storage. · General secure development practices that have been verified. · General categories of logging and monitoring. · General provider governance principles. · Incident and personal data breach response obligations. · Vulnerability reporting rules and approved safe harbour terms. · User security responsibilities. · Meaningful limitations on all of the above. ### 14.3 Information that must remain confidential · Administrative account names, identities or access paths. · Exact privilege assignments or role mappings. · Authentication signing, validation, refresh or revocation mechanics. · Token formats, lifetimes, claims or trust relationships. · Secret names, values, locations, rotation schedules or recovery methods. · Cryptographic keys, key identifiers, ownership mappings or emergency access procedures. · Network diagrams, addresses, ports, provider account identifiers or topology. · Firewall rules, service exposure maps or segmentation boundaries. · Precise rate limits, abuse thresholds, throttling behaviour or bypass conditions. · Detection rules, alert thresholds, block lists, traffic signatures or investigation queries. · Log schemas that reveal defensive coverage or sensitive information flows. · Vulnerability inventories, unresolved findings or exploit details before remediation. · Incident severity thresholds, internal escalation paths, responder contact details or playbook steps. · Backup locations, credentials, restoration commands or access paths. · Runtime, scheduling, orchestration or internal service control mechanics. · Patent sensitive architecture, radio computation, rights enforcement, catalogue, evidence or attribution mechanisms. · Supplier credentials, private contract terms or nonpublic assurance materials. · Security testing tools, timing, targets or methods where disclosure would weaken controls. · Any information whose disclosure could materially assist unauthorised access, evasion, disruption, reverse engineering or rights circumvention. Confidential details may be shared selectively with authorised personnel, service providers, auditors, insurers, counsel, regulators or affected parties where there is a legitimate need, appropriate authority and suitable confidentiality protection. ## 15. Relationship to other policies, contact and changes The musen Privacy Policy explains personal data processing, recipients, rights, retention and controller information. The musen Terms and Conditions identify the service operator and set the contractual conditions for using the service. This Security Policy explains the security approach applied to the current service. If these documents conflict on legal rights or obligations, the Terms and Conditions, Privacy Policy and applicable law govern. | Service operator | Fabio Senna | | ------------------------ | --------------------------------------------- | | Trading name | musen | | Operator address | 483 Green Lanes, N13 4BS, United Kingdom | | Security contact | | | Privacy controller | Fabio Senna, see | | Canonical policy address | | We may update this policy as the service, risks, controls, suppliers or legal requirements change. Material changes will be dated and published at the canonical policy address.

Closing statement

Security is an ongoing responsibility, not a guarantee. We assess risks, improve protections as musen evolves, work with service providers and respond to credible reports and incidents. We publish meaningful information about our approach while keeping defensive details confidential so that transparency does not weaken the service.