Security Policy

Security Policy

This Security Policy explains how Etalyon Sàrl-S, operating Squillify ("Squillify", "we", "us", or "our"), approaches platform security, tenant isolation, credential protection, access control, logging, file security, incident response, vulnerability handling, dependency management, and operational resilience.

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

1. Purpose

Squillify is a capability platform that lets applications, developers, AI agents, automation systems, and other software clients invoke verified microskills through controlled APIs and execution layers.

This policy explains:

• the default platform security posture;
• how tenants are isolated;
• how API keys and credentials are protected;
• how access controls work;
• how traffic and abuse are managed;
• how logging and telemetry are handled;
• how files and temporary storage are protected;
• how production access is controlled;
• how vulnerabilities and incidents are handled;
• what customers remain responsible for.

Security is treated as a product requirement, not an afterthought.

2. Scope

This policy applies to Squillify production services, including:

• public APIs;
• microskill execution;
• tenant dashboard;
• API key management;
• skill catalog and descriptors;
• usage telemetry;
• temporary file handling;
• billing-related access controls;
• support-related security handling;
• operational monitoring;
• Trust Center security commitments.

This policy does not apply to:

• customer applications, agents, scripts, automations, or integrations;
• customer networks, devices, browsers, identity environments, or infrastructure;
• third-party providers outside Squillify's reasonable control;
• beta, preview, sandbox, test, or experimental services unless expressly stated.

3. Security principles

Squillify's security model is based on the following principles:

• deny by default;
• least privilege;
• tenant isolation;
• scoped API access;
• no permanent raw payload storage by default;
• metadata-only telemetry by design;
• short-lived temporary file handling;
• short-lived presigned URLs;
• defence against abuse and automated misuse;
• separation between administrative operations and skill execution;
• explicit external-service disclosure;
• controlled production access;
• documented vulnerability reporting;
• security review before high-risk changes.

4. Tenant isolation

Each customer operates within an isolated tenant context.

Requests are executed against the tenant derived from the authenticated credential. Tenant context must not be overridden through request bodies, headers, query parameters, skill arguments, or client-supplied metadata.

Tenant-scoped resources may include:

• tenant profile;
• users and members;
• roles and permissions;
• API keys;
• skill access settings;
• usage records;
• quota records;
• billing usage;
• telemetry views;
• file references;
• temporary files;
• support context;
• configuration settings.

Resource access is scoped to the owning tenant unless an explicitly authorised administrative function requires broader access.

Cross-tenant access is prohibited unless expressly authorised for Squillify administrative operations, support, security, billing, abuse prevention, legal compliance, or platform maintenance.

5. Authentication

Access to the dashboard and APIs requires authentication.

Authentication mechanisms may include:

• identity provider login;
• session cookies;
• API keys;
• tenant membership;
• role-based access control;
• administrative credentials;
• internal service credentials.

Production API access requires a valid credential issued or accepted by Squillify.

Customers are responsible for securing their own identity provider accounts, devices, browsers, email accounts, and administrative users.

6. API keys and secrets

API keys are security-sensitive credentials.

Squillify's API key model should follow these rules:

• API keys are issued to a tenant;
• API keys are shown only once at creation time;
• Squillify should not be able to recover the original full key value after creation;
• API keys are stored using a one-way hash or equivalent secure verification mechanism;
• API keys can be revoked;
• API keys can be rotated;
• API keys can carry scopes;
• API keys can carry rate limits and quota limits;
• API key usage can be monitored through metadata.

Customers must protect API keys and must not expose them in:

• public repositories;
• client-side code;
• browser local storage;
• browser-visible frontend bundles;
• logs;
• prompts;
• screenshots;
• shared documents;
• insecure environment files;
• support tickets;
• telemetry payloads;
• third-party tools without appropriate controls.

Customer responsibilities are described in the Tenant and API Key Responsibility Policy.

7. Authorisation and access controls

Squillify applies a deny-by-default access control model.

Operations require an authenticated credential with the appropriate authorisation.

Access controls may apply to:

• tenant administration;
• member management;
• API key creation and revocation;
• skill discovery;
• skill execution;
• file upload;
• file download;
• file reference resolution;
• usage telemetry access;
• billing views;
• admin operations;
• support operations;
• platform operations.

Privileged and administrative operations are separated from standard skill execution and require stronger authorisation.

Administrative endpoints should not be exposed to tenant users unless expressly authorised.

8. Skill access controls

Skill execution may be restricted by:

• tenant plan;
• tenant policy;
• API key scopes;
• per-key skill access;
• required scopes;
• skill availability;
• skill status;
• category restrictions;
• external-service classification;
• file handling permissions;
• rate limits;
• quotas;
• abuse controls;
• security policy checks.

Skills that access external services, write to external systems, process files, or carry higher operational risk may require additional restrictions.

9. Transport security

Production API and dashboard traffic is served over encrypted transport.

Plaintext transport is not supported for production endpoints.

Customers must use HTTPS/TLS-capable clients and must not disable certificate validation in production.

Squillify may reject insecure, malformed, outdated, or suspicious connections where needed for security or platform protection.

10. Encryption at rest

Squillify should use encryption at rest where supported by hosting, database, object storage, backup, logging, and infrastructure providers.

Before this policy becomes active, Squillify must confirm:

• database encryption-at-rest configuration;
• object storage encryption-at-rest configuration;
• backup encryption configuration;
• secrets storage approach;
• log storage security;
• relevant provider controls.

No active version of this policy should claim encryption at rest unless the relevant provider configuration has been confirmed.

11. Data minimisation and raw payload handling

Squillify is designed so that raw submitted microskill payloads are not permanently stored as part of normal execution.

This security posture reduces durable exposure of submitted payload content.

Default rules:

• raw payloads are processed to perform the requested execution;
• raw payloads are not intentionally written to permanent operational logs;
• usage telemetry is designed to be metadata-only;
• file content is temporary where file handling is used;
• support generally cannot retrieve raw payloads after execution;
• customers may need to provide sanitized examples for support.

This does not mean submitted data is never processed. Payloads may be temporarily present in memory, transient processing components, network transmission, short-lived file storage, or external services explicitly labelled for a skill.

12. Logging and redaction

Squillify uses logs and telemetry for security, reliability, support, billing, abuse prevention, and operations.

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

Logs may include:

• timestamp;
• tenant identifier;
• API key identifier or derived identifier;
• request identifier;
• skill key and version;
• status code;
• error code;
• latency;
• quota event;
• rate-limit event;
• file metadata;
• content type;
• payload size;
• component name;
• abuse or security signal.

Logs should avoid storing:

• raw microskill payloads;
• full API keys;
• passwords;
• private keys;
• access tokens;
• session cookies;
• payment card data;
• unnecessary personal data;
• customer secrets.

Validation errors, exceptions, and stack traces should avoid echoing raw payload content where possible.

Temporary diagnostic logging, if ever required, must be limited, documented, access-controlled, time-bound, and deleted when no longer needed.

13. File handling security

File-based workflows are protected by the File Handling Policy.

Security controls may include:

• opaque file references;
• tenant-scoped file ownership;
• authorisation checks on reference resolution;
• short-lived temporary file storage;
• short-lived presigned URLs;
• file size limits;
• file count limits;
• content-type restrictions;
• upload/download limits;
• deletion jobs;
• expired file rejection;
• 410 Gone for expired files;
• archive extraction protections where applicable;
• path traversal protections where applicable;
• metadata-only file telemetry;
• rate limits and quotas.

Customers must not use Squillify file handling as long-term storage.

Before this policy becomes active, Squillify must confirm whether malware scanning is performed and what file types or sizes are supported.

14. Network safety and external access

Some skills may fetch URLs or contact external services.

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

For URL-fetching and outbound network features, Squillify may apply controls intended to reduce abuse and server-side request forgery risk, including:

• private IP blocking;
• loopback blocking;
• link-local address blocking;
• metadata endpoint blocking;
• internal hostname restrictions;
• DNS rebinding protections;
• redirect limits;
• request timeouts;
• response size limits;
• protocol restrictions;
• port restrictions;
• deny lists;
• allow lists where appropriate;
• rate limits;
• abuse monitoring.

These controls reduce risk but do not guarantee that every unsafe destination or malicious pattern will be detected.

Customers must not attempt to bypass network safety controls.

15. Abuse prevention

Squillify protects execution surfaces with abuse prevention controls.

Controls may include:

• rate limiting;
• quotas;
• concurrency limits;
• execution time limits;
• file size limits;
• payload size limits;
• traffic anomaly detection;
• account or tenant restrictions;
• API key revocation;
• skill access restrictions;
• IP or network restrictions;
• temporary blocking;
• permanent suspension;
• abuse investigation;
• enforcement of Acceptable Use Policy;
• enforcement of API Usage and Fair Use Policy.

Requests that exceed configured limits may be rejected, throttled, delayed, blocked, or charged according to the applicable plan and policies.

16. Production access

Access to production systems should be restricted to authorised personnel and systems with a legitimate operational need.

Production access controls may include:

• least privilege;
• role-based access;
• administrative separation;
• multi-factor authentication where supported;
• access logging;
• approval processes for privileged access;
• time-limited access where practical;
• periodic access review;
• revocation after role change or termination;
• separation between development, test, and production environments.

Before this policy becomes active, Squillify must confirm its production access model and access review cadence.

17. Secrets management

Squillify should protect platform secrets, credentials, tokens, certificates, signing keys, database credentials, provider credentials, and internal API secrets.

Controls may include:

• environment-level secrets management;
• restricted access;
• no hardcoded secrets in source code;
• secret rotation where appropriate;
• revocation procedures;
• provider-level secret storage;
• limited access to production secrets;
• incident handling for exposed secrets.

Customers are responsible for protecting their own secrets, API keys, tokens, and credentials.

18. Dependency and supply chain security

Squillify uses software dependencies, frameworks, libraries, build tools, container images, and infrastructure providers.

Security measures may include:

• dependency review;
• vulnerability scanning;
• patching;
• dependency updates;
• lockfile management;
• container or image review;
• source code review;
• build and deployment controls;
• separation of environments;
• restricted deployment permissions;
• monitoring of critical dependency advisories.

Before this policy becomes active, Squillify must confirm the dependency review and vulnerability management process used for production releases.

19. Change management

Security-sensitive changes should be reviewed before production deployment.

Such changes may include:

• authentication changes;
• authorisation changes;
• tenant isolation changes;
• API key handling changes;
• file handling changes;
• logging changes;
• external-service integrations;
• billing enforcement;
• rate-limit and quota enforcement;
• data retention jobs;
• deletion workflows;
• admin access changes;
• production infrastructure changes.

Squillify may use automated tests, code review, deployment checks, and staged rollout practices where appropriate.

20. Vulnerability disclosure

If you believe you have found a security issue, follow the Vulnerability Disclosure Policy.

Security reports should be sent to:

• [email protected]

Recommended subject prefix:

[Vulnerability Report]

Do not publicly disclose vulnerabilities before Squillify has had a reasonable opportunity to investigate and remediate, unless legally required or expressly agreed.

Squillify does not operate a paid bug bounty program unless expressly stated.

21. Incident response

Squillify maintains an incident response process for security, privacy, abuse, availability, and operational incidents.

Incident response may include:

• triage;
• containment;
• investigation;
• mitigation;
• remediation;
• communication;
• evidence preservation;
• customer notification where appropriate;
• sub-processor coordination;
• post-incident review;
• control improvement.

If an incident involves personal data, Squillify will assess notification obligations under applicable data protection law and the Data Processing Agreement.

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

Where Squillify acts as controller and a personal data breach is likely to result in a risk to the rights and freedoms of individuals, Squillify will notify the competent supervisory authority where required by law.

22. Backups and recovery

Squillify may use backups and recovery mechanisms for resilience and disaster recovery.

Backup controls may include:

• provider-managed backups;
• database backups;
• infrastructure snapshots;
• retention cycles;
• access controls;
• encryption where supported;
• recovery testing where appropriate;
• deletion through backup rotation.

Temporary files and raw microskill payloads are not intended to be retained as long-term recoverable backup content.

Before this policy becomes active, Squillify must confirm backup coverage, retention period, encryption, restoration scope, and whether temporary file stores enter backups.

23. Availability and resilience

Security and resilience are related but not identical.

Squillify uses operational controls to support availability and resilience, including:

• stateless execution where practical;
• horizontal scaling where configured;
• monitoring;
• rate limiting;
• quota controls;
• provider-level infrastructure controls;
• incident response;
• emergency maintenance;
• abuse mitigation.

Availability commitments, exclusions, maintenance, and service credits are governed by the Service Availability Policy and any applicable plan or written agreement.

24. Sub-processors and providers

Squillify may use sub-processors and third-party providers for infrastructure, hosting, authentication, payment, storage, database, email, logging, monitoring, support, analytics, and security.

Sub-processors that process personal data are listed on the Sub-processors page where applicable.

Squillify evaluates providers based on their role, security posture, data handling, contractual terms, region, and operational fit.

Before this policy becomes active, Squillify must confirm the sub-processor list, regions, transfer mechanisms, and provider security commitments.

25. Regulated customers and DORA

Squillify is not designed as a regulated financial entity.

Customers subject to financial-sector, operational resilience, outsourcing, DORA, CSSF, or similar regulatory obligations are responsible for determining whether their use of Squillify is appropriate.

Unless expressly agreed in a separate written enterprise agreement, Squillify does not commit to DORA-specific contractual terms, audit rights, exit plans, localisation, resilience testing, subcontracting restrictions, incident notification timelines, regulatory access rights, or regulated financial-sector obligations.

Customers must not use Squillify for critical or important regulated functions unless the required contractual, operational, risk, security, audit, exit, and regulatory conditions have been agreed in writing.

26. Customer responsibilities

Customers are responsible for securing their own use of Squillify.

Customers must:

• secure accounts and identity provider access;
• protect API keys and credentials;
• scope API keys narrowly;
• rotate and revoke keys when needed;
• manage tenant administrators and members;
• remove users who no longer need access;
• monitor agent and automation behaviour;
• avoid uncontrolled retry loops;
• avoid submitting unnecessary personal or sensitive data;
• configure applications securely;
• implement secure error handling;
• store outputs securely;
• respect rate limits and quotas;
• report suspected compromise promptly;
• comply with the Terms of Service, Acceptable Use Policy, API Usage and Fair Use Policy, and Tenant and API Key Responsibility Policy.

Squillify is not responsible for customer-side failures to secure accounts, agents, applications, networks, devices, systems, API keys, or integrations, except to the extent caused by Squillify's breach of applicable obligations.

27. What this policy does not promise

This policy does not promise that:

• Squillify is immune from attack;
• Squillify guarantees uninterrupted service;
• Squillify guarantees suitability for every regulated use case;
• Squillify detects all sensitive data;
• Squillify blocks all malicious files or payloads;
• Squillify scans every file for malware;
• Squillify can recover expired files;
• Squillify stores raw payloads for customer inspection;
• Squillify provides legal, regulatory, or security advice;
• Squillify meets DORA, ISO, SOC 2, PCI DSS, or other certification requirements unless expressly stated.

Customers must perform their own risk assessment before using Squillify for sensitive, regulated, mission-critical, or high-risk workflows.

28. Relationship with other policies

This policy should be read together with:

• Terms of Service;
• Privacy Policy;
• Data Processing Agreement;
• Data Retention Policy;
• Microskill Data Handling Policy;
• File Handling Policy;
• External Service Use Policy;
• Telemetry and Analytics Policy;
• Tenant and API Key Responsibility Policy;
• Acceptable Use Policy;
• API Usage and Fair Use Policy;
• Vulnerability Disclosure Policy;
• Service Availability 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.

29. Changes to this policy

Squillify may update this policy from time to time.

If changes materially affect security commitments, tenant isolation, API key handling, file security, incident handling, or customer responsibilities, Squillify will provide reasonable notice through appropriate channels.

No active version of this policy should contain unconfirmed claims regarding encryption at rest, malware scanning, backups, certification, production access, provider regions, or DORA-specific obligations.

30. Contact

For security questions, contact:

• Security: [email protected]

For vulnerability reports:

• [email protected]

For privacy questions:

• Privacy: [email protected]

For support:

• Support: [email protected]

For abuse reports:

• Abuse: [email protected]