File Handling

File Handling Policy

This File Handling Policy explains how Etalyon Sàrl-S, operating Squillify ("Squillify", "we", "us", or "our"), handles files used with the Squillify platform, APIs, dashboard, microskills, file references, temporary storage, uploads, downloads, generated outputs, and related workflows.

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

Some Squillify microskills operate on files rather than only inline JSON payloads.

This policy explains:

• how file references work;
• how file access is authorised;
• how temporary file storage works;
• how uploads and downloads are handled;
• how long files are retained;
• what limits apply;
• what customers are responsible for;
• what happens when files expire;
• how file handling relates to privacy, security, external services, and data retention.

2. Core file handling principles

Squillify's file handling model is based on the following principles:

• files are referenced through opaque file references, not arbitrary filesystem paths;
• a file reference is not proof of authorisation;
• file access is checked when a file reference is resolved;
• file references are scoped to the owning tenant;
• temporary files are short-lived by default;
• presigned URLs are short-lived by default;
• expired or deleted files are rejected;
• raw file content is not retained longer than necessary for the requested workflow;
• file-based workflows should use data minimisation;
• customers decide what files their users, agents, applications, API keys, and integrations may submit.

3. File references

Some microskills operate on files. When such a skill is used, files are addressed through an opaque file reference rather than a local filesystem path or arbitrary external URL.

A file reference is a platform-managed identifier that may point to a temporary uploaded file, generated file, transformed file, or intermediate file.

A file reference:

• is not a public URL;
• is not a filesystem path;
• is not a guarantee that the file still exists;
• is not proof that the requester is authorised;
• must be resolved through Squillify-controlled file handling mechanisms;
• may expire;
• may be deleted automatically;
• may become invalid after completion of a workflow;
• may be rejected if access checks fail.

4. What file references cannot be

File references are opaque identifiers managed by Squillify.

They cannot be used to directly reference:

• local filesystem paths;
• arbitrary external URLs;
• internal cloud metadata endpoints;
• private network resources;
• customer-side local files;
• paths inside Squillify infrastructure;
• provider storage paths;
• unsupported protocols;
• unauthorised files belonging to another tenant;
• expired or deleted files.

If a skill needs to fetch an external URL, that is treated as external service use and is governed by the External Service Use Policy and Acceptable Use Policy.

5. Authorization and tenant isolation

File references are scoped to the tenant that owns or created them.

Every time a file reference is resolved, Squillify should check whether the requesting credential is allowed to access the file.

Access checks may consider:

• tenant ownership;
• API key identity;
• API key scopes;
• user role;
• skill access permissions;
• file purpose;
• file status;
• file expiry;
• file deletion state;
• workflow context;
• request method;
• rate limits;
• abuse or security signals.

Expired, deleted, invalid, cross-tenant, unauthorised, or malformed references are rejected.

Customers are responsible for managing tenant users, API keys, scopes, and agent access to reduce unauthorised file exposure.

6. Upload flow

Where Squillify supports file upload, the upload flow may use platform APIs, presigned URLs, or another controlled upload mechanism.

The upload flow may involve:

• creating a file reference;
• validating tenant and credential access;
• enforcing file size limits;
• enforcing file count limits;
• enforcing content-type or extension restrictions;
• storing the file temporarily;
• recording file metadata;
• returning a file reference;
• making the file available only for an authorised workflow;
• automatically expiring the file after a short time.

Customers must not upload files they are not authorised to process through Squillify.

7. Download flow

Where Squillify supports file download, the download flow may use platform APIs, presigned URLs, or another controlled download mechanism.

The download flow may involve:

• resolving a file reference;
• checking tenant and credential authorisation;
• checking file status;
• checking expiry;
• generating a short-lived download URL;
• enforcing response size and download limits;
• logging metadata for security, billing, abuse prevention, and reliability.

Download links may expire quickly and may need to be regenerated through an authorised API call.

8. Presigned URLs

Squillify may use presigned URLs for file upload or download.

Presigned URLs are time-limited access mechanisms and should be treated as sensitive.

Default maximum lifetime:

60 seconds

Presigned URLs may expire earlier where required for security, provider behaviour, operational reasons, or policy controls.

Customers must:

• avoid logging presigned URLs unnecessarily;
• avoid sharing presigned URLs with unauthorised parties;
• use presigned URLs only for the intended operation;
• design integrations to handle expiry;
• request a new operation where appropriate.

A presigned URL is not a long-term storage link.

9. Temporary file retention

Temporary files are retained only for a short period by default.

Configured default TTLs:

The normal expiry time controls whether a file can be accessed. The cleanup scheduler is configured to check for expired files approximately every 60 seconds. Physical deletion can therefore follow expiry rather than occur at the same instant. A one-day object-storage lifecycle rule is configured as a cleanup backstop and does not make an expired file authorised or available for one day.

After expiry:

• the file may be automatically deleted;
• the file reference may become invalid;
• downloads may stop working;
• access may return 410 Gone;
• support may not be able to recover the file;
• re-execution may be required.

Specific capabilities or plan limits may make a file expire earlier. Production startup rejects a configured file TTL above 10 minutes. Any future increase requires a code, configuration, legal, privacy, security, and product change; it cannot be introduced only by changing this policy.

10. Expired and deleted files

If a file has expired or been deleted, Squillify may return an error such as:

410 Gone

Expired or deleted files are not considered service downtime.

Customers must design applications, scripts, and agents to handle expired file references safely.

Recommended behaviour:

• do not retry expired file downloads indefinitely;
• do not assume file references remain valid after workflow completion;
• re-run the relevant operation where needed;
• avoid exposing expired file errors to end users without context;
• store customer-side copies where lawful and necessary.

11. File metadata

Squillify may retain file metadata for security, billing, telemetry, support, abuse prevention, and operational purposes.

File metadata may include:

• file reference identifier;
• tenant identifier;
• API key identifier or derived identifier;
• file purpose;
• file status;
• creation time;
• expiry time;
• deletion time;
• size;
• content type;
• checksum or hash;
• storage provider metadata;
• related run identifier;
• related skill key;
• upload or download status;
• error codes;
• deletion attempts;
• deletion errors;
• abuse or security signals.

File metadata should not include raw file content.

Retention of file metadata is described in the Data Retention Policy.

12. File content

File content may include personal data, confidential data, regulated data, sensitive data, third-party data, or intellectual property if submitted by the customer.

Squillify does not determine whether a file contains such data.

Customers are responsible for determining whether files may be submitted to Squillify and whether the selected capability is appropriate for that file.

Squillify is designed to avoid retaining file content longer than needed for the requested file-based workflow, subject to temporary storage, operational needs, legal obligations, security incidents, abuse investigations, or other exceptions described in the Data Retention Policy.

13. Limits

File-based features may enforce limits.

Limits may include:

• maximum file size;
• maximum total request size;
• maximum number of files per request;
• maximum number of file references;
• maximum upload duration;
• maximum download duration;
• maximum processing time;
• maximum output file size;
• maximum archive size;
• maximum decompressed size;
• allowed content types;
• allowed file extensions;
• blocked file types;
• concurrency limits;
• rate limits;
• quota limits;
• retention limits.

Requests that exceed limits may be rejected before processing or may fail during processing.

Specific numeric limits may depend on the plan, skill, endpoint, or feature and may be published in the relevant API documentation.

14. Unsupported or prohibited file use

Customers must not use file handling features to:

• upload malware;
• distribute malware;
• store illegal content;
• store unlawful personal data;
• store stolen data;
• store credentials or secrets unnecessarily;
• bypass Squillify retention limits;
• create persistent storage;
• host public files;
• distribute copyrighted material without authorisation;
• attack, scan, or overload third-party systems;
• exfiltrate data;
• hide abusive traffic;
• bypass rate limits, quotas, or billing controls;
• process data in violation of the Acceptable Use Policy.

Squillify may reject, delete, quarantine, restrict, or block files where needed for security, abuse prevention, legal compliance, provider requirements, or platform protection.

15. Malware scanning and content inspection

Before this policy becomes active, Squillify must confirm whether malware scanning, content scanning, or file inspection is performed.

Unless expressly stated for a specific feature, customers should not assume that Squillify scans every file for malware, sensitive data, confidential data, regulated data, illegal content, or policy violations.

Squillify does not provide a general-purpose sensitive data detection or classification service and does not guarantee that unsafe, unlawful, sensitive, or regulated file content will be detected or blocked.

Squillify may perform limited inspection where needed for:

• file type validation;
• size validation;
• security;
• abuse prevention;
• malware prevention;
• policy enforcement;
• troubleshooting;
• legal compliance.

Such inspection should be limited to what is necessary and consistent with the Privacy Policy, Data Processing Agreement, Security Policy, and Data Retention Policy.

16. Archives, compressed files, and decompression

Some skills may create, read, extract, or transform archives or compressed files.

Squillify may apply controls to reduce decompression and archive abuse risks, including:

• maximum archive size;
• maximum decompressed size;
• maximum file count;
• maximum nesting depth;
• path traversal protections;
• blocked file names;
• blocked absolute paths;
• blocked parent directory traversal;
• timeout controls;
• zip bomb protections;
• content-type restrictions.

Customers must not use file handling features to exploit archive extraction, path traversal, decompression bombs, or resource exhaustion.

17. Derived and generated files

Some microskills may generate new files from customer inputs.

Generated files may include:

• converted files;
• transformed files;
• reports;
• archives;
• extracted content;
• images;
• text outputs;
• structured data exports;
• temporary intermediate files.

Generated files are treated as customer-related output temporary files unless otherwise stated and use the approximately 10-minute configured output default, subject to the 10-minute production ceiling.

They are subject to the same tenant scoping, authorization, expiry, deletion, metadata, limits, and retention rules described in this policy.

18. External services and file processing

Some file-based skills may involve external services.

Where file content or file-derived data is sent to an external provider, the skill must be explicitly labelled as using an external service.

External file processing may involve:

• file conversion providers;
• OCR providers;
• AI model providers;
• media processing providers;
• storage destinations;
• customer-configured endpoints;
• public URL fetching;
• third-party APIs.

External service use is governed by the External Service Use Policy, Sub-processors page, Data Processing Agreement, Privacy Policy, and the relevant skill documentation.

Customers are responsible for deciding whether the file may be sent to an external provider.

19. Encryption and storage security

Squillify should protect file handling using appropriate technical and organisational measures.

Measures may include:

• encryption in transit;
• encryption at rest where supported by the storage provider;
• tenant scoping;
• short-lived presigned URLs;
• access control checks;
• logging and monitoring of file metadata;
• deletion jobs;
• restricted production access;
• provider security controls;
• audit or operational records;
• rate limits and quotas;
• abuse prevention controls.

The exact storage provider, region, encryption mode, and retention configuration must be confirmed before this policy becomes active.

20. Processing regions and transfers

Files may be processed or stored in regions determined by Squillify's infrastructure configuration and providers.

Before this policy becomes active, Squillify must confirm:

• storage provider;
• processing region;
• backup region where applicable;
• whether files may leave the European Economic Area;
• applicable transfer mechanism;
• sub-processor status;
• provider DPA or privacy terms.

If files contain personal data and are transferred outside the European Economic Area, applicable transfer safeguards must be in place as described in the Data Processing Agreement and Sub-processors page.

21. Backups

Temporary files should generally not be retained in long-term backups beyond what is technically necessary for provider or infrastructure operation.

If file content enters backups, deletion may occur through backup rotation rather than immediate removal from every backup copy.

Before this policy becomes active, Squillify must confirm whether temporary file storage is included in backups and, if so, the backup retention period.

22. Logging

File operations may generate metadata logs.

Logs may include:

• upload request metadata;
• download request metadata;
• file reference metadata;
• tenant identifier;
• API key identifier or derived identifier;
• skill key;
• status code;
• error code;
• latency;
• file size;
• content type;
• expiry state;
• deletion state;
• security signals;
• abuse signals.

Logging practices are designed to avoid permanent raw file content capture as part of normal execution.

If temporary diagnostic logging is required for a specific investigation, it must be limited, documented, access-controlled, time-bound, and deleted when no longer needed.

23. Customer responsibilities

Customers are responsible for:

• deciding what files their users, agents, applications, API keys, and integrations submit;
• ensuring files are lawful to process;
• ensuring files do not violate third-party rights;
• ensuring files do not contain prohibited, unnecessary, sensitive, regulated, or confidential data unless lawful and appropriate;
• securing API keys and credentials;
• restricting file-capable skills where needed;
• handling expired file references;
• downloading outputs promptly where needed;
• retaining their own copies where lawful and necessary;
• avoiding reliance on Squillify as persistent file storage;
• complying with the Terms of Service, Acceptable Use Policy, API Usage and Fair Use Policy, and Data Processing Agreement.

24. Support and file recovery

Because files are short-lived by default, support may not be able to recover uploaded, generated, transformed, or expired files.

For file-related support requests, customers should provide:

• request identifier or run identifier;
• file reference where safe to share;
• skill key and version;
• approximate time of operation;
• file size and content type;
• error code;
• expected and actual behaviour;
• sanitized example file if needed.

Customers must not send secrets, unnecessary personal data, confidential data, regulated data, or malware to support.

25. Security incidents involving files

A file-related security incident may include:

• unauthorised file access;
• cross-tenant file exposure;
• malware upload or distribution;
• accidental retention beyond policy;
• failure of deletion controls;
• unauthorised external transfer;
• leakage of presigned URLs;
• access to expired files;
• exposure of file metadata;
• compromise of storage provider credentials.

Suspected file-related security incidents should be reported to [email protected].

Where personal data is involved, breach handling is governed by the Privacy Policy, Data Processing Agreement, Security Policy, and Applicable Data Protection Law.

26. Relationship with other policies

This policy should be read together with:

• Data Retention Policy;
• Microskill Data Handling Policy;
• Security Policy;
• Privacy Policy;
• Data Processing Agreement;
• External Service Use Policy;
• API Usage and Fair Use Policy;
• Acceptable Use Policy;
• Support Policy;
• Sub-processors page.

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.

27. Changes to this policy

Squillify may update this policy from time to time.

If changes materially affect temporary file retention, file access, external file processing, file security, or customer responsibilities, Squillify will provide reasonable notice through appropriate channels.

No active version of this policy should contain unconfirmed storage provider, processing region, transfer mechanism, malware scanning, backup retention, or file retention values.

28. Contact

For questions about this policy, contact:

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

For abuse involving file handling, contact [email protected].