External Service Use

External Service Use Policy

This External Service Use Policy explains when Etalyon Sàrl-S, operating Squillify ("Squillify", "we", "us", or "our"), uses external services in connection with the Squillify platform, APIs, dashboard, microskills, file handling, telemetry, authentication, billing, support, infrastructure, or related services.

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

1. Purpose

Squillify is designed to provide transparent, deterministic microskill execution.

This policy explains:

• Squillify's default position on external service use;
• when a microskill may call an external service;
• what it means when data leaves Squillify;
• how external services should be labelled;
• how external providers relate to sub-processors;
• how URL-fetching skills are handled;
• what customers are responsible for before using external-service skills;
• how AI-backed external services must be disclosed.

2. Core position

Squillify's default platform policy is:

• no hidden external service use for submitted microskill payloads;
• self-contained microskills should run within Squillify-controlled execution infrastructure;
• if a microskill sends submitted data to an external service, that must be explicitly labelled;
• customers should be able to understand whether a skill is self-contained, reads from an external source, writes to an external system, or depends on an external provider;
• external service use should be documented before production use.

A microskill must not be marketed or labelled as self-contained if its normal operation requires sending submitted payloads to an external provider.

3. What counts as an external service

An external service is any third-party system, provider, API, website, endpoint, cloud service, database, model provider, payment provider, authentication provider, messaging provider, storage provider, monitoring provider, or infrastructure component that is not operated directly by Squillify.

External services may include:

• cloud infrastructure providers;
• authentication providers;
• database providers;
• object storage providers;
• payment processors;
• email providers;
• monitoring and logging providers;
• support tools;
• analytics providers;
• public websites accessed by URL-fetching skills;
• third-party APIs used by a microskill;
• AI model providers;
• OCR, translation, media, conversion, enrichment, or verification services;
• customer-configured external endpoints;
• webhooks.

4. Platform providers and microskill external services

There are two different categories of external service use.

4.1 Platform providers

Platform providers help Squillify operate the service.

Examples may include:

• hosting;
• database;
• object storage;
• authentication;
• payment;
• email;
• logging;
• monitoring;
• security;
• support tooling.

These providers may process platform data, account data, billing data, operational metadata, support data, or temporary files depending on their role.

Platform providers that process personal data on behalf of Squillify or customers are listed on the Sub-processors page where applicable.

4.2 Microskill external services

A microskill external service is a provider, website, API, endpoint, or external system that a microskill contacts to perform its function.

Examples may include:

• fetching a public URL;
• calling a customer-provided webhook;
• calling a third-party API;
• using an external OCR provider;
• using an external AI model provider;
• sending a file to a conversion provider;
• verifying a domain or network resource;
• reading from a public dataset endpoint;
• writing to an external integration.

Microskill external service use must be disclosed at skill level before customers rely on the skill for production workflows.

5. External service classifications

Squillify may classify skills using one or more of the following categories.

The exact labels exposed in the product may differ, but the product should preserve the underlying meaning.

6. Skill-level transparency

A skill that uses an external service should disclose, where applicable:

• whether it reads from external sources;
• whether it writes to external systems;
• whether it sends submitted payloads outside Squillify;
• whether it sends files outside Squillify;
• whether the external provider is named;
• what categories of data are sent;
• the provider's role;
• whether the provider is a sub-processor;
• whether provider terms apply;
• processing region where known;
• international transfer mechanism where applicable;
• retention by the provider where known;
• whether the provider may use data for training, analytics, or service improvement;
• whether the skill can be disabled, avoided, or restricted;
• whether the customer supplies the endpoint or credentials.

Until dynamic skill-level badges are implemented, this policy describes the default platform approach and the intended disclosure model.

7. What data may be sent to an external service

Depending on the skill, the data sent to an external service may include:

• URL or domain submitted by the customer;
• headers required for the request;
• request body required for the operation;
• file content;
• file metadata;
• transformed file content;
• text extracted from files;
• identifiers needed to complete the operation;
• customer-configured parameters;
• authentication tokens supplied by the customer for the external system;
• operational metadata necessary for routing or security;
• output destination information.

Squillify should limit data sent to external services to what is necessary for the requested operation.

Customers are responsible for deciding whether the data they submit may lawfully be sent to the relevant external service.

8. Customer responsibility

Customers are responsible for determining whether their use of an external-service skill is lawful and appropriate.

Customers must consider:

• whether submitted data contains personal data;
• whether submitted data contains confidential, sensitive, regulated, or third-party data;
• whether the external provider is acceptable under the customer's internal policies;
• whether the external provider may process data outside the European Economic Area;
• whether the external provider's terms permit the customer's use case;
• whether the customer has authority to send the data to the provider;
• whether sector-specific rules apply;
• whether customer-side consent, notice, contract, risk assessment, or approval is required;
• whether the skill should be disabled or restricted for certain API keys.

Squillify provides transparency, documentation, and controls, but customers decide what their users, agents, applications, API keys, and integrations may submit.

9. Sub-processors

An external provider may be a sub-processor where it processes personal data on behalf of Squillify or on behalf of Squillify's customers.

Where an external provider acts as a sub-processor, it should be listed on the Sub-processors page.

The Sub-processors page should identify, where confirmed:

• provider name;
• purpose;
• categories of data processed;
• processing region;
• transfer mechanism;
• provider policy or DPA link;
• status;
• effective date or planned use date.

Under the Data Processing Agreement, Squillify may engage sub-processors subject to the relevant authorisation and notice process.

10. International transfers

External service use may involve transfer of personal data outside the European Economic Area.

Where personal data is transferred outside the European Economic Area, Squillify will use safeguards required by applicable data protection law, such as:

• adequacy decision;
• Standard Contractual Clauses approved by the European Commission;
• provider data processing terms;
• supplementary measures where required;
• EU-only processing configuration where available.

Specific transfer mechanisms must be confirmed on the Sub-processors page or applicable provider documentation before a provider is relied on for production use involving personal data.

11. External provider terms

External providers may apply their own terms, privacy policies, data processing terms, usage restrictions, retention rules, security practices, availability levels, and acceptable use rules.

Customers may need to comply with external provider terms where:

• the customer directly configures the provider;
• the customer provides the provider account, token, endpoint, or credentials;
• the skill documentation states that provider terms apply;
• the external service is accessed at the customer's direction;
• the provider requires downstream compliance.

Squillify is not responsible for third-party terms, policies, outages, restrictions, model behaviour, data retention, or security practices outside Squillify's reasonable control, except as required by applicable law or written agreement.

12. Customer-configured external endpoints

Some features may allow customers to configure external endpoints, including URLs, APIs, webhooks, storage destinations, or integration targets.

For customer-configured external endpoints:

• the customer is responsible for the endpoint;
• the customer is responsible for credentials and tokens supplied for that endpoint;
• the customer is responsible for the legality of sending data to that endpoint;
• the customer is responsible for any downstream processing performed by that endpoint;
• the customer is responsible for ensuring that the endpoint is secure and authorised;
• the customer must not use the feature to attack, scan, overload, or abuse third-party systems.

Squillify may block, restrict, throttle, or reject customer-configured endpoints where needed for security, abuse prevention, network safety, legal compliance, or platform protection.

13. URL-fetching skills

Some skills may fetch URLs to perform a requested operation.

URL-fetching skills are external-read skills.

Customers are responsible for ensuring that the URL they provide may be accessed lawfully and that fetching it through Squillify does not violate third-party rights, terms, policies, robots rules where applicable, access restrictions, or applicable law.

URL-fetching skills must not be used for:

• unauthorised scanning;
• vulnerability probing;
• credential harvesting;
• bypassing access controls;
• scraping at abusive scale;
• accessing private systems without authorisation;
• attacking third-party infrastructure;
• evading rate limits or IP-based controls;
• retrieving unlawful content;
• violating the Acceptable Use Policy.

14. Network safety controls

Skills that fetch URLs or make outbound requests should be routed through controls intended to reduce network abuse and server-side request forgery risk.

Such controls may include, where applicable:

• blocking private IP ranges;
• blocking loopback addresses;
• blocking link-local addresses;
• blocking metadata service endpoints;
• blocking internal hostnames;
• DNS rebinding protections;
• redirect limits;
• request timeouts;
• maximum response size limits;
• content-type restrictions;
• protocol restrictions;
• port restrictions;
• deny lists;
• allow lists where appropriate;
• rate limits;
• logging of metadata for security and abuse prevention.

These controls are safety measures, not a guarantee that every unsafe destination or malicious pattern will be detected.

Customers must not attempt to bypass network safety controls.

15. External write and side effects

External-write skills can create or modify data or trigger actions outside Squillify.

Examples include:

• posting to a webhook;
• writing to a database;
• sending an email;
• creating a ticket;
• updating a repository;
• calling a third-party API that changes state;
• triggering a workflow.

External-write skills carry higher risk than self-contained or external-read skills.

Customers are responsible for:

• confirming the destination;
• controlling credentials;
• limiting API key scopes;
• preventing accidental writes by agents;
• testing workflows safely;
• implementing approval flows where appropriate;
• monitoring downstream effects.

Squillify may require additional confirmation, scopes, labels, or restrictions for external-write skills.

16. External AI and model providers

If a skill uses an external AI model, machine learning service, or model provider, the skill must be explicitly labelled as AI-backed external before production use.

The label should disclose, where known:

• provider name;
• data sent to the provider;
• whether the provider retains inputs or outputs;
• whether the provider uses submitted data for training or model improvement;
• processing region;
• applicable terms;
• transfer mechanism;
• whether the skill can be disabled or avoided.

External AI-backed skills are also governed by the AI / Training Use Policy.

No external AI-backed skill should be presented as self-contained, no-network, or deterministic unless that is accurate.

17. Payment, authentication, support, and infrastructure providers

Squillify may use external providers to operate ordinary platform functions.

Examples include:

• payment processing;
• authentication;
• hosting;
• database;
• object storage;
• email delivery;
• monitoring;
• logging;
• customer support tooling;
• analytics.

These providers are not necessarily microskill external services, but they may still be sub-processors or independent controllers depending on their role.

They are addressed in the Privacy Policy, Data Processing Agreement, Security Policy, Cookie Policy, Billing and Refund Policy, and Sub-processors page.

18. No hidden external service promise

When Squillify states that there is no hidden external service, this means that submitted microskill payloads are not intentionally sent to an external provider for normal execution unless the skill, feature, or policy discloses that external service use.

This does not mean that Squillify operates without any infrastructure providers, authentication providers, payment providers, monitoring providers, or other operational service providers.

This distinction matters:

• platform providers help operate Squillify;
• microskill external services process or retrieve data as part of a specific skill execution.

19. Disabling or restricting external-service skills

Squillify may provide controls to restrict or disable external-service skills.

Controls may include:

• tenant-level restrictions;
• API-key-level skill access;
• scopes;
• rate limits;
• quota limits;
• admin approvals;
• category filters;
• external-service labels;
• execution policy checks.

Customers should restrict external-service skills for agents or applications that must not send data outside Squillify or contact external systems.

20. Incident, abuse, and provider changes

Squillify may suspend, restrict, replace, disable, or remove an external-service skill or provider where necessary for:

• security;
• privacy;
• legal compliance;
• provider termination;
• provider policy changes;
• provider outage;
• abuse prevention;
• unacceptable risk;
• customer protection;
• platform reliability;
• DPA or sub-processor compliance.

Where practical, Squillify will provide reasonable notice of material provider changes. Immediate changes may be made without prior notice where needed for security, legal, provider, or operational reasons.

21. Documentation and descriptor accuracy

Squillify aims to keep skill descriptors, data handling labels, documentation, and policy pages accurate.

Customers should review skill descriptors and documentation before using a skill with sensitive, confidential, regulated, personal, or third-party data.

If a customer identifies inaccurate external-service labelling, they should report it to:

• Support: [email protected]
• Security: [email protected]
• Privacy: [email protected]

22. Relationship with other policies

This policy should be read together with:

• Microskill Data Handling Policy;
• Privacy Policy;
• Data Processing Agreement;
• Sub-processors page;
• Security Policy;
• File Handling Policy;
• Telemetry and Analytics Policy;
• AI / Training Use Policy;
• Acceptable Use Policy;
• API Usage and Fair 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 whether customer payloads are sent to external providers, Squillify will provide reasonable notice through appropriate channels.

Squillify will not intentionally convert a self-contained skill into an external-service skill without updating its data handling label or documentation.

24. Contact

For questions about this policy, contact:

• Support: [email protected]
• Privacy: [email protected]
• Security: [email protected]
• Legal: [email protected]

For abuse reports involving external service use, contact [email protected].