Security

1. Scope and responsible entity

The KitSlate platform (the “Service”) is operated by MIXEL INC, a corporation organised under the laws of the State of New York, United States, doing business as KitSlate (“MIXEL INC,” “KitSlate,” “we”). This document applies to the production systems that deliver the Service at kitslate.app and to Customer Data processed within them.

“Customer Data” means the equipment records, productions, documents, client and crew records, uploaded files and related information that a Customer or its authorised users submit to the Service. Capitalised terms not defined here have the meaning given in the Terms & Conditions.

2. Hosting and data residency

Customer Data is stored in a managed PostgreSQL database and object store operated by Supabase on Amazon Web Services infrastructure in region us-east-1, in the United States. The web application, the AI-assisted features and PDF generation run on Cloudflare’s network, and generated PDF documents are stored in Cloudflare R2. File-transfer files are held in Cloudflare R2 object storage, encrypted at rest, in North America (Eastern North America location hint); the upload and download endpoints run on Cloudflare’s network, so transfer bytes pass through the location nearest the sender or recipient in transit. The email, payment and calendar integrations run as Supabase server functions.

Customers located outside the United States should refer to Section 21 of the Privacy Policy, which sets out the transfer mechanisms applicable to international transfers of personal information.

3. Encryption

• Data in transit. All connections to the Service, to the database, and to subprocessors are encrypted using TLS. Requests received over HTTP are redirected to HTTPS.
• Data at rest. The database, object storage and their snapshots are encrypted at rest by the infrastructure provider using AES-256.
• Backup archives. Workspace backup records are encrypted in the browser before storage and are returned only to the signed-in account that owns them.
• Third-party credentials. Where a user connects Google Calendar, the credential issued by Google is encrypted with AES-256-GCM before it is stored, under a key held only in the server function environment and not present in the database. It is decrypted only inside that function, is never returned to a browser, and is deleted on disconnect, on revocation by Google, or on account deletion.
• Customer-held exports. A workspace export downloaded by a Customer is an unencrypted, complete copy of that workspace. Customers are responsible for securing exports once downloaded.

4. Tenant isolation and access control

The Service is multi-tenant. The following controls govern separation between Customer workspaces:

• Every table containing Customer Data carries the owning account identifier and is subject to PostgreSQL row-level security. Access policies are evaluated by the database engine on each query rather than by application-layer filtering.
• The anonymous database role can read only what a user has chosen to publish: published profiles and marketplace listings. Invoice payment pages and signature requests are served through narrowly scoped, purpose-specific paths.
• Privileged database functions are granted explicitly, and default grants that would expose them broadly are revoked. An automated control fails the build if a function becomes callable by a role not authorised to invoke it.
• Plan entitlements are determined server-side from the Customer’s billing record. The client application is not treated as an authority on its own entitlement state.
• All writes are validated server-side. The browser-resident copy of a workspace is a cache; the server copy is authoritative, and conflicting writes are rejected by a revision guard rather than silently applied.

5. Authentication

The Service does not implement password-based authentication. Users authenticate either through Google OAuth or through a single-use code delivered to the email address on the account. The application offers no password sign-in and never asks a user to set a password.

The security of a KitSlate account is therefore dependent on the security of the identity provider or mailbox used to authenticate. Customers are advised to enable multi-factor authentication with that provider. Sessions are maintained using short-lived tokens subject to refresh, and are revoked on sign-out. The Service does not currently offer a native second authentication factor; see Section 13.

6. Payment card data

Subscription payments and, where enabled by the Customer, online invoice payments are processed by Stripe, Inc., a PCI DSS Level 1 certified service provider.

• Primary account numbers, expiry dates and card verification values are submitted directly to Stripe’s hosted payment interface. Such data is not transmitted through, processed by, or stored on MIXEL INC systems at any point.
• The data retained by MIXEL INC is limited to subscription tier and interval, payment and renewal status, card brand and last four digits, and Stripe customer and subscription identifiers.
• Because all cardholder data fields are hosted by Stripe, the Service falls within the minimum PCI DSS assessment category (SAQ A).
• Stripe webhook callbacks are cryptographically signature-verified before processing, and paid entitlements change only on a verified webhook or a nightly reconciliation that re-reads Stripe; complimentary plans are granted by invitation or by an administrator.

Payments between a Customer and that Customer’s own clients are transacted between those parties. MIXEL INC is not a party to them and does not hold Customer funds. See Section 14 of the Terms & Conditions.

7. Backup and recovery

File-transfer files are deliveries, not records: they are deleted when their link ends and are not included in the nightly backup. Every night an automated job on GitHub Actions captures both the database and the workspace files behind it, encrypts the copy with AES-256 and uploads only the ciphertext to Google Drive, which holds no decryption key; the key is held separately by MIXEL INC. Backups are retained on a rolling schedule — fourteen daily, eight weekly and twelve monthly copies — so a deleted record leaves the most recent backups within about two weeks and ages out of all retained copies within about twelve months. Independently, our database provider maintains its own point-in-time snapshots.

Backups you cannot restore are a story, not a control, so the same nightly job proves the restore rather than assuming it: it decrypts the copy into a throwaway database, restores it, and checks the restored table counts and every file against the original before the run is allowed to report success. A backup that cannot be restored fails loudly rather than passing silently.

Independently of MIXEL INC’s own controls, Customers may export a complete workspace archive at any time, together with record-level exports in CSV and PDF format. MIXEL INC treats the availability of Customer-controlled export as a standing entitlement of the Service rather than a discretionary accommodation.

8. Email authentication and transmission

Outbound mail is transmitted by Resend from a verified sending domain. SPF, DKIM and DMARC records are published in DNS to permit recipient verification of messages purporting to originate from KitSlate. Inbound replies to documents sent through the Service may be routed to the originating workspace using a per-document token address; those tokens are randomly generated, single-purpose, and convey no account credential.

Email is not a confidential transmission channel and is not represented as one. A document transmitted by email passes outside the Service’s control on delivery, and any link contained in it — a file-transfer link included — is accessible to any party holding that link until it ends. Customers are responsible for controlling onward distribution.

9. AI subprocessing

Certain optional features — receipt and document interpretation, catalogue matching, import column mapping and drafting assistance — transmit the specific item submitted by the user to Anthropic PBC over TLS and return the generated result. Transmission occurs when a user invokes the feature, or when a receipt arrives at a workspace’s receipts address, and is limited to the submitted item, plus the names of the user’s clients, crew, kits, equipment and camera presets when drafting a production from a sentence. The Service does not send a workspace to a model provider in bulk.

Under Anthropic’s commercial API terms, inputs and outputs are not used to train its models. MIXEL INC does not use Customer Data to train, fine-tune or improve any machine-learning model, and does not license Customer Data to any party for that purpose. AI-generated output is advisory and requires review by the Customer before reliance.

10. Change management and release control

Changes to the Service are governed by a controlled release process, which MIXEL INC treats as a security control:

• Changes are deployed to a segregated staging environment, served from a separate origin with its own data store, before any production release. The staging environment cannot access production records.
• An automated certification pipeline executes the applicable control suite on each change, including financial calculation tests, database grant and permission audits, schema migration controls and interface regression suites. Control failures are remediated; they are not suppressed, weakened or removed to obtain a passing result.
• Production releases are assembled onto the commit currently served in production and certified as that specific tree, bound to a content digest. A certification does not transfer to a different tree.
• An automated runtime verification compares the deployed production artefact against the corresponding source of record, so that undeclared modification of the production environment is detected rather than presumed absent.
• Promotion to production requires human authorisation. Automated systems may prepare a release but cannot approve one.
• Each release has an identified rollback position prior to deployment.

11. Personnel and internal access

Access to production systems is restricted to personnel with an operational requirement for it, is exercised through the authenticated administrative consoles of the relevant infrastructure providers subject to those providers’ access controls and logging, and is used for operation and support of the Service. Credentials and API keys are held as managed secrets within the platforms that require them and are not committed to source control; an automated control fails the build in the event that a credential is introduced into the codebase.

12. Incident response and breach notification

MIXEL INC maintains an incident response process under which incidents are recorded, root cause is determined, and resulting controls are incorporated into the automated certification pipeline rather than retained as procedural guidance.

In the event MIXEL INC becomes aware of a breach affecting personal information, it will notify affected Customers without undue delay and in any event within the period required by applicable law, and will provide the nature of the incident, the categories and approximate volume of data concerned, the likely consequences, the measures taken or proposed, and recommended actions for the Customer.

13. Assurance and certification status

MIXEL INC states the following for the avoidance of doubt in procurement and security review:

• SOC 2, ISO/IEC 27001 and independent penetration testing. MIXEL INC does not currently hold a SOC 2 or ISO/IEC 27001 attestation and has not commissioned an independent penetration test of the Service.
• Multi-factor authentication. Multi-factor authentication is available through the Customer’s identity provider. The Service does not currently offer a native second factor.
• Service level commitments. The Service is not offered under a contractual uptime service level agreement.
• Regulated data. The Service is not designed for the processing of health, biometric or government-classified information, and MIXEL INC does not offer a HIPAA business associate agreement.

This statement is maintained as the assurance position changes.

14. Vulnerability disclosure

Suspected vulnerabilities should be reported to [email protected] with sufficient detail to permit reproduction. MIXEL INC will acknowledge the report, provide status updates, and credit the reporter where requested. MIXEL INC does not currently operate a paid vulnerability reward programme.

Safe harbour. Where research is conducted in good faith and within the conditions below, MIXEL INC will not pursue or support legal action in respect of that research, and such testing does not constitute a breach of the Terms & Conditions. Researchers must:

• test only against accounts and data they own or are authorised to test, and cease testing and notify MIXEL INC immediately upon encountering another party’s data;
• refrain from denial-of-service, volumetric and load testing, and from automated submission to forms or messaging facilities;
• refrain from social engineering, phishing and physical intrusion directed at MIXEL INC personnel or its providers;
• refrain from testing subprocessor infrastructure directly, and report such matters under the relevant provider’s own disclosure programme;
• refrain from destruction or alteration of data, and from any demand for consideration in exchange for disclosure;
• allow a reasonable period for remediation before public disclosure.

15. Subprocessors

The subprocessors engaged in the delivery of the Service, together with the processing each performs and its processing location, are set out on the Subprocessors page. Each subprocessor is engaged under contractual terms requiring it to process data only on MIXEL INC’s documented instructions. The list is updated in advance of the engagement of any new subprocessor that processes personal information.

16. Customer responsibilities

The security of the Service depends in part on controls exercised by the Customer. Customers are responsible for the following:

• Identity provider security. Enabling multi-factor authentication on the Google account or mailbox used to authenticate to the Service, and maintaining control of that identity.
• Access administration. Reviewing workspace membership and removing team members promptly upon change of role or termination of engagement.
• Distribution of links. Treating publicly addressable links — including invoice payment pages, signature requests and file-transfer links — as sensitive, on the basis that any party holding such a link may access the resource.
• Retention of exports. Maintaining independent copies of Customer Data using the export facilities described in Section 7.
• Retention of transfer files. Keeping an independent copy of anything sent by file transfer; expiry of a link is deletion of its files.
• Reporting. Notifying [email protected] promptly of any suspected compromise, unauthorised access or anomalous activity affecting the Customer’s account.

17. Contact

Security reports and enquiries: [email protected]. Data protection enquiries and rights requests: [email protected]. All other enquiries: [email protected].

MIXEL INC
a New York corporation, doing business as KitSlate
State of New York, United States
[email protected] · kitslate.app