Security Policy

Version 1.0  ·  Last Updated: 17 August 2026  ·  Effective: 17 August 2026

1. Purpose and Scope

1.1. This Security Policy describes the technical and organisational measures we use to protect the confidentiality, integrity and availability of data processed through the Maromel platform.

1.2. What it covers. Account and billing data; Configuration Data; OAuth access and refresh tokens for Connected Accounts; and Interaction Content — the reviews, ratings, comments, mentions and direct messages received from Google Business Profile, Facebook, Instagram and Messenger, together with the replies generated in response. It applies to the platform, the Dashboard, our APIs and our automation infrastructure.

1.3. This Policy supplements, and does not replace, our Privacy Policy, our Data Processing Agreement and our Terms of Use. Annex 2 of the DPA is the contractually binding statement of our security measures; where this Policy and Annex 2 differ, Annex 2 governs.

2. Governance

2.1. Ownership. Responsibility for security sits with the Company's management. We are a small team, and security decisions are not delegated to an outsourced function.

2.2. Alignment. Our controls are designed with reference to the OWASP Top 10, the OWASP Top 10 for LLM Applications, and the security obligations that apply to us under the EU and UK GDPR, the Israeli Protection of Privacy Law, 5741-1981 and the Protection of Privacy Regulations (Data Security), 5777-2017, the Meta Platform Terms and Developer Policies, and the Google API Services User Data Policy. Designing with reference to a framework is not the same as being certified against it — see Section 18.

2.3. Israeli data security regulations. We maintain the documentation required of a database holder under the 5777-2017 Regulations, including the database definition document, the information security procedure, systems mapping, the access register and the incident register.

2.4. Review. This Policy and the underlying controls are reviewed at least annually and after any material change to the Service or any significant security incident.

3. Encryption

3.1. In transit. All connections — between you and the Dashboard, between our systems and the Supported Platform APIs, and between our systems and our AI provider — use TLS 1.2 or above.

3.2. At rest. Databases, object storage and backups are encrypted at rest using AES-256.

3.3. Secrets. OAuth access and refresh tokens, API keys and other secrets are held in a dedicated secrets manager with key management separate from the application. They are never written to source code, configuration files, application logs or error reports, and are never rendered in the Dashboard or returned by our APIs.

4. Tenant Isolation and Data Minimisation

4.1. Isolation. Each customer's data is logically separated, and tenant-scoped authorisation is enforced on every request. There is no code path by which one customer's Connected Account data, Configuration Data or Interaction Content can be reached from another customer's session.

4.2. Scope minimisation. We request only the platform permission scopes required for the channels you enable, and automation is activated per channel rather than globally.

4.3. Minimisation before AI processing. What we send to our AI provider is limited to the text of the item being answered and your Configuration Data. We do not transmit access tokens, billing data, the data of any other customer, or End User platform identifiers. See Section 7.2 of the Privacy Policy.

4.4. What we never collect. We do not request or receive End Users' email addresses, phone numbers, contact lists, location history or advertising identifiers.

5. Connected Accounts and Token Security

5.1. OAuth only — we never see your platform passwords. Connections are established exclusively through the official OAuth flows of Google, Facebook and Instagram. We do not ask for, receive or store your passwords for those platforms, and we cannot recover them.

5.2. Token handling. Tokens are encrypted at rest as described in Section 3.3 and are used solely to perform the actions you have configured.

5.3. Revocation. You may revoke access at any time from the Dashboard or from the platform's own settings. On disconnection we revoke the token with the platform immediately, stop all retrieval and publication on that channel, and delete the stored token within seven (7) days.

5.4. Webhook integrity. [CONFIRM BEFORE PUBLISHING — only keep this clause if you actually verify signatures] Inbound platform events are authenticated by validating the provider's payload signature (for Meta, the X-Hub-Signature-256 header computed with the app secret) before any processing occurs. Requests that fail verification are rejected and logged.

6. Access Control and Authentication

6.1. Least privilege. Access to production systems is limited to personnel who need it, granted on a least-privilege basis, reviewed at least quarterly, and revoked promptly on role change or departure.

6.2. Administrative access. Multi-factor authentication is mandatory for all personnel with production access.

6.3. Your account. We enforce password strength requirements and rate-limit authentication attempts. Passwords are never stored in plain text; they are stored only as salted cryptographic hashes. [CONFIRM: if MFA is available to customers, say so here; if not, delete this sentence rather than implying it] Multi-factor authentication is available for customer accounts and we recommend enabling it.

6.4. Sessions. Dashboard sessions use secure, HTTP-only cookies with CSRF protection and automatic expiry.

7. Human Access to Customer Content

7.1. We apply a deliberately stricter rule to private messages than to public content.

7.2. Every access is logged. Each read of Interaction Content is recorded with the identity of the accessing person and the reason for access. Those logs are retained for twelve (12) months and are available to you on request.

7.3. Personnel with access are bound by written confidentiality obligations that survive the end of their engagement, and receive privacy and security training at onboarding and at least annually.

8. AI and Automation Security

8.1. All End User content is untrusted input. Reviews, comments and messages arrive from the public and are treated as hostile by default. We separate system instructions from End User content, constrain the shape of model output, and apply filters to reduce the risk of prompt injection and manipulation. These are mitigations, not guarantees — prompt injection is an open problem across the industry and we do not claim to have solved it.

8.2. The AI Agents cannot reach anything sensitive. They have no access to payment instruments, platform passwords or raw access tokens, and cannot change billing, security or permission settings. Their only privileged action is publishing or sending a reply on the channels you enabled.

8.3. Guardrails and escalation. The Service applies configurable content filters and escalation rules, described in Section 12 of the Privacy Policy. They are probabilistic and will produce both false positives and false negatives; they do not replace your own oversight.

8.4. Rate limiting and anomaly detection. Automated activity is rate-limited and monitored for abnormal patterns, such as an unusual spike in outbound message volume, to protect both our systems and your Connected Accounts from being flagged by a platform.

8.5. You keep the controls. You can pause all automation instantly, per channel or globally, and switch any channel to Review & Approve Mode so that nothing is published without a human approving it.

8.6. No model training on your data. We do not use Interaction Content, Configuration Data, AI input, AI output, or any data obtained from Meta or Google APIs to train, fine-tune, retrain, benchmark or otherwise develop any generalised or foundation AI or machine-learning model, whether our own or a third party's. This applies without exception, including to anonymised, pseudonymised or aggregated derivatives. There is no consent mechanism by which this can be switched on.

9. Secure Development

9.1. Peer code review before merge; dependency and secret scanning in continuous integration; static analysis; and separated development, staging and production environments with no production data in lower environments.

9.2. Dependencies are patched on a risk-prioritised basis, with critical security updates applied promptly.

9.3. We prioritise the vulnerability classes in the OWASP Top 10 and the OWASP Top 10 for LLM Applications, with particular attention to prompt injection, insecure output handling, and excessive agency — the three that matter most for a product that publishes text autonomously.

10. Infrastructure and Sub-processors

10.1. We do not operate our own physical infrastructure. The Service runs on managed cloud platforms, and we rely on their physical, environmental and network-layer controls. The current list is:

10.2. Each is engaged under a data processing agreement with obligations no less protective than those we owe you. We assess a provider's security posture before engaging it and give you thirty (30) days' notice before adding or replacing any sub-processor that handles Interaction Content.

10.3. Meta and Google are not sub-processors. They are independent controllers for their own platforms.

10.4. Because all four providers are in the United States, international transfers are governed by the mechanisms in Section 13 of the Privacy Policy.

11. Logging and Auditability

11.1. We maintain centralised, tamper-evident logs of administrative actions, authentication events and access to Interaction Content, with alerting on anomalous access patterns.

11.2. You can audit the automation. The Dashboard records which interaction was answered, when, on which channel, in which publishing mode, and who approved or rejected each draft. That audit trail is retained for twelve (12) months without message content.

11.3. Error monitoring is configured to scrub message content and personal data before it reaches any log.

12. Retention, Deletion and Backups

12.1. Retention periods are stated in full in Section 14 of the Privacy Policy. In summary: public Interaction Content 12 months; private message content 90 days from the last message; AI input and output logs 30 days (90 during the Beta); audit and access logs 12 months; OAuth tokens deleted within 7 days of disconnection.

12.2. Deletion. On account closure, disconnection of a Connected Account, or a valid deletion request, we delete the associated data from production systems within thirty (30) days. Deletion routes, including the Meta data deletion callback, are set out at maromel.com/data-deletion.

12.3. Backups. Encrypted backups run daily on a rolling thirty-five (35) day cycle. Data deleted from production is purged from backups by expiry of that cycle; we do not restore deleted data except in a disaster-recovery event, in which case the deletion is re-applied.

13. Incident Response and Notification

13.1. We maintain a written incident response plan covering detection, containment — including immediate revocation of compromised tokens and suspension of affected automation — eradication, recovery and post-incident review.

13.2. To you: 72 hours. Where we become aware of a personal data breach affecting Interaction Content or your own data, we notify you without undue delay and in any event within seventy-two (72) hours, with the nature of the incident, the categories and approximate volume affected, the likely consequences, the measures taken and a contact point. Where the full picture is not yet available we report in phases rather than delay the first notification.

13.3. To authorities. Where we act as controller we notify the competent supervisory authority within seventy-two (72) hours where the breach is likely to result in a risk to individuals' rights, and we notify the Israeli Privacy Protection Authority of a severe security incident where Israeli law requires it.

13.4. To platforms. We notify Meta and Google of incidents affecting data obtained through their APIs, as their platform terms require.

13.5. Your role. Where we act as processor, you as controller decide whether the incident must be notified to a supervisory authority or to your End Users, and you make that notification. We give you the information and assistance you reasonably need to do it.

13.6. We keep an internal register of all incidents, including those we assess as not notifiable, together with the reasoning.

14. Business Continuity

14.1. We rely on the redundancy of our managed cloud providers and maintain documented restoration procedures, tested at least quarterly.

14.2. The Service depends on the availability of the Supported Platforms and of our AI provider. Outages, rate limits or policy changes on their side are outside our control, as described in Section 11.3 of the Terms of Use.

14.3. The Supported Platforms remain the authoritative record of your published content. Do not rely on the Dashboard as your only record of customer communications.

15. Platform Security Requirements

15.1. As an integration partner of Meta and Google we comply with their developer security requirements: secure handling and storage of platform data, honouring permission revocations and data deletion requests, maintaining an accessible vulnerability reporting channel, reporting incidents involving platform data, and completing platform-mandated reviews and data protection assessments where they apply.

15.2. Platform data is used solely to provide the user-facing features of the Service. It is never sold, never used for advertising or ad measurement, never used to build or enrich profiles, and never used to train AI models. The full list of restrictions is in Sections 9 and 10 of the Privacy Policy.

16. Shared Responsibility

16.1. You are responsible for:

• the confidentiality of your Dashboard credentials, and for enabling multi-factor authentication where available;
• the security of the devices and email accounts used to access the Service;
• managing roles and permissions on the platform side — who administers your Facebook Page, your Instagram account and your Google Business Profile;
• reviewing AI Agent activity and configuration, and keeping Review & Approve Mode enabled on any channel where you have not satisfied yourself that autonomous publishing is safe;
• not entering the prohibited and sensitive data listed in Section 21 of the Privacy Policy;
• reporting suspected compromise immediately to security@maromel.com.

17. Vulnerability Reporting

17.1. Report suspected vulnerabilities privately to security@maromel.com, with enough detail to reproduce the issue. We acknowledge reports within three (3) business days, keep you informed while we investigate, and prioritise remediation by severity.

17.2. Safe harbour. We will not pursue legal action against researchers who act in good faith under these guidelines: do not access, modify, exfiltrate or delete data belonging to others; do not degrade the Service or run denial-of-service testing; do not use social engineering against our people or our customers; and give us a reasonable period to remediate before public disclosure.

17.3. We do not currently operate a paid bug bounty. We will credit researchers who ask to be credited.

18. What This Policy Does Not Claim

• We hold no certifications. We are not SOC 2 certified, not ISO 27001 certified, and hold no equivalent attestation. Section 2.2 says our controls are designed with reference to recognised frameworks; that is not certification and we do not present it as such.
• No completed external penetration test. We intend to commission one before general release. Until we publish a result here, assume none has been performed.
• We do not operate network-layer controls ourselves. Firewalls, network segmentation and intrusion detection are provided by our managed cloud platforms. We configure what they expose; we do not run an independent IDS.
• Prompt injection is not solved. Section 8.1 describes mitigations. A sufficiently novel attack embedded in an End User message may still influence generated output. This is why Review & Approve Mode is the default.
• Escalation filters are probabilistic. They will miss things. They are a quality measure, not a control you should rely on for safety-critical or regulated communications.
• All data is currently processed in the United States. An EU hosting region and an EU AI endpoint are available on request but are not the default.
• We are a small team. There is no 24/7 security operations centre and no on-call rotation guaranteeing a response time outside business hours.

19. Changes to This Policy

We review and update this Policy as the Service, our infrastructure and the regulatory landscape change. Material changes are reflected in the version number and "Last Updated" date at the top. Where a change reduces a protection described here, we will also notify customers by email. Previous versions are available on request.

20. Contact

Vulnerability reports and security questions: security@maromel.com
Privacy questions and rights requests: privacy@maromel.com
Everything else: hello@maromel.com