Testen
Rechtliches

Security Policy

Dieses Dokument ist nur auf Englisch verfügbar.

Gültig ab
February 11, 2026
Zuletzt aktualisiert
November 5, 2026
Inhalt
  1. 1. About This Policy
  2. 2. Infrastructure Security
  3. 3. Data Encryption
  4. 4. Access Controls
  5. 5. Application Security
  6. 6. AI Security
  7. 7. Incident Response
  8. 8. Data Protection
  9. 9. Vendor Security
  10. 10. Payment Security
  11. 11. Reporting Security Issues

1. About This Policy

This Security Policy describes the main measures DA592 LTD, trading as Masheev uses to protect the Services and the data processed through them. It describes what we do today. Annex II of our Data Processing Addendum sets out the measures we commit to contractually. We review these measures as the Services and the threats to them change.

2. Infrastructure Security

  • Hosting and DDoS protection: The web application and API run on Cloudflare Workers, behind Cloudflare's network protection. Application authentication, authorization, input validation and rate limits sit on top of that protection.
  • Databases: Application data is held in managed PostgreSQL databases on PlanetScale, in the EU (Frankfurt) and the US (Northern Virginia), according to each organization's region. The billing service (Lago) runs separately on Railway with its own database.
  • Provider certifications: Our infrastructure providers hold their own security certifications for their own services. Those certifications do not certify Masheev.
  • Internal connections: Internal services connect through private service bindings where the platform supports them, and to external providers over authenticated connections. Network location alone never grants access to the application.

3. Data Encryption

  • In transit: Connections from your browser, app or API client to the Services use TLS 1.2 or higher, and we serve the websites and API over HTTPS only. Phone calls, SMS and email also travel over carrier and email networks that we do not control.
  • At rest: Our database and file storage providers encrypt data at rest. Files are stored in Cloudflare R2, and organizations in the EU region use EU-jurisdiction storage.
  • Database connections: The application connects to its databases over TLS with certificate verification.
  • Credentials for connected services: Access tokens for services you connect, such as Google, Microsoft, Notion and Atlassian, are encrypted before we store them.
  • Limits: This is not end-to-end encryption. The Services read your data in order to provide them, for example to show conversations to your team and to generate AI replies.

4. Access Controls

  • Roles: Application roles limit which organization data and administrative functions each user can reach, and the server checks authorization on every sensitive operation.
  • Least privilege: We give staff only the access their role needs, and remove it when the role changes or ends.
  • Multi-factor authentication: Masheev system-administrator actions require a verified second factor. Users in your organization can turn on multi-factor authentication for their own accounts.
  • No browsing of your conversations: The application has no feature that lets Masheev staff browse your conversations. Support, security and legal access to Customer Data is limited to what a specific case needs, as described in our Data Processing Addendum.

5. Application Security

  • Review: Security-sensitive changes are reviewed and tested before release.
  • Automated checks: Our release pipeline runs static analysis, dependency checks and scans of release images for known vulnerabilities. We fix findings according to their severity.
  • Input handling: We use schema validation, parameterized database queries and framework output encoding to reduce risks such as SQL injection and cross-site scripting.
  • Limits: Reviews and automated checks reduce risk. They do not find every defect.

6. AI Security

  • Prompt injection: We use layered controls to reduce the risk that messages from the people your AI agents talk to change how the agents behave. These include separating instructions from untrusted content, limiting the tools and data each agent can use, and checks on what agents send. No control prevents prompt injection completely (Terms of Service Section 5.4(j)).
  • Output safeguards: AI replies pass through safeguards designed to reduce harmful, inappropriate or misleading content. You remain responsible for reviewing how your agents behave.
  • Provider review: Before an AI provider processes Customer Data, we review the service, its account settings, its retention and its contract terms.
  • No model training: We do not use Customer Data to train AI models, and we do not authorize our providers to do so where their contracts or settings give us that control.
  • Abuse prevention: AI features are protected by rate limits and abuse detection.

7. Incident Response

  • Plan: We have a documented incident response plan that sets out roles, escalation and communication.
  • Notifying customers: When we act as processor, we notify affected customers of a Personal Data Breach affecting their Customer Data without undue delay and, where feasible, within 48 hours of becoming aware of it, and we share more information as the investigation develops (Data Processing Addendum Section 10).
  • Notifying regulators and individuals: When we act as controller, we notify regulators and affected people where the law requires, including within 72 hours to the ICO where UK law requires it.
  • Review: After a significant incident we review its causes and our response, and make changes to prevent it happening again.
  • Monitoring: We monitor the application and our providers for errors and unusual activity. Monitoring helps us detect incidents but cannot guarantee that every incident is detected.

8. Data Protection

  • Privacy commitments: Our Privacy Policy and Data Processing Addendum describe our roles as controller and processor, how we handle rights requests, and our transfer safeguards.
  • Minimization and purpose limitation: We collect and process personal data for specified purposes and limit what we collect where we can.
  • Impact assessments: We assess whether high-risk processing needs a data protection impact assessment before we start it.
  • Data residency: Each organization chooses an EU or US region for its application database and file storage. Some processing happens outside that region, as explained in Privacy Policy Section 9.3.

9. Vendor Security

  • Due diligence: Before a vendor processes Customer Data, we review its security, data handling and contract terms.
  • Contracts: Every sub-processor of Customer Data is bound by written data protection terms, and transfers from the UK use the safeguard shown on our Sub-Processor List.
  • Monitoring: We keep the Sub-Processor List current and review providers when their services, terms or certifications change.

10. Payment Security

Payment details entered in the web billing form are collected by Stripe's Payment Element. The application uses payment-method identifiers and limited card metadata, such as brand, expiry and last four digits, to manage billing. Do not send full card numbers, security codes or banking credentials through chat, email, uploads or support requests.

Stripe's provider certification does not certify Masheev. Merchant PCI DSS scope and validation depend on the complete payment integration and the requirements of the payment processor or acquirer. This policy makes no claim that Masheev holds a PCI certification, SOC 2 report or ISO 27001 certification. Customers must not collect payment card numbers through conversations, calls or uploads (Acceptable Use Policy Section 7.2); payments should be taken through the payment provider's own secure page or link.

11. Reporting Security Issues

We value the contributions of the security research community and encourage responsible disclosure of any security vulnerabilities discovered in our Services.

  • Responsible Disclosure: If you discover a potential security vulnerability, please report it to us as soon as possible. We ask that you give us reasonable time to investigate and address the issue before making any public disclosure.
  • Contact: Please report security issues to: security@masheev.com
  • Security metadata: Our machine-readable disclosure details are available at /.well-known/security.txt.

Scope and safe harbour

This policy covers Masheev-owned production services and applications at masheev.com and its subdomains. Third-party services, customer-managed systems, social engineering, physical attacks, denial-of-service or load testing, automated scanning that degrades the Services, and accessing, modifying, retaining, or deleting another person's data are outside scope.

We will not initiate legal action against researchers who act in good faith, comply with this policy, use only accounts and data they own or have explicit permission to test, stop when they encounter customer data, avoid privacy violations and service disruption, and give us a reasonable opportunity to remediate before publication. This safe-harbour statement does not authorize conduct that violates applicable law or third-party terms, and it does not bind third parties.

What to include in a report

Please include the affected URL or component, a concise description and impact assessment, reproducible steps or a minimal proof of concept, relevant timestamps, and a safe way to contact you. Do not include access tokens, passwords, payment-card data, unnecessary personal data, or copies of customer content. Encrypt sensitive supporting material before sending it and coordinate the transfer method with us first.

Severity and response targets

We classify reports by their demonstrated impact and exploitability:

  • Critical: Active or readily exploitable compromise causing broad unauthorized access, remote code execution, authentication bypass, or material cross-tenant data exposure.
  • High: Significant unauthorized access, privilege escalation, or sensitive-data exposure with meaningful prerequisites or limited scope.
  • Medium: Security impact requiring substantial prerequisites, user interaction, or affecting non-sensitive data or a constrained component.
  • Low: Defense-in-depth weakness or limited issue with no demonstrated direct compromise.

We target acknowledgment of critical and high reports within 1 business day and all other reports within 3 business days. After validation, we target remediation or an effective mitigation within 7 calendar days for critical findings, within 30 calendar days for high findings, and within 90 calendar days for medium findings. Low findings are prioritized in the normal security backlog. These are operational targets rather than guarantees; a safe resolution may require coordinated vendor or customer work. We will provide the reporter with progress updates when a target changes.

If you have general security questions or concerns, please contact us at security@masheev.com.