Vulnerability Disclosure

Vulnerability Disclosure Policy

This Vulnerability Disclosure Policy explains how security researchers, customers, users, and third parties can report suspected security vulnerabilities affecting Etalyon Sàrl-S, operating Squillify ("Squillify", "we", "us", or "our").

This policy is a draft and is not effective until published as active by Squillify. It is intended for security, legal, privacy, and operational review before launch.

1. Purpose

Squillify values responsible security research and coordinated vulnerability disclosure.

This policy explains:

• how to report a vulnerability;
• what information to include;
• what testing is permitted;
• what testing is prohibited;
• how to avoid harming other users, tenants, systems, or data;
• what researchers can expect from Squillify;
• what safe-harbor position Squillify takes for good-faith research within scope;
• what is outside the scope of this policy.

2. Reporting contact

If you believe you have discovered a security vulnerability in Squillify, report it to:

• [email protected]

Use the subject prefix:

[Vulnerability Report]

Do not report urgent security vulnerabilities through public channels, social media, ordinary support requests, or public issue trackers.

If your report involves abuse, compromised credentials, or active misuse, you may also contact:

• [email protected]

3. What to include in a report

Please include enough information for Squillify to understand, reproduce, and assess the issue.

Useful information includes:

• affected domain, endpoint, API route, dashboard page, or feature;
• vulnerability type;
• impact;
• reproduction steps;
• proof-of-concept details;
• relevant request identifiers;
• relevant timestamps, including timezone;
• test account or tenant used;
• HTTP method and status code where applicable;
• screenshots or logs where safe to share;
• whether any data was accessed;
• whether any service disruption occurred;
• whether the vulnerability is actively exploited;
• your contact information;
• whether you intend to disclose publicly.

Do not include secrets, full API keys, passwords, private keys, payment card data, unnecessary personal data, customer data belonging to others, or malware samples unless Squillify explicitly requests a safe transfer method.

4. Scope

This policy applies to security vulnerabilities affecting production Squillify services, including:

• Squillify public APIs;
• Squillify dashboard;
• tenant access controls;
• authentication and session handling;
• API key handling;
• authorisation and scope enforcement;
• tenant isolation;
• skill execution controls;
• file reference access controls;
• temporary file handling;
• presigned URL handling;
• rate-limit or quota bypass;
• logging or secret exposure;
• external-service safety controls;
• network safety controls for URL-fetching skills;
• security-relevant misconfiguration in Squillify-controlled systems.

This policy does not authorise testing against systems that are not owned, operated, or explicitly controlled by Squillify.

5. Out of scope

The following are outside the scope of this policy unless Squillify expressly authorises them in writing:

• customer-owned applications, agents, scripts, tools, or integrations;
• third-party provider systems;
• payment provider systems;
• authentication provider systems;
• cloud provider infrastructure not directly controlled by Squillify;
• customer-configured external endpoints;
• social engineering;
• phishing;
• physical attacks;
• denial-of-service testing;
• spam or abuse testing;
• malware deployment;
• destructive testing;
• attacks against employees, contractors, customers, or providers;
• vulnerability testing requiring access to data that does not belong to you;
• tests that require bypassing third-party terms or laws.

If you find a vulnerability in a third-party provider, report it to that provider through its own disclosure process.

6. Permitted testing

You may conduct good-faith security testing against Squillify only if you:

• use accounts, tenants, API keys, files, and data that you own or are authorised to use;
• keep testing limited and proportionate;
• avoid service disruption;
• avoid accessing, modifying, deleting, or exfiltrating data that does not belong to you;
• avoid privacy violations;
• stop testing immediately if you encounter customer data, secrets, or non-public information;
• report the issue promptly;
• give Squillify a reasonable opportunity to investigate and remediate before public disclosure;
• comply with this policy and applicable law.

Examples of permitted testing may include:

• testing authorisation boundaries within your own tenant;
• testing API key scope enforcement for keys you created;
• testing file reference access for files you own;
• testing whether invalid or expired references are rejected;
• testing input validation with harmless payloads;
• testing rate-limit behaviour without causing degradation;
• reviewing publicly available documentation and client behaviour;
• reporting exposed secrets that are publicly visible without further intrusion.

7. Prohibited testing

You must not:

• access, modify, delete, copy, retain, or exfiltrate data that does not belong to you;
• attempt cross-tenant data access beyond minimal proof necessary to identify the issue;
• perform denial-of-service or stress testing;
• degrade service for other users;
• run high-volume automated scanning;
• run credential stuffing, password spraying, or brute-force attacks;
• use stolen, leaked, guessed, or unauthorised credentials;
• bypass payment, billing, quota, or rate-limit controls for personal benefit;
• deploy malware;
• persist access;
• install backdoors;
• create hidden accounts;
• alter logs;
• delete evidence;
• perform phishing or social engineering;
• target Squillify employees, customers, contractors, or providers;
• test physical security;
• attack third-party providers;
• attack customer-configured external endpoints;
• exploit a vulnerability beyond what is necessary to demonstrate it safely;
• publicly disclose the issue before coordinated remediation, unless legally required.

If you are unsure whether a test is allowed, contact Squillify before performing it.

8. Handling accidental access to data

If you accidentally access data that does not belong to you:

1. stop testing immediately;
2. do not copy, retain, disclose, modify, or delete the data;
3. do not continue exploring;
4. document only the minimum information needed to explain what happened;
5. report the issue to Squillify immediately;
6. follow Squillify's reasonable instructions for containment and deletion.

Do not include third-party personal data, secrets, or confidential information in your report unless necessary and safe.

9. Safe harbor position

Squillify will not intentionally pursue legal action against researchers for good-faith security research that:

• is within the scope of this policy;
• complies with this policy;
• avoids harm to Squillify, customers, providers, and third parties;
• does not access, retain, modify, or exfiltrate data that does not belong to the researcher;
• does not disrupt service;
• does not violate applicable law;
• is promptly reported to Squillify;
• gives Squillify a reasonable opportunity to investigate and remediate.

This safe-harbor position is Squillify's statement of intent. It does not authorise illegal activity, bind third parties, override applicable law, or prevent public authorities or third parties from taking action.

Testing remains the researcher's responsibility.

10. Legal limits

This policy does not grant permission to violate Luxembourg law, EU law, third-party rights, contractual obligations, provider terms, or the rights of other customers.

In Luxembourg, unauthorised access, illegal interception, data interference, system interference, misuse of devices, computer-related forgery, and computer-related fraud may constitute criminal offences.

Researchers must remain within the limits of this policy and applicable law.

11. Personal data and breach handling

A vulnerability report may involve personal data.

If Squillify determines that a reported issue involves a personal data breach, Squillify will assess its obligations under applicable data protection law, the Privacy Policy, and the Data Processing Agreement.

Where required by law, Squillify will notify the competent supervisory authority or affected customers within applicable timelines.

Where Squillify acts as processor for Customer Personal Data, Squillify will notify the relevant customer without undue delay after becoming aware of a personal data breach affecting that Customer Personal Data, as described in the Data Processing Agreement.

Researchers must not disclose personal data obtained during testing.

12. Coordinated disclosure

Squillify asks researchers to give Squillify a reasonable opportunity to investigate, remediate, and communicate before public disclosure.

Unless otherwise agreed, researchers should not publicly disclose a vulnerability until:

• Squillify has confirmed remediation; or
• Squillify has had a reasonable period to investigate and address the issue; or
• disclosure is legally required.

The appropriate disclosure timeline may depend on severity, exploitability, active exploitation, affected customers, provider involvement, and remediation complexity.

Squillify may ask for additional time where needed to protect customers or coordinate with providers.

13. What you can expect from Squillify

For reports that appear to be in scope and submitted in good faith, Squillify aims to:

• acknowledge receipt;
• triage the report;
• request additional information where needed;
• investigate the issue;
• assess severity and impact;
• remediate where appropriate;
• coordinate with providers where necessary;
• keep the researcher informed of material progress where appropriate;
• notify affected customers or authorities where legally required;
• credit the researcher if agreed and appropriate.

Specific response times are not guaranteed unless expressly stated in writing.

14. Severity assessment

Squillify determines severity based on its own assessment.

Factors may include:

• exploitability;
• affected services;
• affected customers;
• data exposure;
• tenant isolation impact;
• authentication or authorisation impact;
• ability to modify or delete data;
• ability to execute unauthorised actions;
• ability to bypass billing, quotas, or rate limits;
• availability impact;
• active exploitation;
• remediation complexity.

A researcher-proposed severity may be considered but is not binding.

15. No bug bounty

Squillify does not currently operate a paid bug bounty program.

Submitting a report does not create a right to payment, reward, compensation, employment, contract, or reimbursement.

Squillify may choose to provide acknowledgement or credit at its discretion, where legally and operationally appropriate.

16. Public credit

Squillify may provide public credit for valid reports if:

• the researcher wants credit;
• the report was submitted in good faith;
• the vulnerability was in scope;
• disclosure would not create security, privacy, legal, customer, or operational risk;
• no law, contract, or customer obligation prevents credit;
• the researcher complied with this policy.

Squillify may decline public credit where appropriate.

17. Duplicates and known issues

Squillify may treat a report as duplicate or previously known if the vulnerability:

• was already reported;
• was already discovered internally;
• is already being remediated;
• is already known through provider advisories;
• is covered by a prior report;
• is not exploitable in Squillify's environment;
• is accepted risk;
• is outside scope.

Squillify may not provide detailed information about duplicate, sensitive, or internal findings.

18. Confidentiality

Information shared by Squillify during vulnerability handling may be confidential.

Researchers must not disclose non-public information learned through the reporting process, including:

• customer information;
• system details;
• internal architecture;
• remediation plans;
• provider information;
• security controls;
• incident details;
• communications with Squillify;
• exploit details before coordinated disclosure.

This does not prevent lawful reporting to competent authorities where required by law.

19. Vulnerabilities in external providers

If the issue affects a third-party provider, customer-configured endpoint, or external service:

• report it to the relevant provider where appropriate;
• do not test or exploit provider systems through Squillify;
• do not use Squillify to attack, scan, or overload third-party systems;
• notify Squillify if Squillify configuration or integration may be affected.

External service use is governed by the External Service Use Policy.

20. Vulnerabilities in AI or model behaviour

Squillify's core platform is intended to provide deterministic microskill execution.

If Squillify later provides AI-backed capabilities, reports involving AI-specific flaws may include:

• prompt injection affecting Squillify-controlled systems;
• data leakage through AI-backed features;
• unauthorised tool use;
• unsafe external calls;
• model-provider data handling issues;
• bypass of tenant or API key controls.

AI behaviour that merely reflects customer-provided prompts, customer-controlled agents, or third-party model behaviour may be outside scope unless it affects Squillify-controlled security boundaries.

21. Emergency reports

If you believe a vulnerability is actively exploited or creates immediate risk, indicate this clearly in the subject and report body.

Suggested subject:

[Vulnerability Report][Active Exploitation Suspected]

Include only safe, necessary details.

Do not attempt to contain the issue yourself by accessing systems, deleting data, disabling accounts, altering configurations, or disrupting service.

22. Relationship with other policies

This policy should be read together with:

• Security Policy;
• Acceptable Use Policy;
• API Usage and Fair Use Policy;
• Service Availability Policy;
• Support Policy;
• Privacy Policy;
• Data Processing Agreement;
• External Service Use Policy;
• Tenant and API Key Responsibility Policy.

If there is a conflict between this policy and the Data Processing Agreement regarding processing of Customer Personal Data on behalf of a customer, the Data Processing Agreement controls for that processing.

23. Changes to this policy

Squillify may update this policy from time to time.

If changes materially affect reporting scope, permitted testing, prohibited testing, or safe-harbor language, Squillify will provide reasonable notice through appropriate channels where practical.

24. Contact

For vulnerability reports:

• [email protected]

For active abuse:

• [email protected]

For general support:

• [email protected]

For privacy matters:

• [email protected]

For legal matters:

• [email protected]