Tenant and API Key Responsibility

Tenant and API Key Responsibility Policy

This Tenant and API Key Responsibility Policy explains the responsibilities of customers, tenant administrators, users, developers, applications, agents, scripts, automations, and integrations when using Squillify tenants and API keys.

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

1. Purpose

Squillify is designed to be used by developers, applications, automation systems, and AI agents.

This policy explains:

• how tenant responsibility works;
• how API keys should be protected;
• how scopes and skill access should be managed;
• what customers are responsible for when agents use Squillify;
• how usage and billing are attributed;
• what to do if a key is exposed or compromised;
• how this policy relates to security, fair use, acceptable use, billing, and microskill data handling.

2. Shared responsibility model

Squillify is responsible for securing the platform infrastructure, enforcing platform controls, and providing tenant, API key, scope, quota, telemetry, and access management mechanisms where available.

Customers are responsible for how their tenants, administrators, members, API keys, applications, scripts, automations, integrations, and agents use Squillify.

Shared responsibility means:

• Squillify secures the platform;
• customers secure their accounts, tenants, keys, systems, agents, and usage;
• Squillify provides controls;
• customers must configure and use those controls appropriately;
• Squillify enforces technical limits;
• customers remain responsible for what their credentials submit, trigger, or consume.

3. Tenant responsibility

A tenant represents an organisation, workspace, or customer environment inside Squillify.

Tenant administrators are responsible for:

• managing tenant membership;
• assigning roles appropriately;
• removing users who no longer need access;
• reviewing administrator access;
• configuring API keys;
• managing skill access;
• monitoring tenant usage;
• controlling billing exposure;
• reviewing usage and quota consumption;
• enforcing internal customer policies;
• ensuring agents and integrations are authorised;
• reporting suspected compromise or abuse promptly.

Actions taken under a tenant may be attributed to that tenant.

4. Administrator responsibility

Tenant administrators should be treated as privileged users.

Administrators may be able to:

• invite users;
• remove users;
• create API keys;
• revoke API keys;
• change scopes;
• manage skill access;
• view usage;
• manage billing-related settings;
• configure limits;
• connect integrations;
• trigger actions that affect platform use or cost.

Customers must ensure that administrators are trustworthy, trained, and removed when access is no longer needed.

5. Member responsibility

Tenant members must use Squillify in accordance with:

• these policies;
• the Terms of Service;
• the Acceptable Use Policy;
• the API Usage and Fair Use Policy;
• customer internal rules;
• applicable law.

Customers are responsible for member activity under their tenant unless otherwise required by applicable law or written agreement.

6. API keys as secrets

API keys are secrets and must be treated like passwords or production credentials.

Customers must not expose API keys in:

• public repositories;
• client-side code;
• frontend bundles;
• browser local storage;
• mobile applications where extraction is likely;
• URLs;
• screenshots;
• logs;
• prompts;
• support tickets;
• chat tools;
• documents;
• CI/CD output;
• telemetry;
• error messages;
• third-party tools without appropriate security controls.

If an API key is exposed, customers must revoke it immediately and issue a replacement.

7. API key creation

When creating an API key, customers should:

• use a clear label;
• identify the intended application or agent;
• assign only required scopes;
• restrict access to required skills;
• set appropriate rate limits where available;
• set appropriate quota limits where available;
• avoid shared keys where separate keys would provide better control;
• document the owner and purpose of the key;
• store the key securely immediately after creation.

The full key value is shown only once at creation time. Squillify should not be able to recover the original full key value after creation.

8. API key storage

Customers should store API keys using secure secret storage mechanisms appropriate to their environment.

Examples may include:

• server-side environment variables;
• secret managers;
• encrypted configuration stores;
• CI/CD secret vaults;
• backend-only configuration;
• restricted production deployment systems.

Customers should avoid storing API keys in:

• frontend code;
• public repositories;
• local notebooks without protection;
• unencrypted files;
• shared documents;
• prompt templates;
• browser storage;
• agent memory systems without controls;
• logs or analytics systems.

9. API key scoping

API keys should be scoped narrowly.

Customers should grant only the access required by the specific integration, application, or agent.

Scopes and restrictions may include:

• skill execution;
• skill discovery;
• file upload;
• file download;
• external-service skills;
• external-write skills;
• administrative operations;
• usage access;
• billing access;
• rate limits;
• quotas;
• category restrictions;
• per-skill permissions.

Customers should not use one broad, long-lived key for all applications and agents unless they have assessed and accepted the risk.

10. Per-key skill access

Where Squillify supports per-key skill access, customers should use it to limit what each key can execute.

Recommended pattern:

• one key per application, agent, or service;
• minimal skills per key;
• separate keys for test and production;
• separate keys for external-read and external-write use cases;
• separate keys for file-capable workflows;
• separate keys for high-cost or high-risk skills;
• separate keys for human-operated tools and autonomous agents.

This reduces the blast radius if a key is compromised or an agent misbehaves.

11. API key rotation

Customers should rotate API keys:

• periodically;
• when an employee or contractor with access leaves;
• when an integration changes owner;
• when a key may have been exposed;
• when a key appears in logs or support material;
• when a repository containing the key was public or compromised;
• when an agent or tool using the key is decommissioned;
• when requested by Squillify for security reasons.

Customers should design systems so keys can be rotated without extended downtime.

12. API key revocation

Customers must revoke API keys that:

• are no longer needed;
• are suspected of compromise;
• were exposed in public or insecure locations;
• are associated with a retired application or agent;
• are associated with a departed user;
• show suspicious activity;
• exceed expected usage;
• are involved in abuse or policy violations.

Revocation may stop new requests using that key. It may not reverse actions already performed or usage already incurred.

13. Compromised keys

If a key is compromised or suspected to be compromised, customers should immediately:

1. revoke the key;
2. create a replacement key with minimal required scopes;
3. update affected applications or agents;
4. review recent usage;
5. review billing and quota impact;
6. review external-write or file operations performed by the key;
7. check logs and repositories for exposure;
8. rotate related secrets if needed;
9. contact Squillify support or security where appropriate.

Security contact:

• [email protected]

Support contact:

• [email protected]

14. Agent usage

When a customer connects an AI agent, autonomous system, automation, script, or application to Squillify using an API key, that system may perform any operation allowed by the key's scopes, skill access, rate limits, quotas, and plan.

Customers are responsible for agent activity under their keys.

Customers must ensure that agents:

• submit only authorised data;
• use only approved skills;
• respect quotas and rate limits;
• do not expose keys;
• do not include keys in prompts or tool outputs;
• do not submit unnecessary personal or sensitive data;
• do not call external-service skills without approval;
• do not trigger external-write actions unintentionally;
• do not enter uncontrolled retry loops;
• handle errors safely;
• handle expired file references safely;
• stop or degrade safely when limits are reached.

15. Agent guardrails

Customers should implement agent-side guardrails before giving agents access to Squillify.

Guardrails may include:

• allowlists of skills;
• per-agent API keys;
• spending caps;
• quota caps;
• rate limits;
• approval workflows for external-write skills;
• approval workflows for high-cost skills;
• prompt and tool output filtering;
• secret redaction;
• data minimisation;
• maximum retry counts;
• exponential backoff;
• circuit breakers;
• monitoring and alerts;
• kill switches;
• human review for sensitive workflows.

Squillify controls do not replace customer-side agent governance.

16. External-service and external-write risks

Some skills may read from or write to external services.

External-read skills may fetch URLs or external API data.

External-write skills may send data to, modify, create, trigger, or delete data in an external system.

Customers must use extra caution before giving agents or applications access to external-write or provider-backed skills.

Customers are responsible for:

• confirming the destination;
• controlling credentials;
• avoiding unintended writes;
• testing safely;
• preventing harmful automation;
• complying with third-party terms;
• ensuring data may lawfully leave Squillify;
• monitoring downstream effects.

External service use is described in the External Service Use Policy.

17. File handling responsibilities

Where API keys can access file-capable skills, customers are responsible for:

• submitting only lawful files;
• avoiding unnecessary personal or sensitive data;
• understanding short file TTLs;
• handling expired file references;
• downloading outputs promptly where needed;
• not using Squillify as persistent file storage;
• not exposing presigned URLs;
• not uploading malware or unlawful content;
• respecting file size and file count limits.

File handling is described in the File Handling Policy.

18. Usage and billing responsibility

Usage is attributed to the tenant and credential that made the request.

Customers are responsible for usage incurred under their accounts, tenants, API keys, agents, scripts, applications, automations, and integrations.

This includes usage caused by:

• authorised users;
• agents;
• applications;
• exposed API keys;
• compromised credentials;
• misconfigured retries;
• uncontrolled loops;
• excessive parallelism;
• insufficient rate limiting;
• customer-side bugs;
• customer-side testing;
• third-party tools connected by the customer.

Refunds, billing adjustments, overage handling, and disputes are governed by the Billing and Refund Policy.

19. Rate limits and quotas

Squillify may enforce rate limits, quota limits, concurrency limits, file limits, execution limits, and fair-use restrictions.

Customers must design integrations to handle:

• 429 Too Many Requests;
• quota exhaustion;
• skill access rejection;
• expired file references;
• invalid or revoked keys;
• temporary degradation;
• service errors;
• billing-related suspension.

Customers should not bypass or attempt to bypass rate limits, quotas, or billing controls.

API usage and fair use are described in the API Usage and Fair Use Policy.

20. Tenant monitoring

Customers should monitor tenant activity.

Monitoring should include:

• API key usage;
• unusual volume;
• unexpected skill calls;
• external-service skill usage;
• external-write skill usage;
• file operations;
• quota consumption;
• billing changes;
• rate-limit events;
• failed requests;
• suspicious errors;
• activity by retired applications or users.

Customers should investigate unexpected usage promptly.

21. Logs and customer-side records

Because Squillify does not permanently store raw submitted payloads by default, customers should maintain their own records where needed for:

• audit;
• debugging;
• compliance;
• dispute handling;
• customer support;
• regulated workflows;
• reproducibility;
• incident investigation.

Customers should ensure their own logs do not unnecessarily store sensitive data, secrets, full API keys, personal data, or confidential data.

22. Data submitted under keys

Customers are responsible for data submitted under their keys.

Before submitting data, customers must determine whether the data:

• is lawful to process;
• contains personal data;
• contains special categories of personal data;
• contains confidential or proprietary information;
• contains third-party data;
• contains regulated data;
• contains secrets or credentials;
• is appropriate for the selected skill;
• may be sent to external services if the skill uses them.

Squillify does not provide a general-purpose sensitive data detection or classification service.

23. Support requests

Customers must not include full API keys, passwords, tokens, private keys, session cookies, payment card data, regulated data, unnecessary personal data, or confidential data in support requests.

For support, customers should provide:

• tenant identifier where available;
• API key label or partial identifier, not the secret;
• skill key and version;
• request identifier or run identifier;
• approximate timestamp;
• error code;
• expected and actual behaviour;
• sanitized examples where needed.

Support is described in the Support Policy.

24. Enforcement

Squillify may restrict, throttle, suspend, revoke, block, disable, or terminate access where necessary to:

• protect the platform;
• protect customers;
• protect providers;
• prevent abuse;
• enforce policies;
• reduce security risk;
• prevent fraud;
• manage compromised keys;
• respond to legal obligations;
• avoid infrastructure harm;
• address payment failure;
• address excessive or harmful traffic.

Protective action may occur without prior notice where needed for security, abuse prevention, legal compliance, or platform stability.

25. What this policy does not promise

This policy does not promise that:

• Squillify will detect every compromised key;
• Squillify will prevent every agent mistake;
• Squillify will classify sensitive data before submission;
• Squillify will refund all usage caused by customer-side errors;
• Squillify will recover data deleted or expired under retention policies;
• Squillify will guarantee compatibility with every agent framework;
• Squillify will monitor customer applications or agents on the customer's behalf;
• Squillify will provide legal, security, regulatory, or compliance advice.

Customers remain responsible for their own systems, credentials, agents, and data governance.

26. Relationship with other policies

This policy should be read together with:

• Terms of Service;
• Security Policy;
• Acceptable Use Policy;
• API Usage and Fair Use Policy;
• Billing and Refund Policy;
• Microskill Data Handling Policy;
• File Handling Policy;
• External Service Use Policy;
• Support Policy;
• Data Processing Agreement;
• Privacy 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.

27. Changes to this policy

Squillify may update this policy from time to time.

If changes materially affect tenant responsibilities, API key handling, agent use, billing responsibility, or security obligations, Squillify will provide reasonable notice through appropriate channels.

28. Contact

For questions about this policy, contact:

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

For suspected abuse, contact [email protected].